Sunday, October 27, 2013

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of value at least every 30 days. One voice speaks for the customer. A coach and change agent helps the team and the organization improve.

Scrum also creates a context where the Agile values and principles can thrive. "We are uncovering better ways of developing software by doing it and helping others.... We value individuals and interactions over processes and tools.... Our highest priority is to satisfy the customer through early and continuous delivery of valuable software...." As anyone who has attended my Agile company workshop knows, if you use the values of the Agile Manifesto as a guide, you generally make pretty good decisions about how to run your company.

So how do SAFe, DAD and LeSS stack up for scaling Scrum and Agile? I will look briefly at each one, by examining what it claims to be, what its core values are, and give an assessment of how its values and principles correspond to those of Scrum and Agile. For reference, let's start with the Waterfall.

Classical Management or "Waterfall"

IMHO, the waterfall is simply adapting the management structures created to manage the automobile industry in the early 20th century to software. Assembly lines assemble components in steps defined by the engineers and managers who watch over unskilled and recalcitrant workers. Companies seek to maximize outputs and profits, and minimize costs. According to Steve Denning, the underlying principles are managers as controllers, coordination through bureaucracy, optimizing utilization, and communication primarily as a from-the-top broadcast.

This approach worked extremely well until about the 1960's or 1970's. Since then it has come increasingly under strain. Deloitte's Center for the Edge predicts that 70% of today's Fortune 1000 companies will not be there 10 years from now. This model doesn't work any more.

Agile and Scrum represent a rejection of this approach for the simple reason that it fails spectacularly when applied to producing software. This also makes clear why scaling Scrum is such a challenge for organizations. It is based on values and principles that are incompatible with the rest of the organization.

Summary: On a 0 to 10 scale, how likely am I to recommend this approach to scaling Scrum? 0.

It's failing. Time to move on. (And yes, I know, most every company on the face of the earth is organized this way. But look at the exceptions: Spotify, Guidewire, Morning Star, WL Gore. There are better ways to organize your company.)

Scaled Agile Framework (SAFe)

The Scaled Agile Framework has been getting a lot of attention lately. There is a budding certification program, a roadmap for implementation (with lots of training), and support from various established companies (like Rally). As I write this, the SAFe Academy is listing 5 trainers and claiming over 1000 certifications have been earned at their trainings.

SAFe is "an interactive knowledge base for implementing agile practices at enterprise scale." The SAFe big picture addresses the enterprise at three levels: Team, Program, and Portfolio. At the Team level, SAFe looks a lot like Scrum, including of course XP practices. Not every sprint necessarily produces a potentially shippable increment, but this should happen frequently, possibly after a hardening sprint.

At the Program Level, the efforts the Agile teams are aligned and integrated to serve the needs of the enterprise and its stakeholders. SAFe provides a fair amount of detail on how to do this. The Portfolio level provides similar product and goal alignment between the investment levels and the operational levels of the organization.

What does SAFe value? According to the Core Values page, "we know that Lean thinking, the Principles of Product Development Flow and the extensive benefits that Agile development (Agile Manifesto, Scrum, XP technical practices, Kanban) all play important roles in defining the principles and practices of SAFe," but SAFe "really values" Alignment, Code Quality, Transparency and Program Execution.

This is the statement that worries me about SAFe. The values, principles, and practices that enable Scrum, Agile, and Kanban to work their magic, are important, yada, yada, but subjugated to "what we really value." There is little reason to challenge Code Quality and Transparency, but Alignment and Program Execution mean the development teams are expected to do what top management tells them; the difficulty that "mere mortals" have convincing top management to pursue new innovations is a well documented cause of large organizations' vulnerability to disruptive innovation.

Summary: On a 0 to 10 scale, how likely am I to recommend SAFe for scaling Scrum? 4.

(Update 19-May-14: I have raised my recommendation from 4 to 6. Still a "yes, but", but somewhat less skeptical than before. Read why: Three Things to Like about SAFe )

It's better than waterfall, and existing managers will feel at home. But its lack of commitment to Agile Values, especially continuous learning and people over process, means that there will still be managers making decisions over the heads of people who understand the problem better than they do. This does not bode well for the acceptance in the trenches of SAFe and it will be interesting to see how many of SAFe's reference customers are still boasting about it 5 years from now.

Disciplined Agile Development (DAD)

After I got over the huge IBM logo on the cover page, I found quite a bit to like about DAD. This process framework is "a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven, and is enterprise aware." What does DAD value? It's top four priorities are: 1) People first 2) Learning-oriented 3) Agile and 4) Hybrid.

Hybrid means that DAD also draws on other, more traditional sources, especially the various flavors of Unified Process for governance and life-cycle management. Projects are divided into three phases, Inception, Construction and Transition. Compared to Scrum, DAD puts more emphasis on architecture and technical risk reduction through the designation of an Architecture Owner. (DAD also changes many of the names of Scrum, so the Scrum Master is now the "Team Lead").

