How Do I Know Agile is Succeeding?
When talking to potential customers, we often get told that a team or program has been ‘agile’ for months, or even years. It’s not uncommon for us to find teams applying those agile practices we associate with successful teams: retrospectives, shared code ownership, decent product management. Unfortunately, this does not necessarily translate into what we consider to be a successful agile delivery process. So this got us thinking:
What does a successful agile team or organization look like?
How do we know a good agile team when we see one, or a great agile organization when we see one?
Here’s what to look for:
1. Listen for the ‘Why’
Becoming agile is a cultural shift, not a tactical shift.
The practices are the how, not the why. Just as Simon Sinek points out, it’s all about the why. A cultural shift is made visible through the conversations we overhear and the discussions and communication between teams, rather than the practices we observe in the teams. Therefore, in order to understand how well a team or project has adopted agile we want to listen to how they communicate, not just focus on the practices they are using.
2. Improve learning capabilities
The goal of adopting an agile mindset is a to develop a capability, not reach a destination. We don’t want teams to aim for “50 points per sprint”, or a “release at the end of each sprint”. The objectives are new skills and ways of working that allow the team to learn and grow, not measures of activity or productivity. Here, we do look at practices. What skills are the teams building? What capabilities do the teams have? Not efficiency or productivity skills and capabilities, but learning and experimentation skills and capabilities.
So, now that we know what to look for? How can we identify successful agile teams?
Here, we ask two questions:
Do you focus on value delivery or activity and productivity?
Are you continually learning, able to continually refine and adjust a living work delivery process?
Value over Activity
Agile frameworks, from Lean Startup to Extreme Programming, are focused on the rapid delivery of customer value. Every aspect of each framework starts with the assumption that the teams are working as hard as possible. The level of contribution is not in question. Therefore, what is delivered becomes the primary concern. In agile organizations, the cultural noise we hear is focused on the delivery of value rather than comparing activity or productivity. Teams talk about the features they released, and how well (or not) the customers valued (used, paid for) the new features. It’s not a race to do the most work, or have the most number of features, but to provide something the customers need and value.
One of us (the Englishman) is a big fan of the English Premiership. The successful teams are those that grind out results against unsexy, mid-table opposition, many times against the run of play. We often hear the teams that win the Premiership described as boring or being able to grind out ugly wins (Chelsea or Manchester United, for example); winning games by one goal even though they played poorly. On the other hand, there are teams that play some of the best football on display in any league, with an incredible strike force or elegant build-up play (stand up Arsenal) and still do not win. The hard reality is that these teams lose sight of the value - winning games - because they are focused on elegant activity, on quality and on productivity.
We want to hear about the value delivered - the games won - not the productivity of the team. Conversations revolve around how to get value to the customers, how to understand what the customers need, and how to deliver that value quickly, with the minimum of fuss.
Experiments are the New Black
Agile organizations are continually learning, basing decisions at all levels on small experiments in which they learn something about how to move quickly toward their goals. This focus on continually learning through micro-experiments extends throughout the organization, from how the teams work to what the teams work on. Agile development teams can use it to determine if a new practice will help them deliver better quality code and Product Owners can use it to determine if customers will really use the great new feature they’re developing. Continually learning is predicated on designing a small change, and testing whether that change improves your outcomes or not. Keep the ones that move you forward and change the ones that hold you back.
As groups make the transition from doing a lot of work to doing the right work, one obvious question always comes up: How do we know what the right work is?
It is a natural tendency in many organizations to use assumptions to make these decisions. Perhaps you’ve heard comments around your company like “everyone knows that…”, “none of our users…”, or “everyone’s code includes…”. Yet you wouldn’t plan a road trip from Seattle to New York by assuming any road going east will get you there, so why would you base critical decisions on assumptions about your business or customers. Instead, agile organizations target these assumptions and find the true answers before making their decisions. In Eric Ries’s Lean Startup book, this practice is aptly referred to as Validated Learning.
Most organizations will transition from assumption-based decisions to validating decisions in hindsight. As the organization gets better at framing their validation experiments in smaller pieces and gets more proficient at extracting informative data out of their experiments, they will begin to be more proactive in their validated learning.
Don’t Take Anything for Granted, Even Agile Practices
A case in point. Many new agile teams struggle to complete valuable work within the sprint constraints of Scrum. One team we worked with wasn’t sure that well-defined user stories with acceptance criteria would really help resolve this challenge for them, so they created an experiment around it. For the next month (two sprints for them), the team and Product Owner would commit to a strong definition of ready, creating a clear understanding of what the team was being asked to deliver. In the sprint reviews, if the resulting work from each story matched what the end user was looking for, they’d know that this practice was effective in solving their problem. On the other hand, if they kept missing the mark and incurring expanding scope on their work, they’d know that this practice was not enough to help them deliver value in their sprint. This was a short, well-defined experiment that helped the team take a step towards owning their delivery process.
Adopting agile is a journey and every organization is at a different place in that journey. So how do you know you are moving along in the right direction, at a decent pace without too many detours?
We believe you have to listen out for two things:
How often are you talking about (and following through) on value delivery to the customer? Remember value delivery is more important than productivity.
How many discussions do you hear on the experiments that teams are working on? Remember, Status quo is not the goal, but the baseline; continual learning and improvement is the goal.
So, how well are you doing? Join us on LinkedIn to continue the discussion! (agile42 #WhyAgile Discussion Group)