Jazoon Side Event
15-10-2013Philipp Engstler on the Rise and Temptation of an Agile Company
14-11-2013Recently 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)
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.
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)
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
26 Comments
"Summary: On a 0 to 10 scale, how likely am I to recommend DAD for scaling Scrum? 9."
I believe should be LeSS
Oops, you're right! Thanks, Darkflib, for pointing this out.
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
How about Agility Path / Scrum for the Enterprise?
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
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
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
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.
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.
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.
Peter,
very good post analyzing those 3 frameworks. The approach is also good (how useful to scale Scrum?) instead of comparing them, since they are different things.
I am DAD certified, it's the FW I know the best (I have my Rational days behind me), although actually I first learnt about SAFe (from the original Leffingwell requirements book). LESS is newer to me but supported by related well-known success stories such as the Spotify case.
This week I will be speaking at the Conference Agile Spain 2014 in Barcelona where I will discuss whether to use a framework or not to scale agile (of course I would!) and which of those different approaches would be the best.
In my opinion, I would add up things from the different FW:
1. From LESS: All
2. From DAD: The hybrid approach and it's lifecycle
3. From SAFe: "the organizational layers" it proposes (but clearly redesigning it to incorporate the technical and functional feedback from the teams to the management).
Alex Ballarin / http://www.itnove.com
Peter,
I am late to this party, I stumbled across this post. Nicely done. However a few updates:
– While Scott and I wrote that white paper while he was at IBM, it is not IBM IP. In fact, IBM has no involvement with DAD at this time. They are more focused on SAFe. You may be pleased to know that DAD doesn't pitch any tools 🙂
– I am glad that you understand that DAD has little to do with RUP. It does incorporate some UP ideas such phases (short ones please!), lightweight milestones and the need for a focus on work that mitigates risks early. While the basic/Scrum based lifecycle depicts Inception and Transition phases, we try to make it clear that where possible these should be reduced and preferably eliminated as orgs move towards using a continuous delivery lifecycle. But the reality is that some/most orgs are not there yet, so the basic lifecyle acknowledges the reality, while striving to be as agile as possible.
– For those that criticize DAD I usually find that they haven't taken the time understand it. For instance it is a process decision framework first, scaling second. We provide guidance to address all sorts of context (whether they be agile or lean) and add some enterprise discipline that really does need to be in place to effectively scale.
– SAFe and DAD are complementary
– Your link to the IBM DAD white paper isn't the best source for info on DAD anymore. The blog at http://www.DisciplinedAgileDelivery.com provides far more, up to date content
– when you wrote this, our book had just come out and it was true that it was hard to find much use of DAD. I am happy to say that it is quite different now. There are many large organizations that are not only using it on a few projects, but are rolling out the framework across their entire enterprise.
Mark Lines
Co-creator of DAD
I am a bit surprised by the outcome.
– What I like about SAFe is that Program level uses Scrum concepts: Scrum of Scrums. And at Portfolio level it uses Kanban concepts. So it becomes truely iterative.
– What I dislike about DAD is the phases. It makes it very tempting to continue thinking in waterfall.
– What I dislike about DAD and LeSS is that they still think in terms of projects. Most organizations I work in consist of programs (consisting of collaborating projects) and platforms (reused architectures and implementations). In DaD and LeSS there is little definition about how projects collaborate. Scaling is IMHO primarily on collaboration between projects in a larger organization.
So overall, I would expect a higher score for SAFe than for DAD or LeSS.
And yes, I understand the discrepency between the Agile values and the SAFe values. But I'd rather have a model that works for a complex (scaled) organization than a model that fits the statements of a manifesto.
Hi Frank, nice to hear from you, been a while.
However, I believe that you have misunderstandings about DAD. We absolutely do not recommend a project approach, we much prefer a product or release strategy. We are quite clear that we wish companies to reduce and ultimately eliminate the phases, as they move towards using the Continuous Delivery lifecycle where possible. The fact that Phases are present in DAD reflects the current reality of many if not most organizations however.
If people are applying DAD in a waterfall fashion, that is a problem of execution, and lack of understanding, not the framework.
The original post was written a copule of yeara ago, so now, I liek to hear about current situation of SAFe, DAD and LeSS in real situations. What is the current exposure of each one.
There is other consideration. Mark wrote that if people decide to use waterfall inside any scrum framework is people´s fault not the framework´s. I think that a framework is omething like an enforcement, and I think Scrum is not a Framework, it is a set of good practices tied in such way that if you follow them you have less chance to fail.
The best one, no matter what it demands, it is the one that do not forcé to use an specific set of tolos or programming language and most important, something that allows to get ridd off waterfall problems, leaving far away the tradicional Factory problems that have populated software projects. Not even Scrum has covered at least 50% of successful projects. this is a proof that we still need a better approach for software development.
great article
have you done an update since 2013 as i would like to present thand open this type of discussion in a few weeks
Dear Mark, Dear Anonymous (are you *the* anonymous ;-),
Sorry for the slow response.
I suggest you take a look at Steve Denning's article on Forbes Making the Whole Organization Agile
The probelm with SAfe is that it is not Agile. It may get Agile in the door or large organizations, which might be a good thing, but it fundamentally retains the mindset of the people at the bottom do what the people at the top tell them to, with only slow feedback loops.
Will that be good enough to save the whales? I have my doubts….
As a CSP and CSM with over 12 years of SCRUM experience, my first thought when looking at DaD was "another attempt at disguising waterfall as iterative". When I look at the introductory page at http://www.disciplinedagiledelivery.com/introduction-to-dad/ this becomes strikingly apparent to me. Also, when they describe DaD as goal-driven as opposed to value-driven, it feels diametrically opposite SCRUM. With this in mind, how can you justify such a high rating? How does your opinion differ from mine, and how would you convince me that DaD is a good enterprise integration framework for SCRUM?
Don't worry, Michael, I'm not going to try to convince your to adopt anything. Over the years, RUP has been getting smaller and smaller. I see DAD as its latest incarnation.
I have customers for whom DAD resonated – their projects are characterized by technical complexity, and their customers very waterfall-ish, so DAD resonated with them.
Even though I believe in and teach Scrum, I don't believe there is only one true way to be Agile. After watching Henrick Kniberg's talk 'Is SAFe evil', I have softened my stance even further. I find it helpful to go back to the values, especially the first sentence 'we are uncovering better ways.." This is the most important part of being agile.
@Michael. I would recommend that you take a closer look at understanding what DAD really is. It certainly is not waterfall disguised as iterative. DAD has 4 lifecycles. While the Agile/Scrum lifecycle depicts an Inception and Transition phase, we try to be very clear that these phases should be minimized and ideally they go away completely. BUT, DAD being a process decision framework, context counts. In many situations you will need these phases. I can't explain the details here but you can find several posts on this topic at disciplinedAgileDelivery.com
You also said that it is goal driven rather than value driven. Not true. You have the contexts mixed up. It is goal driven rather than artifact driven. Understanding that every project has DAD common goals allows you to drive out the appropriate agile strategies for your context. Regarding value-driven, DAD combines value-driven with risk-driven, as early risk mitigation avoids unpleasant surprises late in a project/release.
Lastly, I'll point out that people often judge DAD literally after 60 seconds once they see the lifecycle diagram from the Agile/Scrum lifecycle. They immediately jump to waterfall or waterScrumFall conclusions without taking the time to understand the intent. DAD has 4 lifecycles, and we try to be clear that the Agile/Scrum lifecycle is just a start. Most teams evolve from the Agile lifecycle, to the Lean lifecycle, and hopefully then to the Continuous Delivery lifecycle. This is one of the reasons that DAD has become so popular is in its pragmatic approach, and choice of lifecycles.
Hope this helps.
Mark Lines
@Mark Thank you for pointing me back to DaD for further clarification. What I like about what you wrote is “Most teams evolve from the Agile lifecycle to the Lean lifecycle and hopefully the continuous delivery lifecycle.”
My experience is many mature Scrum teams end up using Kanban, which is very similar to the continuous delivery lifecycle. What makes these teams successful is that SCRUM provides the necessary level of agile experience to make this transition successful. Does RUP provide the necessary level of agile experience to high-level enterprise decision-makers to facilitate the evolution to Continuous Delivery? An impediment to the growth of SCRUM in some enterprises is a lack of knowledge of the Agile philosophy among senior stakeholders. How does DaD improve this?
@michael re: "My experience is many mature Scrum teams end up using Kanban, which is very similar to the continuous delivery lifecycle. What makes these teams successful is that SCRUM provides the necessary level of agile experience to make this transition successful. " Completely agree with this. btw, we differentiate lifecycles for Lean/Kanban from CD because unfortunately while many project/orgs can use Kanban, they have difficulty deploying regularly via CD. Also, our latest book "Introduction to DAD" describes the evolution we are speaking of in the case study for a typical team.
You used the term RUP, but I think you meant DAD. Yes, DAD certainly helps bridge the agile philosophy understanding gap between Scrum teams and senior stakeholders. The DAD poster helps to show that agile will not be sustainable and effective unless the entire IT (and indeed business) ecosystem evolves to be agile as well. The mistake that many organizations make is ignoring the ecosystem, seeking to build high performance teams without addressing the larger picture.
I am almost totally in agreement with this article, Peter. In fact, I found this article because I was trying to folks that SAFe is does not an Agile scaling framework make. My only disagreement is that you increased the points for SAFe from 4 to 6. I believe 4 is a fair grade, and I could take it lower when I consider that all the SAFe coaches/practitioners I have worked with, none of them have done Scrum in the real world. Only 1 was a Certified Scrum Master (CSM), and she had never worked on a project in that capacity. SAFe does not work. It panders to management, and violates too many principles of Agile. As a result, every organization I encountered, that implemented SAFe, decided to scrap the whole idea of Agile in general. Furthermore, when those organizations implemented SAFe, there is no underlying Agile practice. Team members are not first trained in an Agile practice like Scrum. Instead they often bring one guy/gal that teaches SAFe to people that are trying Agile for the very first time. This creates problems and a huge frustration for true Agile/Scrum practitioners. To paint a picture. Imagine that you were playing billiards with the pool stick, but no balls. That is SAFe for you. They are propagating "nothing", but their disjointed framework.
Funny to read this old post about scaling Scrum. A bit annoying, though, that even though Alan Shalloway tried to clarify the essence of SAFe for you in 2013, you still repeat your misunderstandings in 2015 :/
Since I was mentioned I must state that my opinions of SAFe have changed since 2015.
Full disclosure, I am now with the PMI as is DAD. We are in the process of integrating FLEX with DAD which will improve both.
These comments, however, are based on things I've written well before these acquisistions.
I am a former SAFe trainer, contributor, and partner. When SAFe was introduced it attended to a lot of good issues:
1) managing the intake process
2) several lean principles and practices
3) coordinating multiple teams
4) DevOps
But as it has expanded, it has done so by adding components and levels until now it is difficuilt to see the value stream – which is very critical. It also leaves you in the catch 22 of being too complicated if you implement all of its levels, or insufficient if you only implement Essential SAFe. It also has not improved it's product management method significantly – using MVPs in a way they were not intended for and not adopting the concept of the minimum business increment.
SAFe can be a good start, but it tends to bog down for a variety of reasons I am writing up elsewhere (follow me on linkedin if you're interested).
This was such a great overview and especially appreciated how little biased or opinionated this was written (I found this to be one of the major flaws with most of the comments on scaled agile practices or frameworks).
Since this is now 7 years old, I wonder if you would reconsider some of your evaluations here or even add new frameworks to that list such as Scrum@Scale.
Cheers