The Road to Scaling an Agile Organisation
Leaders in Tech is a group of senior execs and thought leaders who get together to discuss current tech trends, share knowledge, learn new things and network. We have created thriving local communities in Munich, Stuttgart, Reading, UK, and now we are excited to expand to Berlin.
Our Berlin launch event will be held at VW Digital Labs on 23rd November. Eric Heymann, Vice President Engineering at FlixMobility Tech GmbH (FlixBus), will give an interactive presentation on the journey to a fully independent, agile team.
There are numerous ways to scale a truly agile team. Eric will present his own perspective at the event but here are some considerations that Austin Fraser consultants have encountered recently.
The prevalence of Agile methods in the software industry today is obvious. Most major organisations can tell you about their approaches to implementing the values and principles found in the Agile Manifesto. Published frameworks and methodologies are rapidly maturing, and a wave of associated terminology is part of the modern lexicon. The challenge now is to scale Agile to work in complex settings with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines.
What is scaling?
Many people understand Agile concepts through the illustrations offered by widely adopted methods such as Scrum. These team-focused development processes embody patterns of Agile behaviour and offer concrete implementation examples. If you want to achieve success with Agile methods in large-scale development efforts, you might be tempted to view the challenge as simply a matter of tailoring Scrum to work with larger groups of people. What we are learning from the experiences of major programs undertaken by large businesses is that this view oversimplifies the real work to do.
Below are some key attributes in successfully applying Agile methods. These attributes deserve attention as organisations architect the way their programs will implement Agile processes:
Keeping teams small can enable every member of the team to have all the information needed to effectively contribute to the work.
Specialisation of roles.
Limiting the extent of specialisation among team members is something that most Agile proponents strive for. Agile program managers are instead encouraged to move away from a team structure where people focus only on one speciality.
Iteration length has received much attention among those adopting Agile practices. The challenge of implementing shorter iterations may be one of the biggest challenges in scaling Agile to build larger, more complex software systems.
Coordinating the contributions of multiple teams to a single product delivery cycle can be hard, no matter what development method you choose. If your teams use different iteration lengths, you will want to look for ways to synchronise the end points of iterations. If teams deliver product features or components (or slices of the architecture) at different times, the cascading effect of rework as integration occurs with each new arrival can lead to a chain of rework-driven cycles that amplify over time. Postponing integration while lagging teams finish their work may lead the early finishing teams to move on to other projects without the benefit of potentially course-correcting feedback from those they’ve just completed.
At scale, most Agile development efforts are structured into a series of releases, each built up from a number of iterations. Typically people set a release to contain four to six iterations, which often fit into a calendar quarter (e.g., four iterations of 3 weeks each, or six iterations of 2 weeks each lead to a 12-week cycle). When scaling Agile methods it is useful to consider synchronising with business cycles (e.g., quarterly reporting requirements or cadence driven by earned value management systems), as budget cycles and other external dependencies may follow these patterns.
In scaling Agile, the long wait for feedback is a bigger problem than the heavy weight of documentation. The priority focus should thus be on working in small batches, prioritised by value, with rapid feedback from the user.
Product owner role.
The product owner role in Scrum is a pivotal element to successful implementation because it provides the development team with a single voice of the business. Even among teams not using Scrum, we are seeing a product owner role – or some variant of it – used to communicate priorities based on value for users.
Agile development relies on collaboration with the users of the system (or someone who represents the user base) in a way that many other development styles do not. Rather than basing all work on an up-front comprehensive requirements specification, engage the users to help refine the development team’s understanding of what is needed – at a time when that discussion will have the most beneficial effect.
While a number of published frameworks are available, each has strengths and weaknesses. The challenge faced by many in the Agile community today is how to scale Agile to succeed in complex settings, with larger teams, larger systems, longer timelines, diverse operating environments, and multiple engineering disciplines.
If you would like to find out more about scaling agile teams, discuss this and other current trends with your peers, and expand your network, then register for the upcoming Leaders in Tech Meetup on Thursday 23rd November: https://www.meetup.com/Leaders-in-Tech-Berlin/events/244144570/