Jan. 31, 2013

Growing powerful agile teams

Without strong, self-sustaining agile teams, any change as a result of an agile transformation is very likely temporary

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.

 

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.
blog comments powered by Disqus
Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Latest Posts

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.