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.
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 extending 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.
What 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 the 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.
Scaled Agile Framework (SAFe)
SAFe is one of the leading frameworks for scaling Agile at the enterprise-level. It follows lean-Agile principles to help businesses continuously and efficiently deliver value on a regular and estimated schedule.
SAFe provides guidance at all levels of software development: Team, Program, LargeScale Solution (Value Stream), and Portfolio, so as to align enterprise-level strategies with the team working on a solution. Here is how it manages development agility at the enterprise level.
In a general Agile framework, there is a Scrum and Kanban team that comprises a development team, scrum master, and product owner. Such a framework works when there are 2-3 teams with 5-9 team members.
When the number of teams extends (say there are 10 teams), a single product owner and a scrum master for a team are not sufficient enough to manage requirements and facilitate the teams. To handle multiple teams at a larger scale, there is a program layer in the SAFe framework. The program layer has roles like Product Manager who provides guidelines to all the product owners working for individual teams. Then, there are Release Train Engineers who act like chief impediment officers for all the teams. A System Architect defines, communicates, and shares an architectural and technical vision for the Agile Release Train (ART).
Agile Release Team (ART) is a name given to multiple development teams at the program level. These teams deliver their work incrementally in 8-12 weeks long sprints. This time box during an Agile Release Train is called Program Increment (PI).
At a large stream level, there is a value stream engineer to manage Agile Release Trains (ARTs), Solution Manager to define vision and roadmap for the solution, and a Solution Architect for the technical and architectural vision of solution under development.
Moving up, at the portfolio level there are epic owners and enterprise architects who define the base for a portfolio of solutions. For this, a Portfolio Kanban is used that defines an MVP of the solution, a lean business case, and starts implementation on approval. An enterprise architect works across value streams and programs to help provide the strategic technical direction that can optimize portfolio outcomes. The enterprise architect often may act as an epic owner for enabler epics.
SAFe is a prescriptive framework. It organizes and structures how software development activities should be performed and in what order. The SAFe framework can be adopted for large scale projects that have at least 50-125 team members in it.
Large Scale Scrum (LeSS)
LeSS is a scaled version of a one-team Scrum, which focuses on directing the attention of all the teams towards the product. It maintains basic practices of Scrum but has some basic differences from regular Scrum meetings:
- There is a product backlog, but for the product and not for the team
- There is only one Definition of Done for all the teams
- All teams are in common sprint to deliver a common shippable product
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 of 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.
There are 10 roles that a DaD project has. While five of them are primary, five are secondary. The primary roles will occur, regardless of the scale that a project has; while the secondary roles are added to the primary roles as the demand or scalability expands.
The reason why the number of members in a Scrum and DaD varies is the difference in scope that both the frameworks handle. Scrum has its focus on leadership and change management while DaD focuses on the entire delivery lifecycle. Thus, with a larger scope, there are more roles in DaD.
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.
Heart of Agile
In a nutshell, at the enterprise level, the heart of Agile asks these questions:
- Independent of anything else going on, how will you increase collaboration?
- Accounting for everything else going on, how can you increase trial and actual deliveries to consumers?
- How will you get people to pause and reflect on what's happening to and around them?
- What are some experiments your people will do at different levels in the organization to make a small improvement?
These questions are designed to help an organization decide which small change to make next in the pursuit of Agility, and to the 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.
Putting it all together
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. 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.