In the early days of executing Scrum, Jeff Sutherland and Mike Beedle formed a set of proven patterns. They found when a Scrum team practices these patterns; the result is a state of hyper-productivity. Jeff Sutherland published these patterns in 2014(1). As defined, hyper-productivity equates to more than a 400% velocity increase over a team’s initial velocity.

The work continues, and new patterns are log during each yearly session at the Scrum Pattern Community(2)

During the March-May Covid-19 confinement, I decided to look more deeply at the idea, put names on some patterns I was already using, and try some new with teams I was coaching remotely.

9 Scrum Patterns for a Hyper Productive Scrum Team

Patterns link to a specific context; experiences showed that some patterns bring on the wrong period could not bring the success expected or bring more disruption than anything else.

Successful Team

It’s the beginning journey of our Scrum Team; we all pass through this part; the people start to learn how to work on a team. The Scrum Master protects the team, and the Product Owner comes with a new value to introduce into his product.

There are two common patterns that I am such you will recognize:

Stable team

It is the first step we struggle with the most; having a stable team will take less or more time, depending on the outside system’s willingness. In my last 20 years of experience, I was witnessing a lot of harmful patterns; the most common pattern is the

The account patterns: where the team members are just numbers that you add or remove on needs, you are cost-driven, these people are placed on task for a specific time without regarding the value they bring. Very common in the project-oriented organization.
I am not surprised to see many of these people looking to move out and catch any other organization’s function.

The Hero patterns: another widespread pattern, where you see people work for a specific function without any link with the others. Usually, you see other people hired to bring this relation between hero has the integrator or the Project Manager.

First things you need to remove these harmful patterns and having a stable steam. In Scrum, you will bring the Scrum events, values… but that’s not enough. Please don’t bring it; it has a gold plate without the team understanding why we are doing all this. I like to use the ADKAR Model(3) – Awareness, Desire, Knowledge, Ability, and Reinforcement; it helps the Scrum Master bring a new practice per step and reinforce it.

A stable team has 3-9 persons, working together daily bases; research by Harvard Professor Richard Hackman(4) shows that the smaller end of this range, five members, is best. It allows for fast communication saturation and team alignment. And it provides adequate skill and perspective differentiation to complete the work.

The team considers it has a CAS – Complex Adaptive System(5) that doesn’t change on the extended life, the system stabilizes, and the velocity starts to stabilize. It is much more comfortable for the Product Owner to predict the business has the team know their capacity.

Yesterday Weather

The concept is straightforward, to know your team’s velocity, you measure the last know velocity. Yes, the velocity is not something you calculate with ingenious mathematical formulas. It is empirical, and there are no magical formulas. I tell you a secret that only a few of us know – We are human, not a machine, so we are a CAS like a team is a CAS; we behave differently in different contexts. And no one knows with accuracy the context of tomorrow. We can only make the hypothesis that tomorrow would be approximately like yesterday.
It’s the reason we look at yesterday’s weather.

I recommend most of the time to take the last 3-5 sprints mean velocity, to have a more accurate velocity, especially at the beginning of a team journey. When you know that the velocity will be cyclic, and from one velocity measured to the other, there could be a 2x difference or more. Why will you say? Because the team doesn’t know their real capacity and are learning, remember we are human; context changes impact us more than machines.

I was the witness of the following team struggle patterns:

Too much: the team take always more than their know capacity. There is a different reason why a team would commit for more than know capacity:

• Please the management, we are trying to give more than we are usually able, but the problem is not sometimes but continuously.
• Don’t know how to say NO to their Product Owner. Here the Scrum Master should challenge the team and protect the team from such bad behavior.

Not planned task: The team member receives too much not planned task to do, this is the most common problem, and it will be the most common issue.

Work outside: Team members work on other teams; what can I say? You can be part of different teams because then you have a conflict of interest. How can you commit to a different team backlog?

All these examples will result in only one result—a loss of trust between the customer and the team.

Deal with Common Disruptive

You have now a Stable Team and use the Yesterday Weather, it’s then the time to work on the disruptive that interrupt your team on their daily work.

Swarming

You may have heard about the concept of Mob Programming(6) by Woody Zuill. The concept is quite similar to Swarming. The idea is if you want to accelerate, you need to have a team focus on the least amount of work. For this, you introduce a limit WIP to your « In Progress » of one that forces the team to work with one PBI (Product Backlog Item) per time.

Someone in the team will take the lead on the PBI; we talk about emergent leaders. The rest of the team support the lead on the resolution of the PBI. When the PBI is done, we take another PBI in the backlog and, the same or another leader emerges.

In my last five years of experience, I sow many teams take this idea and swarm; for some teams, it was introduced by their Scrum Master, for some ideas come from a team dev member who has heard about the Mob Programming concept.

Interupt Patern

You may have heard about teams interrupt continuously by run items (production incident, service request). Then if you see yourself on that team, this pattern may help your team.

1. The Product Owner, along with the team, decides on a capacity dedicated to this interruption.
2. When an interruption occurs, they decide to take the interruption or postpone it to the next Sprint.
3. The team aborts its Sprint If the Interruption capacity is exceeded.

