Scaling Agile Ain’t Easy, But It’s Necessary For Better Project Management
Chances are, you’re already familiar with the basic concept of Agile project management: a small team works in time-boxed sprints, frequently demoing features and integrating customer feedback, to iteratively deliver a customer-centric end result. Since its origins in software development nearly two decades ago, Agile has been embraced by companies big and small in a wide range of industries and applications. To its adherents, Agile is much more than a methodology: it’s a guiding set of principles and values. Some have embraced Agile so wholeheartedly, they rock Agile t-shirts, hats, and even tattoos.
But scaling Agile for larger projects and larger organizations doesn’t inspire clever swag or inked dedication. To make it work, you’ll need to build in additional roles and structures to facilitate coordination across multiple teams while also maintaining the flexibility that’s core to Agile. That’s a tall order. There are frameworks to scale Agile, but they can be intimidating at first glance.
Why Agile Must Scale for Large Projects
To understand why organizations need to scale Agile for larger projects and what that might look like, let’s start with a simple hypothetical. Let’s suppose you are a home owner and your project is “home improvement.” If the project is simple—you just want to replace the floors—it could be handled by one Agile team of flooring experts. The foreman is the Scrum Master, who keeps the team on track and is responsible for solving problems. The team works in sprints and demos progress at major intervals to make sure you’re happy.
But as any home owner knows, home improvement is rarely simple. Let’s say your home improvement project involves replacing the floors, replacing the windows, repairing siding, and remodeling the kitchen. Now, you have a cross-functional project requiring multiple teams with different skillsets. You still want the teams to be Agile. You want them to demo working features and incorporate your feedback. You don’t want to burden them with rigid schedules or unnecessary meetings that just drive up costs.
But if you unleash all the teams to work independently, you’re bound to run into problems and waste. The kitchen team might drop a slab of granite on your newly-installed floors, the siding folks might end up twiddling their thumbs (on your dime) while they wait for the window people to finish up, or the teams might independently purchase supplies that should have been bought in bulk.
That’s not smart or cost-effective, and that’s why you hire a general contractor. The contractor coordinates the teams, checks in on the work, and provides you with updates and opportunities to give feedback. Simply put, to deliver a large and complex project like this, you need another role and some structure to make sure you get an end result that’s good for you and your wallet.
Key Scaled Agile Concepts
The home improvement hypothetical can help us understand the core concepts of the Scaled Agile Framework® (SAFe®), one of the most popular approaches for scaling Agile. At the team level, SAFe is just like Agile Scrum. Each team (the flooring team, window team, etc.) has a Scrum Master (foreman) and works in sprints. At the program level, SAFe introduces additional structures:
- Agile Release Train (ART): a team of teams working on the same project (your flooring team, window team, siding team, and kitchen team)
- Release Train Engineer (RTE): a role that coordinates the ART (your general contractor)
- Potentially Shippable Increment (PSI): a time-boxed project chunk, typically five sprints long
With SAFe, a project begins with a meeting of the ART to identify what features they can deliver in a PSI as well as any interdependencies or potential complications. Think of this as the contractor and teams meeting to define what parts of the home improvement project they can deliver by a deadline. Then, the teams break out and start to work on their parts of the project.
Every week, the RTE and Scrum Masters (the general contractor and foremen) meet to discuss progress, mitigate problems, and identify interdependencies. At the end of the PSI, the ART has a “hardening sprint” where all members of the ART join together to demo features, verify that they’re meeting objectives, identify continuous improvement opportunities, and plan the next PSI.
It Can Be Done
Some Agile purists say that scaling Agile doesn’t work, but the proof is in the pudding. Thousands of organizations—even massive companies and government entities—have successfully scaled Agile, and they’re seeing benefits in time-to-market, defect reduction, productivity, and employee engagement. To learn more about SAFe and other flexible project management methodologies, read our whitepaper, Introduction to Flexible Project Management.Tweet