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

Why are organizations not seeing the benefits of doing Agile?

Due to a difference in goals and approaches, friction occurs between Agile teams and the rest of the organization - who has yet to see the benefits...

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.

Agility requires cultural change

Article published 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.

Agile in Everywhere: Sales

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP Berlin

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP