Many organizations without any Agile experience want to immediately jump right into a fully scaled environment. Others may be dabbling in Scrum or Kanban with one or two teams and feel they are ready to expand with new teams or roll out Agile practices to other parts of the organization. However, in many instances, an […]
Many organizations without any Agile experience want to immediately jump right into a fully scaled environment. Others may be dabbling in Scrum or Kanban with one or two teams and feel they are ready to expand with new teams or roll out Agile practices to other parts of the organization. However, in many instances, an organization is not fully ready. Here are 4 reasons why you might not be ready to scale agility.
“We need everyone to be Agile at the same time.”
Consider the organization who wants a big-bang scaled Agile transformation, despite having little to no experience with agility. Often, an end-goal is defined, a detailed roll-out plan is crafted, a framework is forced upon an organization and frustrated and confused teams move forward with plans and processes that they feel don’t make sense.
This approach is at odds with the Agile Manifesto: it places processes over individuals and planning over responding to change.
When faced with a complex new release, an Agile team would decompose release goals into small, manageable chunks, receive feedback on what they delivered and adapt their plan based on what they learned. An organization will find more success when trying to scale agility by adopting a similar strategy and beginning with just a single team.
This first team can learn and adapt their processes based on what makes sense for their context. This learning will inform plans for future teams.
To scale well: Form a strategy which allows you to learn from small experiments, as opposed to an organization-wide rollout that may impede learning.
“We have a pilot team using Scrum, and we want others to follow suit.”
Even if your organization has a single Agile team who seems to be operating well, it doesn’t necessarily mean they truly adopted an Agile mindset. Simply using Scrum terms and running Scrum events is often conflated with “being Agile.” However, a team with the nomenclature and meetings in place but struggling with key facets such as responding to emerging requirements, self-organizing and owning their processes, working sustainably and delivering working software at the end of a sprint, is merely “doing Agile.”
The bad habits of one team will multiply at scale.
If a single team can’t deliver working software each sprint, they will only be further challenged when faced with integrating their work across teams into a single product increment.
To scale well: Ensure you have one team who is truly succeeding with agility prior to considering scaling to future teams.
“We don’t trust our deployment process.”
Poor engineering practices are one of the primary factors preventing increasing levels of agility. Do you have a team who succeeds at delivering every iteration in a sustainable, quality fashion? Or are they rushing to get a working product out the door, accumulating technical debt and introducing defects as a result?
These problems will only be worse at scale.
For example, consider manual regression testing: If a team is dedicating a significant portion of time towards manual regression testing each sprint, how much time will multiple teams be spending on testing with more and more features being added? If a team’s release process involves a hardening sprint or requires scheduled downtime and late-night deployments, consider what will this look like when adding the risk accumulated by multiple teams.
To scale well: Confirm you have at least one team who fully embraces automation and can release working software without introducing large amounts of risk or overhead before scaling to other teams.
“We need more teams to go faster.”
Assuming your team embraces agility and is consistently delivering high-quality, working software, there is one primary question to ask: Do you really need more teams? If that one team is working sustainably and consistently delighting customers with the end-product and delivery timeline, what is the end goal of adding more teams? The most common answer is to deliver features even faster!
Adding more teams means more complexity.
Teams will need to collaborate across more communication channels, eliminate dependencies in their work across a broader group and promote collective code-ownership of a more rapidly growing codebase. None of these are easy problems to solve and will require a lengthy time investment that needs to be weighed against the desire to deliver faster, especially if your first team is already meeting customer demands.
Another pitfall is having unclear goals for the product itself. In a one-team system, it can already be challenging to ensure each team member is aligned around the goals of an iteration, release, and the overall product. This becomes more problematic when trying to ensure alignment across multiple teams. Teams may drift apart and work towards incongruent objectives without clear goals and consistent reinforcement.
To scale well: Have clear goals for your organization and product prior to adding more teams.
Final Notes Before Scaling
The first two principles of the Manifesto for Scaling Agility give insight into whether you are ready to scale. Focus on succeeding with a single team prior to scaling across the organization. Make sure this team can rapidly and sustainably deliver high-quality, working software. Once they’ve succeeded, ensure you truly need more teams prior to scaling, and if so, establish clear goals to create cohesion. Without these in place, you may not be ready to scale.
Get your fill on Agile scaling with our other posts in the series:
Whether your budget is based on the fiscal year, the school year, or the calendar...
It’s well over halfway through the year, and if you’re like most people, you set a fitness goal. Have you stuck to it? We know how hard it...