Scaling agile from 5 teams to 27 teams within 12 months

As executives, how do you take the capability and good agile practice you are seeing in a handful of team and scale that across the organisation? This is one of the biggest challenges for leadership who what to achieve organisational agility to be able to respond swiftly and pivot to meet changing demand and marketplace forces.

We have been working with a number of executives who were starting to see the benefits from the move to agile ways such as greater productivity, faster deliver and more collaboration across teams. This initial success was seen as a critical way for the organisation to evolve and the CIO wanted all the division to now “move to agile”. So our challenge was to take the learnings from these five initial teams and scale to over 27 teams across branches within 12 months.

There was a lot of concern about the move to agile from some branches and people as they had heard mixed reports on how effective Scrum could be at scale.  Most were skeptical that agile actually worked beyond single teams.

 

Causes of Failed Agile Projects

One of the key reasons agile initiatives are seen to fail is when the culture of the organisation is at odds with agile mindset and agile principles. But the next key factor is management support. So we knew that this change needed to be driven and supported by the leadership team in order to be successful.

Executive Action team to lead the initiative

We explored scaling frameworks and Scrum@Scale seemed to be the most relevant for our context. We had an executive action team (EAT) to discuss priorities and a teams of teams delivering the work across divisional boundaries. We wanted a pattern that would scale as more teams were transitioned to agile.

The Executives became an Executive Action Team and developed a single prioritised backlog for the entire division. We established a pipeline team to support the EAT and manage development of work from strategic ideation to work across the division from inception to delivery.

Templates for work across the Division were created and the major work items across the Division were broken down into manageable components or ‘features’. These features were value ranked by the EAT and a clear priority and focus on value was established.

Executives communicated the intent and why the features were valuable and and then by means of a feature briefing and allocation workshop the highest value work was owned by teams across the Division in according to their capabilities and capacity. This allowed the existing teams to remain intact i.e. to be ‘long lived’ teams which avoided the loss in productivity inherent in teams being broken up and individuals moved between teams. 

Cross Functional Teams 

There was now one divisional backlog so organisational structural boundaries didn’t inhibit where the work was done as teams were cross functional and had all the capabilities within each team to take on the work. This cross functionally was a deliberate strategy form the start of team set up as the aim of the executives was to have the ability to move the work to teams rather than teams move to the work. This would mean that high priority work could be done across branches without the loss in productivity inherent in a major restructure. The cross functional teams could continue to deliver essential features related to their legacy products to keep them functioning in production as well as delivering features for the higher value program/s.

Scaling & Divisional Horizon Planning

At our first horizon we had five teams however they were cross functional and representative of teams across two programs. This was a great start and the first time many of the teams and their leadership had the opportunity to work with other teams across the branch.  Teams were briefed on feature and were able to self allocate features based on their skills and capacity . At this planning days, the cross functional teams committed to what they would deliver in the coming three month of the planning horizon.

In 3 months time, we expanded the Horizon Planning to include another program and 4 addition teams. With the larger group the teams were able to assist each other with the running of the planning days and accelerate the learning process. All teams successfully built their plans for the next horizon. On the strength of the results achieved in the first two planning horizons, the framework was extended to additional programs and teams. Each horizon, additional teams were added and the collaboration, stakeholder involvement and team productivity was achieving the outcomes and delivering more value than the previous 12 months.

Twelve months down the track, Horizon Planning involves 22 teams and over 200 people representing the majority of the Division, participating in the ‘Horizon Planning’ events. Agile is now the accepted and preferred way of working and the organisation is seen as leading the way in achieving business agility and delivering value

About the author

Related Posts:

How do I run a Retrospective?

The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works (including the Product Owner).

READ MORE

Increase your Ability to Pivot with Agile Change Management Practices

Traditional Change Management’s linear approach exacerbates the steepness of the change curve and leads to a “Productivity Dip” as it attempts to manage risk through upfront planning. Agile Change Management addresses this dip by iterative customer feedback to focus efforts on the most important activities, determined by customer value and stakeholder impact and outcomes

READ MORE

What Knowledge and Experience do you need to be an Agile Coach?

To be effective, agile coaches require deep, applied expertise and experience across multiple organisations, multiple projects and industries. As the organsiation scales, the Agile Coaching Development Pathway shows the focus of the role as it scales to more responsibilities beyond being a coach of a single team and provides guidance on what knowledge and experience is required to be an Enterprise Coach.

READ MORE