Back in 2008, I wrote that people and responsibility were missing from the Rational Unified Process. This latest evolution is clearly a huge step in the right direction.  The notion of "Potentially Consumable Service" as opposed to "Potentially Shippable Product" is intriguing.  OTOH, our understanding of risk has grown substantially since the days of RUP to include Market Risk and Social Risk, among others. Furthermore, this approach does not look very close to the way successful startups (Facebook, Spotify, Guidewire) are actually scaling up.

DAD now has a certification program. As of this writing, there are 9 trainers and 29 certified DADs.

Summary: On a 0 to 10 scale, how likely am I to recommend DAD for scaling Scrum? 7.

Much good stuff, and nothing obviously evil. My own experience both with technical risks and chief anythings (developer, architect, project leader, etc.) lead me to be skeptical about those aspects, but not so skeptical to throw the baby out with the bath.

I almost gave DAD an 8, but I lowered the score for pitching IBM tools in the white paper (compare to LeSS which encourages Open Source).

Large Scale Scrum (LeSS)

"Large-scale Scrum is regular Scrum applied to large-scale development." Craig Larman and Bas Vodde set out to manage large projects while staying within the constraints of vanilla Scrum. They have developed two frameworks depending on the size of the project. Because they remain true to the constraints for Scrum, Large Scale Scrum cannot be considered a practice. It is an organizational design framework.

Framework-1 is for projects of up to around 10 teams. The basic roles are unchanged, but some the of the meetings are changed and some are replicated at the-cross team level. For example, Sprint Planning 1 may be held with representatives of each team, rather than all members of all teams. Similarly, a cross team retrospective with representatives of each team facilitates overall improvement. Teams are organized as Feature-Teams. Other inter-team coordination meetings may be added, in the form of Scrum of Scrums or Open Space meetings.

Framework-2 is designed for even larger projects. Framework-2 adds an additional role, the Area Product Owner, who assumes product Ownership of a major section of the product. At this point, an Overall Sprint Review and Retrospective is also added to ensure overall product consistency and process improvement.

Beyond Scrum, there are many technical practices which are helpful and encouraged to enhance coordination: Continuous Integration. Internal Open Source (any source can be modified by anyone), Team-controlled build systems. These become even more important for multi-site projects. Pervasive video, Free Web 2.0 tools (skype, google docs) and open source tooling reduce the friction between teams.

Summary: On a 0 to 10 scale, how likely am I to recommend LeSS for scaling Scrum? 9.

One the plus side, LeSS is clearly in the Scrum and Agile tradition. It is the simplest of the three approaches and makes only a few changes to vanilla Scrum. When I look at Spotify, an organization that has scaled from 6 to 1200 staff members, I see a company architecture that is very close to LeSS. It will be a very natural approach for small organizations that are scaling up as they grow.

As with any Scrum transition, moving to LeSS is a complete architecture-redesign. Informed buy-in is the key to acceptance. I can imagine in larger companies, that could be a challenge.

Overall Summary

How likely am I to recommend these approaches?
  • Waterfall: 0
  • SAFe: 4
  • DAD: 7
  • LeSS: 9
Of these approaches, Waterfall has by far the best training infrastructure. Every year, Business Schools around the world churn out thousands of MBA's who know how to manage by the numbers, but have never heard of Agile, much less thought about Agile forms of management.

SAFe comes in a close second. With its training academy, licensed trainers, and traditional management-friendly approach, it is clearly resonating well and is poised to do well in the market. (The reports I have gotten on the quality of the courses is strongly mixed. Some say horrible, others seem to be eating it up).

Will SAFe be enough of break with the waterfall to save their customers from being part of the 70% that won't be in the Fortune 1000 ten years from now? Fundamentally it's people separated by two or three layers of management from the real world setting direction for those who get it. Not promising.

On paper, DAD has come a long way since RUP. It's values are more in sync with Agile than ever. Today, DAD has more trainers than SAFe, but hardly anyone has actually taken the course, so is it really resonating with the market? The other question I have is whether its practitioners have really left their RUP days behind them. Do they really believe their new-found values? However, given the choice between SAFe and DAD, I would clearly chose DAD, especially if your coaches really understand Agile and the values it represents.

LeSS is more two guys with a book at the moment (3 books, actually). Their approach is sound, but there is no institutionalised marketing. While the Scrum Alliance currently lists 57 Certified Scrum Coaches, the "Black Belt" of the Scrum world, this is not strictly speaking a LeSS certification, nor are any LeSS courses or certifications being offered. On the other hand, that's about where Scrum was 10 years ago. People reading books, and deciding to change. For my money, it's time to start reading Larman and Vodde.


