Toggle Menu

Insights / Agile Transformation / Agile Scaling: Debunking 3 Common Misconceptions

June 04, 2019

Agile Scaling: Debunking 3 Common Misconceptions

4 mins read

Your organization implemented Agile practices and saw success in delivery speed, employee engagement and customer happiness. Now your boss wants to use these practices across the organization, which begs the question: Can Agile scale? The short answer is that while Agile can scale to the point of transforming organizations as a whole, there are some misconceptions we must tackle on Agile scaling before taking the leap.

First, what do we mean when we say Agile scaling? Agile scaling is the practice of running Agile methodologies across multiple teams. This can be multiple Agile teams working on one product, or multiple teams working on multiple products; these two examples are considered product delivery scaling. There is also organizational scaling – specifically, Agile concepts are scaled horizontally (across) and vertically (up) through an entire organization. At this stage, we are taking Agile concepts outside of software development and into different divisions of the organization.

Before jumping in feet-first, here are three common misconceptions you’ll want to address:

1. Agile scaling = No rules

We’ve heard people say, “Agile means there are no rules,” and apply the same myth to scaling. Different approaches in Agile scaling have their own rules and set up different human systems. An example of this is the SAFe approach.

SAFe (Scaled Agile Framework) is a set of organization and workflow patterns meant to guide enterprises in scaling lean and agile practices. SAFe promotes alignment, collaboration and delivery across large numbers of agile teams. Developed by and for practitioners in order to Agile software development, lean product development and systems thinking, SAFe can be very prescriptive in that they tell you exactly what to do.

In some instances, SAFe may be too prescriptive and not suitable for many large-scale agile projects; your organization will have to look to other approaches instead.

2. Agile scaling is one size fits all

We’ve heard people say, “If it worked for one team, it will work for every team.” Agile scaling has multiple approaches based on the size and complexity of the project(s) or organization. We already covered SAFe, but below are other frameworks in which Agile can scale.

Kanban: Management method around the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively and is based on 3 principles:

  • Visualize what you do today (workflow): Seeing all the items in context of each other can be very informative
  • Limit the amount of work in progress (WIP): This helps balance the flow-based approach so teams don’t start and commit to too much work at once
  • Enhance flow: When something is finished, the next highest thing from the backlog is pulled into play

LeSS: Provides two different large-scale Scrum frameworks: LeSS (Up to 8 teams of 8 people each) and LeSS Huge (Up to a few thousand people on one product). Most of the scaling elements of LeSS are focused on directing the attention of all of the teams onto the whole product instead of “my part.” Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:

Scrum at Scale: Framework where Scrum team networks, operating consistently with the Scrum Guide, can address complex problems while creatively delivering products of the highest possible value. These “products” may be hardware, software, complex integrated systems, processes, services, etc., depending on the domain of the Scrum teams.

3. Agile scaling is just for IT teams

We’ve heard people say, “Agile practices just apply to the technology delivered.” Agile started as a way to better align the business and IT departments within organizations, but Agile scaling takes this emphasis on alignment even further. For teams to see the benefit, the non-IT department must adapt their practices and increase cross-organization collaboration. Frameworks like SAFe and LeSS can work for non-software but include a lot of software-specific considerations. Kanban, however, originated in the manufacturing industry and involved almost no technology teams.

Some reasons non-technical teams are choosing Agile scaling are:

  • Aligning as a team
  • Focus on priorities
  • Managing interruptions
  • Increased transparency

Now that we covered different examples of Agile scaling frameworks and debunked some misconceptions, the next steps will be deciding which framework works best for your organization.

 

Get your fill on Agile scaling with our other posts in the series:

 

Do you want to learn more about how to successfully scale Agile? Download our Agile Scaling eBook now!

Download eBook Now

You Might Also Like

Resources

Simplifying Tech Complexities and Cultivating Tech Talent with Dustin Gaspard

Technical Program Manager, Dustin Gaspard, join host Javier Guerra, of The TechHuman Experience to discuss the transformative...

Resources

How Federal Agencies Can Deliver Better Digital Experiences Using UX and Human-Centered Design

Excella UX/UI Xpert, Thelma Van, join host John Gilroy of Federal Tech Podcast to discuss...