Comparing scaling agile frameworks
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.
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.
[Related: Learning Scrum: an empirical approach to product development]
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 Scrum, 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 contraction 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 need 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.
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.
[Related: Johanna Rothman: Getting serious about portfolio and program management]
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.
In 2008, Arlo Belshee won the Godon Pask Award, the official award of the Agile Alliance for contributions for the practice. After earning the Pask Award, Belshee moved on to a coaching/teaching position at Microsoft. That experience informed his 2013 blog post, Scaling Agile the Easy Way, in which Belshee claims that scaling objections have it backwards; that when companies develop true multi-disciplinary teams that can regularly ship software, the problems go away. As Belshee explains it, this is what happens once teams have that competence:
Belshee is not alone.
Matt Barcomb, an independent Agile coach and former VP of product developer for Taxware, points out that while the problem of “scale” sounds hard, it typically means one of three things: spreading, coordination or alignment. As Barcomb explains it, what we think of as the big, organizational problems are fairly easy to understand:
Barcomb’s approach, like LeadingAgile, is to identify where the gap is and to work on that, making small improvements to skill and culture along the way.
Finally, we have Alistair Cockburn, who organized the Snowbird Conference that created the Agile Manifesto, and was known as one of the leading thinkers on the topic before and after that conference.
Initially hesitant when approached about scaling agile frameworks, Cockburn went on to talk about something he called the "Heart of Agile.” In a nutshell, at the enterprise level, the heart of Agile asks these questions:
These questions are designed to help an organization decide which small change to make next in the pursuit of Agility, and to ground that change in the context of this organization and this moment, instead of relying on someone else's revealed wisdom. In short, they focus on responding to change instead of following a plan.
Cockburn subsequently elaborated on his blog with a post titled Using the Heart of Agile on the problem of scaling.
The dominant framework, SAFe, provides a way for a large IT group to organize itself as teams of teams of agile teams. LeSS does the same by focusing on improving communication between the teams. Belshee suggests starting by making high-functioning Agile teams that can ship working software on demand, and the scale problems disappear, while the other consultants tend to recommend small changes to adapt an organization toward a more Agile ideal.
Once we dig past “scale” to the real problem your company is most interested in solving right now, then one of these solutions might make more sense than the others.