There are some common, simple elements that I’ve observed when agile works at scale across the variety of medium-to-large organizations I’ve had the good fortune of working with. Making agile work at scale is ultimately about changing behavior, not just for the individual contributors involved, but also for the leaders. Changing individual behavior is hard, so trying to do change at scale is, by definition, even harder. This difficulty leads us as individuals to complex solutions. “It’s hard, so we must need a complex way to solve it”. It’s what we like to do as humans. I’m guilty of it more often than I’d like. So, I’ve tried to distill the research, discussions, opinions, and practical observations that I’ve come across over the years into a simple view of what makes agile work at scale. The standout elements are: Engaged leaders Empowered teams Sharing what’s working Time These are the elements that have been present when agile has worked at scale. When it doesn’t work, there are a multitude of different specific reasons, but you can usually trace it back to one of these elements not being present. I’ll unpack each of these elements below and then walk through what I’ve omitted and why. Common Elements When Agile Works at Scale 1. Engaged Leaders When agile works, it has engaged leaders. Leaders that understand and model the values and principles from the agile manifesto. Leaders that clear the obstacles and make the organizational changes necessary to empower teams to deliver outcomes. It’s also just as important for leaders to be explicit about how agile will be adopted, particularly the parts that won’t be adopted or will be challenging. This sets expectations with the teams. 2. Empowered Teams Teams need to be empowered to deliver outcomes. Bringing this back to the Agile Manifesto, it’s usually about allowing teams to work the way they want rather than imposing processes on them. It’s about allowing them to focus on outcomes over powerpoints reporting on output. It’s about allowing teams to adapt to what they think the customer and the business needs over fixing them to a plan. The teams themselves are also best placed to bring about change, especially the change that is right for them. Most teams know their problems and have ideas on how to solve them. The teams themselves also have the power to change their ways of working, to change their own mindsets, and to influence each other. 3. Sharing What’s Working Often organizations already have pockets of teams and leaders that are shining lights on better practices (doesn’t even need to be agile-related). But, these teams and their mindset, ways of working, and insights often don’t make it beyond their immediate surroundings. Allowing and supporting teams to share knowledge helps put practices into context and helps demonstrate that “yes, it can be done here, here is an example”. 4. Time Lastly, the other often overlooked element when agile works at scale is time. Change takes time and patience. Time to get the right people in the right roles, time for behavior to change, time to iterate towards the right working model for your organization. I’m guessing it doesn’t show up much in frameworks or models because we can’t control it. What Wasn’t Common There are a few ideas that are often put forward as essential to agile working at scale. However, in my observations and research, these weren’t what made agile work. The ideas that aren’t essential to success are: is common to agile working at scale (think SAFe, Scrum, or the Spotify Model). In fact, most organizations that I’ve seen running agile at scale use a variety, and some leave it to the teams. No single process, methodology, or framework There are organizations that have used great coaches to great effect. There are organizations that have made agile work at scale and have done so without coaches, looking instead to their senior leaders and team leaders to mentor their teams. Agile coaches. Most teams that made agile work at scale used a variety of tools and technology. You don’t need to be using the latest technology, although it helps. And you don’t need a specific toolset, there are plenty of options. Technology and tools. Closing Thoughts Broadly, these elements suggest that approaching agile at scale from the top-down bottom-up with the patience to allow time for change to occur might be the right framing to come from. and On reflection, these elements don’t seem unique to agile and could easily be applied to the use of other values systems. Agile isn’t the right solution for every organization and every situation. It’s perfectly okay to adopt the principles and values that work best for your situation. But be honest and clear about this, don’t ignore it. I’d love to see some research that simplifies the common elements; if you have any, please send it through. The book probably has the closest so far. Accelerate The main reason for publishing this was to collect my own thoughts after the discussion generated by my article ‘ Agile is Dead, McKinsey Killed It ’.

Trace

McKinsey’s “Agile Transformation Office” is the Final Nail in the Coffin

Don't talk to McKinsey, talk to Terem

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

How To Make Agile Work at Scale

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps