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.
Large Scale Scrum (LeSS) literally scales up the activities in scrum, applying them at the team-of-teams level. In LeSS, large-scale planning takes one or two members from each team to form a second meeting; there is a daily standup that does the same as the daily scrum. The “overall retrospective,” which happens the week after the end a sprint, likewise pulls representatives from each team to discuss large program issues. On top of these, LeSS also adds open space, town hall meetings and other coordination and communication activities.
The formal LeSS Rules for two to eight teams fit on the front and back of a page; the version for product teams of up to a thousand people, LeSS Huge, is not much larger. Craig Larman, co-creator of LeSS, claims that large organizations add unnecessary complexity through single-function groups, handoffs and weak or slow feedback. “Rather than introduce a method which adds a Band-Aid on top of this…we are trying to change the organizational design to create multi-skilled feature teams. These ideas are in contradiction to how organizations are usually set up.
While scrum assumes a team is in flight, it does not include where the team started, or how to make “sprint zero” decisions, such as the base technology platform, the programming language and the architecture. That’s where Disciplined Agile Delivery (DaD), Scott Ambler’s framework, begins, including the inception of the project, architecture and team formation, and the end – production, operational use and support. Where “Scrum” tends to assume a team exists in maintenance mode, DaD does not, giving the team time to decide on the platform, build tools, project schedule and the other challenges that happen for product development more and maintenance efforts less.
Based in Atlanta, LeadingAgile was founded in 2010 and quickly developed an international reputation as a company that provides executive level consulting on large-scale agile transformations. Instead of a “scaling framework,” LeadingAgile provides a "transformation framework" that begins by evaluating a company’s planning goals relative to predictability or adaptability. This methodology also asks if product functionality is expected to Emerge (discovery based on market need) or Converge (delivering specific requirements and features at pre-determined intervals).
LeadingAgile then offers guidance to improve delivery based upon what is driving the business today, while establishing a foundation to achieve where the IT organization needs to be to support the business tomorrow. The company organizes groups of teams into “expeditions,”which move progressively through “basecamps,” developing the skills needed to improve business outcomes over time. CEO Mike Cottmeyer calls this a “transformation roadmap,” because LeadingAgile focuses on aligning objectives, creating transparency and improving business performance over implementing abstract models and rules.
Alternatives to the ‘big’ frameworks
After the aforementioned “big three” and the work of LeadingAgile come a host of smaller scaling frameworks and methods. Sam Laing’s Scrum Lean in Motion (Slim), for instance, is designed to complement LeSS. This author is the creator of Sustainable Cultural Agile Release in the Enterprise (SCARE), which applies the theory of constraints to agile adoption and is based on patterns that have emerged from successful scaling projects. Ron Quartel’s FAST Agile, recently announced at the Agile Roots conference, focuses on improving the integration speed of large groups (and reducing waste) through the use of near-continuous open space meetings for planning.
If you could think of managing a large IT organization as one portfolio of work as a kind of scaling, then another option to consider is Johanna Rothman’s work on The Project Portfolio and Program Management.
What the scaling frameworks are missing
Adam Yuret, a portfolio management and strategy consultant, points out that the scaling frameworks cannot prevent a senior executive from personally poring over specifications and bug lists. He adds that “Not only is that not the best use of their time, but when you have that as an example, it leads to middle-management doing the same thing, which eventually ends up with programmers getting conflicting directions from multiple people.” Yuret’s fix is not a framework, but strategy deployment, where leadership communicates clear strategic intents, then trusts the teams to deliver on that strategy however they see fit.
A few other leaders, including Arlo Belshee, Matt Barcomb and Alistair Cockburn, have gone on to propose alternatives to the “scaling framework” idea.