Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Comparing scaling agile frameworks

Matthew Heusser | Aug. 24, 2015
As larger organizations scramble to apply agile software development methodologies to the challenges inherent in an enterprise-level company, it’s important to understand the pros and cons of the different approaches.

A close-up of a colorful sticky notes on a Scrum board

When the Agile Manifesto hit the street in 2001, it combined several methods, sometimes called "lightweight methods," under a single banner. Scrum, DSDM, ExtremeProgramming (XP) and Crystal were all "agile" in that they matched the spirit of the manifesto. These methods enable small teams to do their best work, getting the paperwork out of the way and bringing the customer into the conversation.

The focus on "small teams" worked for small teams. Today, larger organizations want to move toward more agile methods, too. The methods they’re interested in extend the original methodologies to include larger teams, coordination and oversight. They also introduce risk; an experiment that goes wrong for the entire IT department is much more dangerous than for a team that experiments for a few months.

Most large organizations commit to a single software development framework. Companies that don't – that try to pick and choose the best pieces from each – still want to create a single vision. Either way, making the right choices requires understanding them all, their strengths and weaknesses, when and how they make sense.

So let's talk about them.

What's left from Scrum and XP?

Teams execute a project at a time (at least, we hope they do). Organizations execute programs – combinations of several projects that may overlap. Larger projects are built by teams of teams, or teams of teams of teams, that may work in different physical locations. This type of work requires coordination. Larger organizations typically want a loose-tight coupling – giving the teams freedom to innovate while creating just enough shared expectations to make cross-team coordination easier. Managing the work-in-progress, the planned work and the scheduling of when projects start and stop becomes much more complex.

Then there is the legacy problem of switching to an agile approach. One senior manager of a Fortune 500 hotel chain described his rollout process as “a dozen people on one conference call, taking systems down and back up again, over a five-hour period.”

Scrum, XP, Crystal and the other first-generation development methodologies don’t provide an answer to these questions. We’ll explore how the new methods address these needs.


The popularity of Dean Leffinwell’s Scaled Agile Framework (SAFe) makes finding training or consulting easier. There are plenty of articles, tutorials and videos online, and the certification process is clear and fairly mature. Relatively easy for organizations to transition to, SaFE is also prescriptive – it tells organizations exactly what to do. One program manager from a Fortune 500 company commented anonymously that without understanding the advantages of every piece of SAFe, senior management tends to adopt all of it, including team work, program work, “business epics,” “technical epics,” metrics at every level and a host of other requirements. All those extra pieces can actually add complexity to the organization, which runs counter to the goals of agile adoption.


1  2  3  4  Next Page 

Sign up for Computerworld eNewsletters.