6 Agile patterns of hiper-productive teams

Have you been in a daily where each team member looks at their cell phone after "passing their status"? or in a Sprint where the duration, scope, and goals were changed in the middle? - Maybe a retrospective without value? - If these issues sound familiar - then please check this post in which I present 6 useful patterns of hiper-productive teams.

What is a pattern?

A pattern is a proven solution for a specific problem in a specific context. That′s all. The main advantage is that you will benefit from a solution that was developed and proven by people who were in the same situation as you are right now.

Patterns in action

Here is the list of patterns with some links to help you know more about it.

Stable teams

Let′s start by bringing the projects to the teams instead of resources to the project. This means: First, let′s understand the core values of the team, their strengths, skillset, and challenges, and let′s match the initiative to the team.

According to Brook's law: the more people you introduce in a project while you have an urgency, the more it will take you to complete the project.

It seems that the first thought when we were delayed was to introduce more people to the project. In the end, this will result in a worse result. Not just for onboarding′s overhead - The human factor is essential and underestimated: Trust, empowerment, integration, and productivity are the result of a process, not just something that happens in one day.

Swarming

If your team is stable, if they know each other, then the team knows how to assign their tasks. This is one of the easiest patterns to apply and, at the same time, one of the most difficult ones - It is all about the mindset - Basically, we should reduce the work in progress to 1 ( or closest to it) and assign as many people as we can to a specific task and goal.

Sounds imposible right? - Trust me - The more your team multitask, The worse their velocity, integration, coordination, and collaboration.

Have you seen people working in small sub-cells with different goals, not understanding the product or what other team members are doing? - I would give it a chance if I were you.

Yesterday's weather

What happens when you have unexpected changes in the middle of the sprint? - How can you manage them? - how much work should your team commit to each sprint? - If this is your case, then yesterday's weather and Interruption Buffer procedure patterns are for you.

Based on the velocity or cycle time of the last three sprints, your team knows how much work they should commit. You can make decisions based on these numbers. For instance, save a buffer for unexpected issues or to work in technical debt.

Interruption Buffer

You know your velocity - Then save 10 % or whatever you consider to work on unexpected critical issues, technical debt, and whatever you want. easy, right? - wait then, and I encourage you to follow these steps :

1- Implement Yesterday's weather

2- Group incidents/issues you′ve had in the last three sprints (understand the capacity that they took it)

3- Save that capacity as a buffer - If you don′t know, you can use a standard number - for instance, 20 %. So, if the velocity of your team is 40, then save 8 story points of capacity as a buffer

4- When an incident comes, you will have that capacity to cover - If that capacity is exceeded, you can choose to close and re-plan the sprint or implement action from the next pattern, which is #emergency procedure#.

Emergency Procedure

Being prepared for critical situations is the best way to face them effectively. This is all what this pattern is about.

Asking yourself just "what if" - What if this fails - what if I have a critical incident - what if a critical resource is not there anymore - what if my release fails will serve to prepare the procedure to attack that issue with a solution that fits your context.

Ask for help from other teams, Re-scope the sprint, Start a new sprint, and rollback your release are all examples you can practice and emulate to be ready when a critical situation comes - Much better than trying to improvise in the middle of the storm uh?

Scruming the Scrum

If I would get a dollar for every time that I heard that the retrospective doesn′t add any value or anything is improved - I might be rich these days.

The main goal of a retrospective is to generate insights in the team members to embrace the improvement - a mindset of commitment with excellence. Instead, just a board or an Excel file with the awful and boring same two /three columns (what was ok, what we can improve) are spread on every retrospective.

Scruming the scrum helps to implement an iterative framework to improve our scrum process. This is how I implement it :

1- Implement fresh approaches on every retro

2- Get one takeaway or action item that you would like to improve in the next sprint regarding the scrum process

3- create an action item in your backlog with specific steps to be done by the team

4- review the results in the next retro

5- iterate

At the end...

Patterns are useful solutions that will make your life easier. It is easy to think about the what, but it is harder to know the why and the how. These are the main challenges that managers face.

Have you found this post helpful? Would you like a step-by-step guide based on my experience, or maybe include more patterns in the next post? All comments are welcome.