P.S. This article represents a first pass at comparing the frameworks. Does it sound right to you? I would love to hear from practitioners of these approaches to share the experiences and/or improve this article!





10 comments:

Darkflib said...

"Summary: On a 0 to 10 scale, how likely am I to recommend DAD for scaling Scrum? 9."

I believe should be LeSS

Peter said...

Oops, you're right! Thanks, Darkflib, for pointing this out.

Peter Hundermark said...

Hi Peter,

Nice post and at the right time. This debate is not going to go away.

I'm inclined to agree broadly with your scores. I'm not much familar with DAD, but Scott is not teaching a whole lot of wrong stuff, afaict.

Some people I know suggest that SAFe enables them to have conversations with people who think Agilists are dancing with the fairies at the bottom of the garden. This may be so. However I have deep scars from the RUP and know in my bones that people who begin with SAFe will not give up the (illusion of ) control they value so highly. So it will mostly end in tears, just like the defined processes that precede it. Neverthleless Dean and his cohorts will laugh their way to the bank. SAFe is not all evil, but, as a friend mine says, there is way too much 'process voodoo'.

And I'm right with you: people need to start reading Larman and Vodde. Then get out and try out some stuff. Amplify the good and dampen the bad.

P

Andy said...

How about Agility Path / Scrum for the Enterprise?

Peter said...

Hi Andy,

Good question!

I also had a conversion during my CSPO course yesterday which gave me some other insights into SAFe and how SAFe is already a huge step for some organisations. So I plan to review SAFe again and take a look at Agility Path in a later article.

What are your thoughts on Agility Path?

Best,
Peter

Rainer Grau said...

Hi Peter,

What a disappointment to me. I took a deep look in all these models as well (by the way you forgot Agility Path by scrum.org). I came to a total different result.

My result is: There is no winner or looser, there is a "one fits best in this context" and "the other fits best under these constraints".

Are we once again falling back in the Silver Bullet mentality?!!

Please do not! Please do not fall back in the mid-ages of this is better than that on an absolute grading scala.

Kind Regards
Rainer

Peter said...

Hi Rainer,

Yes, I need to look at Agility Path.

I'm sorry you are disappointed by the review. I did not say, one is better than the other. I indicated how likely I am to recommend the approach. Think Net Promoter Score.

As a coach, I often say, "It depends." As a consultant, I know there are pros and contras to every situation. My ability to push customers out of their comfort zone is limited by my fear of losing the contract - how many of my developers are under contract to the customer? A tricky situation and this is why I am independent.

As a pundit, your job is to call it as you see it, and that's what I have tried to do. The biggest companies are dying off, and pretending to do the new stuff while really doing the old stuff isn't going to save them.

So yes, there are pros and contras to every situation. For some companies SAFe might be a step in the right direction, and it is surely better than what they are doing now. I think they can do much better if they choose to.

Best,
Peter

Alan Shalloway said...

Peter:
I am afraid you are grossly misinterpreting things with the statement "Alignment and Program Execution mean the development teams are expected to do what top management tells them;" SAFe works on an explicit pull system. People work on what they feel they can commit to. Alignment means that they work in a structure that keeps them aligned - keeps their dependencies visible and that they work on them together. Yes, management helps this. But a higher view is needed for this. And these dependencies are discovered by the teams.

Most Scrum afficionados take the peer-to-peer approach (Scrum of Scrums) which has a poor track record. It seems that any time a higher view is presented people complain that the teams are subjugated to management. That is not what SAFe suggests and it is this very attitude that makes it difficult to scale Scrum.

SAFe works because it takes an holistic approach and creates partnership between management and teams. Teams are not controlled by management and management does not have the sole role of removing impediments the teams have discovered.

Rather management's role is to create a structure within which self-organizing teams can work effectively. Management helps create a common vision.

Pete said...

Alan, I think you've hit the nail on the head. My problem with SAFe is not really with the content, but that it is far too easy for people to misunderstand it. To organisations looking to 'do agile' without actually going through too much pain it seems as though they can just buy SAFe and the job is done. Just like RUP, where most implementations were RINO (RUP in name only). I think the best thing that SAFe could do is re-draw all those lovely 'shiny' diagrams as whiteboard sketches, to make the point that they are not fixed, just examples, and YMMV.

Alan Shalloway said...

Pete:
And you hit the nail with this comment. SAFe is not a panacea. It is truly a framework. For a variety of reasons (that I agree with) the practices of SAFe have been injected into the framework & are not always explained that they can be changed. But this has a certain risk to it.

The challenge is that there is only a certain rate at which we can define and explain. Our approach to Agile at scale now should be to come up with frameworks and patterns that work and learn the principles on which they are based.

While SAFe is far from complete in its explanations, it at least explains (in the Leading SAFe and SPC training anyway) what the principles on which it is based and grows from their. To date, it is the only approach that has attempted this - so not being perfect should not be expected.