No one likes to interrupt a Sprint, neither the management, neither the team. It will show anyone what happens if we don’t control the flow of interruptions.

This pattern is powerful when taken together with the Swarming pattern. When combined, teams uncover an ability to meet the Sprint Goal early and move work to « Done » faster.

Daily Clean Code

A long time ago, when I worked as a Scrum Master on a team, we had a unique commitment between us. In the morning, the first 30 min was dedicated to fixing as many bugs, technical debt, etc. At that time, we drastically reduced the number of defects in our code.

This pattern is in line with the Agile principle:

« Continuous attention to technical excellence and good design enhances agility. »

If you want an accelerated team, you must remove all the impediments that slow down the teams. Push to later work will only slow down the team; these defects and evil design issues are all the small stuff that will slow everything sooner or later.

The team finishes each story respecting their Definition of Done; we do all that needs to be done to deliver a more stable product than the previous increment.

Unfortunately, in most of the projects I assess, we still think a process improvement is more effective than technical excellence. Technical excellence slows down the release of a project. Why? Because in a Project-driven mindset, all these evil designs will emerge only after the project, in the maintenance phase. At that time, the budget is no longer linked to a project; we work with different people. The project was delivered on time and on budget.

Ron Jeffrey says in one of his 2018 Tweet:

A developer’s lifespan in a product is shorter than the impact feeling of a bad design.

A way to bring this to a team is at the Daily Scrum; instead, each person says where they are, you ask the team what needs to be done, so the first story is done today. Then you do the same to the next story until there is no one working on a story.

Emergency Procedures

This one is for the Scrum Master, an emergency procedure to follow after we tried everything else. Like the pilot in an airplane, they have an emergency procedure to follow, and hopefully, we don’t need to go the last check.

1. Change the way we work: the way we are working doesn’t seem to work. Let’s experiments with other practices to do our job.
2. Get help: We need outside help with our struggle. Talk with another Scrum Master, ask to meet an Agile Coach. Don’t stay there without doing something. Somewhere outside, there is someone who has already tried something that may work for us.
3. Reduce Scope: Maybe the team took too much; let’s see what we can remove so the team can reach their goals. Remember, the team commits on a Sprint Goal; maybe they were too ambitious.
4. Abort Sprint: When there is nothing that can be done, it’s better to abort the Sprint and start a new one with a goal the team can respect and bring value to the product.

It happens to me only once; we were forced to abort the Sprint. It was during the holiday. The person who committed to the Sprint Goals was not the same who realized the Sprint. Since the beginning of the Sprint, the teams were continuously asking the Product Owner other things to do, not link to the Sprint Goals, like the other persons were not there.
I finally ask the Product Owner to abort the Sprint and prepare a new Sprint Planning for the remaining days. The management was not happy; we were late now. For the team, it allows them to accelerate. In the end, the team was able to deliver on time.

Drive the Hyper-Productive team

The team now performs; they know how to resolve problems and work as a trusted team struggling toward their commitments.

Scrumming the Scrum

The goal of this pattern it’s to use Scrum for improvement. Each improvement discusses during the retrospective is put on top of the next sprint backlog. And it is considered as the most important thing to do.

At the Daily Scrum, the team discusses what needs to be achieved to finish the improvement before starting the next item from the backlog.

It will eradicate impediments and make a significant improvement over time on team delivery.

Today I don’t even wait that the team performs before introducing this pattern. I introduce it as early as possible, so the team gets rid of the problem faster.

Happiness Metric

Happiness results from team autonomy, mastery, and purpose, as explained in the book « Drive » by Daniel Pink. A team that is happy about their future performs better.

Tony Hsieh, in his book « Delivering Happiness, » understood it well also. If its employees were happy, then also its customers. There are numerous examples on the market, some well-known like SouthWest Airline, an American airline that put its employees before the shareholders.

In 2013 I met the Brussels city HR Manager during a conference in Antwerp (Netherlands); she presented her work at bringing happiness in a government environment. The results were upstanding.

The team needs to keep track of their happiness from Sprint to spring and take notes on events. It allows the team to react fast to future impediments.

Finish early, team accelerate

Stretch Goals and dates don’t motivate teams. And they do not let them deliver faster. The eight firsts patterns will help the team to deliver sooner. When a team finishes earlier, they can add a new backlog item in their Sprint, that they can achieve during the current Sprint.

A team can improve its delivery; it is not by improving its velocity, but by delivering more value to the product.

Reference

1. Teams that Finish Early Accelerate Faster: A Pattern Language for High-Performing Scrum Teams. Jeff Sutherland, Neil Harrison, Joel Riddle 2014
2. Scrum Published Pattern Librairie – http://www.scrumplop.org
3. ADKAR Model – Awareness, Desire, Knowledge, Ability, and Reinforcement
4. Leading Teams: Setting the Stage for Great Performances. Cambridge: Harvard Business Review Press, J. R. Hackman, 2002.
5. CAS – Complex Adaptive System- https://en.wikipedia.org/wiki/Complex_adaptive_system
6. Mob Programming – https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/
7. Drive by Daniel Pink – https://www.danpink.com/books/drive/
8. Delivering Happiness by Tony Hsieh – https://www.deliveringhappiness.com/