Growing powerful agile teams
Agile teams are the building block to any successful agile transformation. Without strong, self-sustaining agile teams, any change as a result of an agile transformation is very likely temporary. At agile42 we spend a lot of time helping our clients form powerful agile teams, and in the following we explain a little about our approach.
Characteristics of an agile team?
As well as small, 6-9 people, an agile team is:
- Cross-functional – the team includes all roles necessary to deliver the work (at minimum Dev and QA), and dependencies outside the team (e.g. UX) are understood and available as needed
- Dedicated – team members are dedicated, with any non-sprint work transparently tracked on the task board and the potential impact (decreased priority) agreed with non-sprint stakeholders
- Co-located (preferably) – defined as sitting in the same space. Where distributed teams are necessary, ensure strong ties are created through virtual tooling and regular communication
- Working from a single backlog – the team has a single product backlog, containing items prioritized by the business and ready for the team to work on, from which to pull work
- Managing unplanned work – agree with the PO an agreed contingency or bug capacity to be removed from the sprint; manage this contingency to avoid impacting the sprint commitment
Getting started
We start with a conversation with the team around the +15TEAM assessment, a simple dashboard of 15 basic agile behaviors and practices that provide the foundation for an agile team. The +15TEAM acts as a seed for discussion and understanding about why each practice is part of the foundation of a successful team.
But the +15TEAM is not enough. We need a team to develop new habits and skills, and to break old destructive habits. Any new agile team will pass through three levels of growth to become high-performing, predictable agile teams.
Three stages of an agile team
Stage 1 – Predictable Delivery
Start by creating a habit of finishing work requests within the team. Many teams or developers working in a traditional environment quickly lose the habit of finishing a feature completely, perhaps as a result of silo’d delivery or high interruption levels. Quickly reintroduce this habit, before focussing on other agile behaviors. Without the habit of getting to done, a team will never progress.
Predictability is the ratio of the number of story points completed to the number of story points committed to. High predictability is above 90%, the target above 95%. Completing a story means meeting all the points mentioned in the Definition of Done, defined by the team itself.
Stage 2 – Build Quality In
Once a team has the habit of predictable delivery, the team turns their attention to quality. While learning to deliver predictably, the team has become more and more aware of technical ownership.
With support from the business and the product owner the team have already taken on non-product related stories to improve their working environment or remove technical debt. Focusing on the technical standards the team works to, they raise the bar and build quality into their process.
Tightening the Definition of Done constraints or measuring and making visible quality metrics and technical debt, such as bug counts and the results of static code analysis, contributes to a focus on quality, and in particular, building quality into a product, rather than chasing quality at the end.
Stage 3 – Sustainable Delivery
Finally, once a team has mastered completing the stories they commit to while building quality in, they turn their attention to improving throughput. This is a delicate step because a traditional mindset might set velocity goals to increase productivity. But velocity is a lagging indicator, telling a team after they have reached a sustainable pace, rather than a leading indicator telling the team what more needs to be done.
Think of velocity like weight. I can measure my body weight to determine how much I weigh today, but on its own my weight cannot tell me how my weight will change, whatever I promise to do.
Instead focus, through observation and frequent retrospectives, on aspects of the technical environment or team dynamics that prevent high performance. This might mean speeding up feedback loops for the development team through continuous integration and test automation, or using the retrospectives to enhance team work around a single story.
Remember enhancements on productivity often have a negative impact on the predictability of the team. For example, challenging teams to take on additional stories to expose weaknesses in their development environments or team dynamic, means predictability will fall as stories are dropped. Set expectations appropriately, and make the work of the team transparent, to help mitigate concerns raised by variations in productivity.
In closing, growing powerful teams takes dedicated time and targeted effort. Changing team behaviors and practices requires the courage to recognize mistakes, and the honesty to delve into the root cause of the results, good and bad, the team delivers. But the rewards are impressive: A team that stands on its own, robustly handling organizational churn, and with the capability of predictable delivery of new features. Think about it – it might be worth it.