When Will My Team Be Agile?
“When will my team be Agile?”
I get this question more frequently than you think from well-meaning management and executives wanting to initiate a transformation or apply Agile to their existing projects or ways of working. For this question, I’ll share with you what I have seen my teams live through as a coach (I know, don’t hate me yet!) and someone who has been part of many (countless blood, sweat and tears, you name it!) projects and scrum teams.
Ask the why
Firstly, I think it’s good to explore the drivers that led to people asking this question in the first place. Your drivers could be very similar to the following:
- Unable to deliver projects — your current team has had multiple attempts at building something with no success.
- Wanting to utilise their current team — well-meaningly, the leaders wish their existing teams could deliver, and they heard Agile, specifically scrum, would be a good idea. They want their team to learn and apply it in their projects.
- Experienced members but still no delivery success — your current teams have members with many experiences working in an Agile/ scrum environment. However, this doesn’t affect the whole team’s execution and output. They’re still struggling to deliver.
So when exactly can your team become “Agile”?
Agile Fluency
To understand how long it will take for your team to become Agile, you’ll need a little intro to the stages of Agile Fluency. Here I’ll explain and share my experiences and how long it usually takes in the wild.
Focus on value
One of the best things about learning and applying Agile and Scrum is that it provides teams with a formula to execute projects. There’s a formula for Standups, how we write stories, what our Scrum schedule looks like, estimating, etc. Easy enough, right?
More often than teams care to admit, as they follow these formulas mindlessly, they end up not delivering value. Have you seen Scrum teams who have completed so many sprints tell you that they haven’t delivered anything usable? Why is that?
The reason is that the teams were not focusing on value. They were merely executing a formula, hoping that value would come out of it. Agile, after all, is a mindset. Take, for example, the Standups. Mindlessly reciting what you did yesterday, what you will do today, and any blockers won’t take you far. But consciously being alert on how someone’s task today may affect yours or the project’s overall progress is the Agile mindset and way of working we want to encourage. Imagine if everyone in your team does exactly that!
So at this stage, we start shifting your team’s mindset and execution to focus on value. Focusing on value involves getting clarity on how your teams run these given formulas (standups, sizing, planning, stories, etc.) in the first place. We look into all the nitty-gritty of what seems to be simple/trivial things to elevate the quality of the team’s communication style, stories, sizing, scrum, etc. Once we focus on quality, we start to focus on value. Quality and value go hand in hand.
How long does this usually take? 1–2 months.
I often warn leaders that they’re not going to like this number. Most of them want an immediate change. Change is hard to stick because we are dealing with people. They typically think there’s nothing wrong with their current working methods until they see a better way of working. Within this period, you will also see the team fluctuate in applying and not applying the changes you have implemented. It’s only natural as they’re testing the waters. If you have a coach working with you, usually, their presence will enforce a conscious practice of elevating the quality and focusing on value. Then as progress happens, you will start to taper off the coaching in this area. So that, eventually, the teams run on their own.
At the end of this stage, your team will start to sound and execute like a real, mean, functioning machine! Oops, I mean an Agile team. You don’t necessarily need to progress to the next stage of the Agile fluency. Most successful delivery teams can stay at this stage of Agile fluency and enjoy the fruits of focusing on value.
Deliver Value
This stage of Agile fluency calls for your team to deliver consistently with a predictable cadence which means you can plan for a scheduled release to the Market.
How long does this usually take? 3–6 months.
This one is the next level up from focusing on value. It requires your team to be in the flow (orchestration) of managing what’s coming in terms of work and managing problems(blockers) as they arise.
Let’s break that down a little bit further. What does it mean when I say to be in the flow of managing incoming work? It means that the team has a valued feedback loop to prioritise the work and product backlog. We use the team’s insight on how long build work will take, and together, we start to sharpen the team’s estimation skills. Hence, the team keeps getting better to be able to deliver consistently.
Now for the bit about managing blockers as they arise. These scenarios can always throw any well-oiled machine into chaos. At this fluency stage, teams work together to sharpen their skills in managing these blockers. It means simplifying the triage process, bug management and managing any new items creeping into the backlog, including changes in the priority. Remember that these factors will influence your team estimation.
This stage is fluency is more complex because of all the factors we need to consider and rallying the troops to work together as one team while thinking of the cause and effect of their actions. Hence the changes take a little longer to take effect.
Optimise value
We now move into the stage of Agile fluency, where we start to shift the mindset of the broader organisational structure.
The shift I refer to can range from infrastructure changes (i.e. building DevOps or automation) to building a feedback loop from the customer back to the product, which assists in better decision-making and building to the customer needs.
How long does this usually take? 1–2 years
I know what you’re going to say. It’s too long! I know it is! By all means, I’ve seen companies build and implement the tech infrastructures they need for their projects in only a few short months. The sticking points are creating a feedback loop to make better decisions and the usage of those infrastructures to start automating, eliminating friction in handoffs between teams and implementation to production.
Smaller companies and startups tend to be better at getting to this level of Agile fluency because they haven’t got the politics of the more giant corporates. They tend to have people in their teams wearing multiple hats and haven’t yet invested in existing heavy processes.
More giant corporates tend to get to this fluency stage a little later because most will implement change while they do their existing work. It’s like doing a house renovation while still living in it. It’s not necessarily bad. It’s just what they can do without putting a halt to existing work.
Optimise for systems
This stage of Agile fluency is a broader organisational change. So vast and deep that it starts to change its culture. We’re talking about cross-pollinating ideas and value streams. The stuff they talk about in SAFE.
How long does this usually take? Well, I wish I could give you a number on this one. From experience, this is a more challenging and longer change. Many corporates go through SAFE transformation doing the building blocks, and most of those teams will reach the Focus on Value and Deliver Value stages and be called total success.
I see this stage of fluency as more of the evolution of the groups and the company. There’s no telling how long it takes to get to this maturity. However, there’s also no rush in getting to this stage, as you can still clearly have highly functioning teams who deliver successful outcomes in the earlier stages of fluency.
So there you go, my friends. There is no short answer to how long it will take for your teams to be “Agile”. But now, at least, you have an insight into what you need to get there!
