The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization. They have made their approach even more complicated by partnering with Rally, a tools vendor. Consultants are available to customize it for you, also just like RUP.
They are touting their processes and tools this week at Agile 2013 in Nashville. They would be at the RUP conference, but there are none. They would be at a waterfall conference, but they are no longer. So they are at our conference. Strange, but they had nowhere else to go. Try to be polite.
When the signers of the Agile Manifesto got together in 2001, we wanted to share our ideas about software development, a discussion that resulted in the Agile Manifeto. The very first tenet of it is:
Individual and Interactions over Processes and Tools
We wanted to undo the damage that waterfall had done to our profession, and we also hoped to ensure that RUP wasn’t seen as a viable successor.
In many instances, software development has improved based on the values and principles in the Agile Manifesto. Values and principles scale, but practices are context sensitive. We all know it is hard to improve, but we know that we cannot buy our way to a better future.
Many organizations will open their checkbooks for SAFe and its partners. I suggest that they measure the improvement, as that is the job of management. Investments are supposed to have returns. Measure:
- Cycle time – quickest time to get one feature out
- Release cycle – time to get a release out
- Defects – change in defects
- Productivity – normalized effort to get a unit of functionality “done”
- Stabilization – after code complete, % of a release is spent stabilizing before release
- Customer satisfaction – up or down
- Employee satisfaction – up or down
I’ve developed several programs to help you create these benchmarks, if you don’t want to do it yourself. You can look at one at http://tinyurl.com/kgbn94l.
Keep the values, keep the principles, think for yourself. A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe.
Best,
Ken
Ken Schwaber's Blog: Telling It Like It Is 
Wow big that’s quite a statement. I thought Scaled Agile was from Dean Leffingwell, and his book called scaled agile was a good read. Have a confused this?
Pretty good book. He turned that and RUP into a product and licenses people to implement it.
Ah, well we see monetization of this methodologies at varying levels. I suspect Kent Beck, the main XP, makes money via book royalties and coaching and speaking engagements. Going further it seems scrum adds the certification program where another layer of people benefit including yourself and james. This would appear to be the Pinnacle. However maybe I can get by with scrum, xp, kanban, lean and some of this. I wouldn’t want to licence all of that…. its costly in more ways than one.
Comments from the from the most isolated capital city in the world
Yes because Scrum Alliance and others do not do the same 😀
Good point, Ken. I am currently working with a customer, which is currently looking at the SAFe framework to connect the business in their scaling up Agile. Where I do believe that the content of the website and the many practices and ideas that have been gathered there are quite valuable and of use, I also believe that this framework is too ‘complete’ to help the Agile valuesystem of a company thrive, regardless its size.
I must admit I was actually the one pointing out the SAFe framework as a nice reference when thinking of scale, when there were several initiatives to use PMI and all kinds of huge standards to do this. Now it has turned against us a little, as this is now a ‘tool’ the company wishes to ‘deploy’.
I think the nobility of gathering valuable resources on a subject to give an overview or guidance to people seeking security, is actually counterproductive. Yes, the practices are all valuable, and all useful, but arggg, within a year, everything is obligatory and fixed as ‘the new standard’.
The same happened with RUP, with Prince2, with PMI, etc etc. Even in development frameworks like Spring, the elegance of a framework diminishes with the aim for completeness it has.
Scrum is one of of those rare examples, where it is INCOMPLETE by design, and that is why it works. You can safely (no pun intended) ‘implement’ Scrum, and learn to adopt the new values accordingly. Implement SAFe in that way ensures a waterfall of mini-iterations done by the book, with little or no value..
Thanks for this fit-for-purpose post 🙂
Eelco Rustenburg
Thanks Ken for confirming. I got the same feeling when read the book and afterwards saw the way SAFe has been laid out with amazing similarities with RUP. Since I am an experienced and certified professional in all these methodologies: Scrum, RUP and Waterfall (PMP); I could see the similarities on many levels between SAFe and RUP. Besides, it’s amazing how some pieces in SAFe have been picked from Scrum to bring extensive tool and processes and reduce “Individuals and Interactions” aspects.
I’ve been an agile practitioner for 7 years and a CSM for 2 1/2 working in a very large and overwhelmingly waterfall enterprise. When my team adopting Scrum the bulk of the team along with a few product owners took Scrum training together and we began as an SoS organization of 4 Scrum teams. As we grew to 8 teams and began interacting with other development activities in the enterprise (Agile and Waterfall) it quickly became apparent that SoS hierarchies don’t scale well, especially in enterprises that don’t understand or can’t adopt Agile.
I pretty much stumbled across the SAFe Big Picture (you didn’t see much in the Agile Alliance about it) early this year and it resonated because it resembled the model that was already emerging from my SoS team retrospectives.
I read Dean’s book and then went into his course with two preconceptions; that Dean was glossing over intermediate hierarchies; and this was because SAFe was a mostly a theoretical model intended to sell books and licenses.
I left the course with the knowledge of the principles behind a framework that is being continuously improved by a team that is practicing in the field. This knowledge empowers me to look at Principles of Lean, Agile and Product Flow as needed to apply and tailor SAFe for my enterprise. I left eager to reinvigorate my Scrum team to reexamine their Scrum practices because of the emphasis on the need for sound Scrum practices at the team level. Or in Dean’s words, “you can’t scale crap”. I left with an established methodology and framework for applying Agile at an enterprise scale that I could take to leaders of the organization I support. A methodology and framework that when applied to a large scale enterprise gives them a way to meet their business objectives and address their user’s needs while scaling down development in the enterprise.
I didn’t leave with a restriction that requires licensing or outside consultants to apply the SAFe model or framework. Everything my organization needs to apply SAFe is in the book and updated on the website. SPC training helps understand what’s behind the book and website. I didn’t adopt Scrum without training the first practitioners. I don’t think it makes sense for any organization to adopt a methodology or model they don’t understand.
Would it be possible to have some more information about the “licenses people to implement it” claim? I’m not sure I’m finding anything on their website about this licensing, but if you’re talking about paid consultants to implement it on-site, well…I guess that’s how everything works.
Anybody looking at a framework should take it with a grain of salt, especially in Agile context: inspect and adapt.
@mats. If you take the 4-day SAFe Program Consultant course, then you become qualified to teach the 2-day courses. http://www.scaledagileacademy.com/?page=spc
@bob
@bob then I guess the sentence should be rephrased as follows: “[…] and licenses people to become certified consultants of their framework”. And again, I don’t see anything bad about it
You also want:
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)
and
The Principles of Product Development Flow: Second Generation Lean Product Development
Thanks for the additional references Tim. The Principles of Product Development Flow was new to me and its very good.
First, I want to agree with Ken on one point. I wholeheartedly agree that the implementation of an agile framework or process alone, especially across the entire enterprise, isn’t the answer.
But, our clients do need right-sized implementations of proven frameworks that integrate agile and other proven practices. I, and others in IBM Global Business Services have been working with external clients to integrate rapid, lean, agile and traditional practices to deliver large, enterprise solutions since 1999. We have also been conducting assessments of troubled client agile implementations since 2005. All of the assessments that I have been a part of were well intended basic Scrum or XP implementations, where little or no time was spent to understand the current state constraints to agile practice usage, gain executive sponsorship to address the gaps, and develop a plan suited for the scale and type of project/product/program. Most of the clients hired an agile coach that understood Agile basics. Some clients even attained a one day Scrum Master Certification (that my teenage daughters could have passed had they paid the fee), and then they started writing stories…yippee. Most of them bumped into avoidable blockers from outside of the agile team on the very first sprint. Those clients all would have benefited by starting off with the applicable pieces of a proven framework like Dean’s or IBM’s that address end to end delivery, and some help from people who had really used it before to deliver work.
Ken forgot to mention the subtext of the manifesto he signed when he addressed the agile value statement, “Individual and Interactions over Processes and Tools.” That subtext is, “WHILE THERE IS VALUE IN THE ITEMS ON THE RIGHT, we value the items on the left more.” In my experience, without some documentation of the right things, at the right time, chaos is likely to ensue. The Scrum folks have done a lot of great work, but they showed up pretty late to the party with even the notion of needing a "Sprint 0" to do a little pre-work before a first Sprint. Dean, Scott Ambler, I and others have been talking about and writing about “with discipline” and “to scale" practices for years, which are also influenced by well proven lean practices. It is great that Ken is going to now create another framework (and maybe a one day “master” certification for the framework?), but there are already choices out there for our clients now, as well as experienced people who know how to tailor them to client wants and needs.
Most of our clients are not at a point where they are just ready to “be agile” after basic Scrum training and some coaching. And, most of them are asking for agile “project” delivery from system integrators through procurement processes. They need help. So instead of reinventing the wheel every time, and re-discovering a majority of the same lessons through retrospectives every time, our clients would be wise to leverage proven frameworks, and some help from experts who understand how to implement the right aspects of it for them. If we in the Agile community want to take the next leap with Agile, we have to stop over simplifying what it takes to implement Agile with most of our clients for true end-to-end optimization (not water-scrum-fall). I contend that leveraging existing, proven, frameworks is a part of that leap…regardless of their origin.
Paul, I personally worked with you using this framework and it was total failure; the worst part is that you keep trying to convince your clients to use it just to make more bucks at IBM. Shame on you.
LL? I would love to respond but don’t have the context of which client, initiative or who you are. If you provide something specific, then I would be glad to provide a response. Since I first responded to this I have also led or been involved in several SAFe implementations (and now have 20 years of DAD/SAFe (and a few one team Scrum implementations). In addition to executive support, having a roadmap to guide you and a suitcase of assets based on proven, integrated, practices that scale and can be tailored Is valuable regardless of their origin.
LL? I would love to respond but don’t have the context of which client, initiative or who you are. If you provide something specific, then I would be glad to provide a response. Since I first responded to this I have also led or been involved in several SAFe implementations (and now have 20 years of DAD/SAFe (and a few one team Scrum implementations). In addition to executive support, having a roadmap to guide you and a suitcase of assets based on proven, integrated, practices that scale and can be tailored Is valuable regardless of their origin.
Big Methods and Big Tools – reminds me of James Martin (died last month a rich man on a Caribbean Island of his own…).
More here:
http://bit.ly/IE-an-IT-religion
An IT religion for the 1980s…
Brian
Pingback: ken Schwaber’s rather incendiary rant against SAFe… | brianwernham
I think it would be wise to drop the zealot approach. Many Scrum concepts, like iterations, potentially shippable increments, definition of done and development driven by product needs come from RUP and even before. The current generation of developers and process enthusiasts ought to study some history before they commit the same mistakes.
They were used by RUP, but we developed by many of us far before RUP. The problem with RUP wasn’t the ideas in it, it was turning them into a formal, prescriptive methodology.
Ahhh! Methodology wars – its like being back in the 1990’s all over again!
How waterfall….
Brian, my question was not meant to be negative, I am truly interested in knowing and understanding the experiences of other folks working in our industry (so to speak)
paul
Just kidding!
These philosophies existed LONG before SCRUM or the manifesto and were not “invented” by technologists. The practices are centuries old. Linear is largely derived from agrarian age (reap, sow) and industrial age (mechanization) evolution. The information age and the internet have pushed evolution into geometric models. SAFe is no more than a construct in process, not a fixed “prescriptive. Your myopic rant smacks of “self serving protectionism” and has immediately devalued your role as a progressive thought leader, so SEE YA.
RUP is a framework for best practice in Software Development, It is purely customisable. I see SAFe as building on the best practices of SCRUM, and I believe it genuinely helps in scaling SCRUM beyond a single workstream. Is there anything else that does this job. I am an advocate of both SCRUM and RUP and am fully certified in both methods. I will apply just the right amount of process and tools necessary given the current client, culture and circumstance. As software engineers, we should stand on the shoulders of our predecessors and the “methodologies” of our previous generations, instead of standing on each others toes.
Ken,
Great blog. It appears to me that regardless of the success of Scrum, organizations still desire the command and control facade to feel comfortable. I have seen SAFe in action and it is a huge overhead and burden to an organization especially one just starting out on the Agile/Scrum transformation. IMHO it looks to me that SAFe is an easy sell to organizations that think they want to go Agile/Scrum but are hesitant to give up the reins and I am not sure if this is a good or bad thing. That is getting an company to try SAFe and be immersed somewhat in the Agile philosophy and why of life/work.
I think what is missing a less formal structured approach for scaling agile/scrum across an enterprise. In my experience the clients have wanted some sort of defined process to replace their current way of doing things and SAFe comes with a list job descriptions/titles/roles/responsibilities and alike that will make things appear pre-packaged and ready to go. Not that i am in favor of SAFe, actually it is pretty much how most organization work above the dev team level. But now it is wrapped in a pretty packaged to be sold and made money off of.
Just mights for the morning
Paul,
<>
An interesting analogy. Riding a horse is a collaborative effort between the rider and the horse. The rider must let the horse ‘self-organise’ in terms of co-ordinating its feet, but the rider must set the direction and pace. When it comes to jumping, it is a team effort – both rider and horse working together.
So, no, a rider would not give up the reins, and neither can top management…
Brian,
Hum, was not thinking about animals or horses, just thinking alongs the command and control. I guess you could think of the team as a horse and the riders as the product owner, but this analogy leaves much to be desired. let’s look at this differently how about american football. you could run a team like the Dallas Cowboys where management/owner has a tight hold on the “reins” and leads the team into NFL abyss by providing too much control, or look at the NE Patriots where management/ownership allows the coach lead the team with minimal input from above, although there is definitely a guiding factor, and see the differences in the teams successes.
Excellent reply Brian. To reiterate a point in my initial blog entry, the Agile manifesto language includes “That is, while there is value in the items on the right, we value the items on the left more.”, yet many people ignore the items on the right as opposed to acknowledge that they can be tailored to fit the need.
The best horses and riders work together using as little of the reins as possible. The reins are held loosely and serve only as a reminder to the horse. When the reins are held tightly they have “a great physical and psychological impact on the horse. The horse is deprived of all of his dignity, it is painful, and because of the position of the head, the horse cannot see. It is unnatural, and has nothing to do with the natural movements of the horse. The breathing is hindered, the blood pressure is higher, the heartbeat is higher, and the horse is in a constant state of panic.”
So although the reins may be necessary, to achieve the perfect balance between horse and rider, they must be held loosely and used only as a gentle guide or reminder to the horse.
When I go to the site that describes the scaled agile framework, I see a picture that has icons representing people all the way down the left hand side. To me that symbolizes that it all starts with individuals. When I dive into the rest of the website, I read article after article that describes how the people work together to build something large. To me that seems to be about interactions. All of this is available for free. No consulting fees, no paywall, nothing. I don’t need to pay them, if I think I can apply their ideas to my situation without help.
This blog post offers nothing in the way of helpful comments or specifics about what is good or bad about SAFe. It simply shows a lingering bias and misunderstanding of the origins of the concepts. The first paragraph is full of pejoratives, which is a very anti-agile mindset in its own right, and inaccuracies. Nobody said SAFe was simple. Bemoaning the experiences and learnings of the predecessor practices (RUP) which leads to SAFe just follows-up on this overt negativity. We learn, we inspect, we adapt. I can’t think of a better process “thought experiment” than RUP, to give us the very insight Ken uses to discredit SAFe in his replies. You can characterize RUP as a failure if you want, but you’d be wrong. Further, I am not sure why Ken gave the “one-size-fits” all analogy given the “Inspect and Adapt” vision of cadence and synchronization. What SAFe does, and in a way that is so much better than anything else to date, is to acknowledge the context of agile in the larger businesses. It recognizes the need to optimize at the program, not the team, level. It recognizes that transparency needs to flow to the top. It acknowledges that training needs to happen at all levels to be successful. It serves to demonstrate that being agile in the enterprise requires a shift across the enterprise. From the leadership of the C-level team, to Human Resources to support and devops, the shifted roles for collaboration are clear. SAFe addresses how to optimize large number of people rather than the “cut scope” answer to all schedule problems of the short-sighted Scrum. It defines context authority and alignment of goals on a cadence. It uses Lean and Development Flow at its very core and re-enforces the agile manifesto at every single turn. All that and it’s free and in the public domain. The only real flaw I have noticed in my studies of SAFe is that it uses Scrum as the team practice. I think that’s a mistake and will eventually use Kanban to avoid the transaction cost, handoffs and unnecessarily large batch size of the iteration. This will be replaced with terms like “minimal shippable feature” and the cadence and synchronization will happen on schedule but decoupled from the arbitrary flow units of Scrum. All in all SAFe offers what is arguably “the simplest” framework for enterprise agile to date. Given the framework versioning, open source IP and willingness to listen and change based on real feedback I predict SAFe to lead us in to the next dawn, whatever that is. I just hope people in the future view the iterative advancements as “failures”. That would be the only real failure.
Correction: do NOT view the iterative advancements as “failures”
Tim – I really like your analysis. You have done a great job articulating many of the points that I have thought about regarding SAFe.
SAFe has also totally misunderstood the role of Kanban.
@tim
My first question for you is: Have you seen SAFe in action at a client site? or is your response based upon what you have read and learned form the SAFe site?
paul
I worked full time as an individual team member (BDD/Cucumber) on a flagship SAFe project for over a year and across many PSI deliveries.
Tim, cool. what did you find optimal about SAFe? what areas did you see room for improvements?
Paul, nested replies only go 1 deep so this will get a bit disconnected. The number one thing SAFe does is alignment of the Agile practices across the enterprise and engages the entire effort with a common set of values and principles which are all well founded in Lean and Flow. There are many subtle benefits to this and addresses the (inevitable) “artifact impedance mismatch” that happens when Agile is not socialized across the organization. One flaw was that very risky or large scale epics didn’t make the cut for a PSI and so maximum business value was not achieved. However, this is correctable and speaks even further for the need to train everyone and to socialize the concepts continually.
Hi Tim,
I agree that it aligns some practices, but it changes some others, and by doing this it violates some of it principles. I could write a whole book about that – also based on practical experience.
For example the normalization of points asking to define a story that can be done in 1 day and that is now assumed to be 1 point. That alone leads already to a lot of confusion.
First of all this is a major violation of anything that Agile and Scrum point estimation stands for.
And secondly – one day by one engineer or the whole team (which would be really nonsense) ?
Thirdly – if one team estimates 1 day to do a job, this does not mean this will apply to another team too.
Fourth – I think they recognized this dilemma and introduced then the independent concept of Feature points on program/PSI level. But this creates another flea circus – do we need to estimate twice ? Or how do we keep both concepts aligned and synchronized in our program structure ? That is a nightmare.
And so forth.
As long as SAFe defines only the high-level structures and interfaces for the individual teams to use for the coordination with the other teams, all is fine with me (in fact SAFe defines pretty much all the principles I was preaching and teaching for many years now about successful Scrum of Scrum structures). But when they try to change Scrum and/or squeeze it into amore restricted framework, it will fail.
To exaggerate and bring it all to a short statement : RUP was basically a waterfall structure (with its phases) in agile disguise.
The Agile and Scrum success bases on the fact that practically everything is dynamic. Only the sprint length is kept constant as much as possible. But all team members incl. the PO act totally flexible and dynamic. That is the most essential thing about the success of these projects (and the most driving factor for failure, if the project’s environment is not accepting/supporting and even fighting this mindset).
To put these concepts into more static frameworks supports again the traditional mindset, and makes SAFe therefore sellable to the traditional hardliners, but reduces the real success factor and generates a rather schizophrenic approach.
You need to try SAFe or any other methodology for at least two years before criticizing it… *cough*
PA
“That is, while there is value in the items on the right, we value the items on the left more.” (love the rhythm, balance and moderation)
First, some positive feedback: I liked to see the measurement bit at the end, and who doesn’t like a little controversy.
Do we agree that agility is about inclusion, collaboration, change and leadership? Re-read the post a few times to find glimpses of this, but.. there are none…
“Individual and Interactions over Processes and Tools” has, by definition, more to do with the inclusive aspect, ‘individuals and interactions’ than the exclusive aspect, ‘processes and tools’ – so why induce fear with a rationale that it was written was to ensure RUP wasn’t seen as a viable successor? This not only diminishes the history of software, it diminishes the history of agile (double-whammy!) Wouldn’t it be more productive, more “leader-like”, more along the lines of shared value, to emphasize the positive aspects of individuals and interactions? (Now, that’s an article I would love to read)
I don’t feel comfortable reading about an approach to scare or demoralize people into exclusion from “your conference” – this doesn’t feel agile. Likewise, it is awkward to read about values such as independent thought when the article is written so much to the contrary.
Here are some ideas, which I hope are reasonable, for aims which may add value in a constructive debate: To elevate us… to result in better attitudes, better performance, stronger networks, healthier communities (long-term as well as short-term)… to stimulate our intellects… to positively represent ideals… to inspire us and motivate us.
Best,
Adam
Ken, I think that you are being a bit unfair to both RUP and SAFe. Certainly RUP’s best days are behind it, but at that time of methods evolution it was a great improvement over waterfall. Slamming RUP is like calling those that invented the turboprop idiots. At the time it wasn’t such a bad thing.
I think that it is a matter of record that many large and complex software development initiatives have struggled to scale with Scrum and some high profile failures have ensued. Software development at scale is very hard, as Scott Ambler has written about for years in articles such as this one on the DAD blog: http://bit.ly/1112OQn
SAFe gives us some good ideas for how to deal with these complexities where few existed before. I am using some elements of SAFe with a client right now but not all since some of the techniques would not work well, which is consistent with a “pragmatic agile” approach.
I completely agree that one size does not fit all, which is why we have the Disciplined Agile Delivery (DAD) process decision framework. It helps us to make better process decisions to be as agile as we can, yet in a disciplined manner for the context that we find ourselves in.
I think that in future decades, it is reasonable to expect that we may have moved away from Scrum to something that works better. When people explore the archaeology of software development methods, I hope that they do not dismiss your great work and contribution with such disdain.
I think that you’re as a touch unfounded to help equally RUP along with Safe and sound. Definitely RUP’s very best days and nights usually are at the rear of the idea, nevertheless in those days associated with approaches progress it had been a fantastic advancement above waterfall. Slamming RUP is compared to phoning those who created the actual turboprop idiots. At that time the idea wasn’t a real awful point.
I think it was mentioned that the team-level practice in SAFe is only Scrum. Actually, I think that Kanban at team level is not against SAFe in any way although Scrum is discussed mostly in the SAFe literature at team level.
Kanban is on the framework right there at the team level, same as Scrum. Also at the other three levels.
Pingback: Thoughts on how the Scaled Agile Framework is perceived by Agilists
I rather appreciate the SAFe model. It’s a manifestation of disparate practices that organizations have thrashed on and ultimately landed on anyway. While, I am viscerally opposed to dogmatic practices, I find value in the guidance of the framework. It’s still just a framework. Use what works. Throw out what doesn’t.
Is “viscerally opposed to” being dogmatic???
Not intentionally. I meant that my immediate (or gut/visceral) reaction to prescriptive processes is to have disdain for them but it’s too easy to throw something out because it looks overcomplicated and bloated. When I look at the SAFe model, it gives me anxiety–the way The Cheesecake Factory menu does–but that doesn’t mean there isn’t some value.
The risk with anything like SAFe is that some organizations will only take it at face value and follow it to the letter–and blindly at times. They lose the spirit and intent. They go through the motions and forget why they are doing it in the first place. Jim Newkirk said at Agile 2013 that when you don’t know *why* you do something, when the context changes, you won’t know how to adjust.
Personally, I think it’s unfair to put that onus solely on those who develop a framework/methodology/process. We have to take responsibility for how we choose to use the tools we have.
Agile appears to be moving away from its key tenets of helping customers deliver successful outcomes. It is now a cottage industry of authors, experts and doom sayers attempting to discredit new ideas that may – or may not add value to a customers delivery process. We now live in a distributed world where teams work towards the same goal but are located in different timezones, so the Kens point about individual and interactions over processes and tools becomes interesting, to enhance the former we have to use the later. And with distribution we have to use more of the latter to get the former.
Personally I am a Scrum advocate – but also believe Scrum is only a foundation and to add greatest value we need to pull elements from XP and Kanban into teams to add the greatest value. Scrum also only looks at the bottom tier of team level, SAFe looks further up the tree and defines the pipeline of work and some techniques to prioritise it. I have seen it work well and strongly believe SAFe actually adds value to the Scrum delivery process. Perhaps it is time to stop thinking our way is the only way and become open minded to new ideas and innovative frameworks that can add value to our customer.
There are lots of great comments on this thread but the term “cottage industry” struck me as an appropriate description of the current maturity of Agile. I see SAFe, PMI-ACP and the increasing number of Agile certifications as the next steps to bring Agile past its current level of a consulting tool for various authors and to make sense of how Agile can fit into a larger corporate eco-system. I don’t see RUP or any prior processes, methods or methodologies as failures, they’re all part of a greater arc of improving project and software development effectiveness.
Interesting – I think this is the first time I’ve seen agreement between Ken and David Anderson!
http://www.djaa.com/kanban-anti-safe-almost-decade-already
Having not tried SAFe out myself, but been at many large corporations, I agree with many of the comments here. Large orgs need to feel they’re buying a bronze bullet – they know silver bullets don’t exist but they want what looks like the closest thing they can to it.
I’d also say – where there’s a demand there’s a supplier, just like certification, books, conferences. There are smart people who are willing to pay for this stuff and use it because they have problems.
Admittedly most won’t get the 1,000% productivity improvements or similar bu tif it moves the culture needle a little then I’m sure it’s got to be worth something.
Used RUP for many years, used Agile for many years and studied and used parts of SAFe. My lessons learned about SAFe so far:
> The good – the underlying framework is sound with Agile Release Trains at the program level and Investment Themes at the portfolio level;
> The bad – the current version (http://scaledagileframework.com/) is created to please big companies with big budgets, big processes and big teams so it is heavyweight, complex and unSAFe in a complex world (just like RUP);
> The ugly – too much process, too much documentation and not enough Agile so please, someone write a safe SAFe Guide. I would say 16 pages is sufficient!
Ken, I appreciate what you have contributed to the software development community and to the advancement of Agile values and practices. Needless to say I was very disappointed in the very harsh, non-Agile like approach you took to sharing your thoughts about SAFe. I have equal criticism for David Anderson’s post on the topic as well. Agile is a big tent, and there is more than enough room for different approaches to achieving the values and principles of the Manifesto (you of all people should know that). I am a SAFe Program Consultant and practitioner, and can say from first hand experience that several of your comments are completely off-base. For example, while Rally is a tool vendor that is working to make it easier for SAFe programs to configure their product to align to SAFe, the framework in no way promotes Rally or the use of any tool for that matter. (BTW, VersionOne and other tool vendors such as AgileCraft are working with equal diligence to make their products more friendly to SAFe shops.) In SAFe training and in practice, we make extensive use of manual boards to do release planning as well as to provide very typical information radiators. I interpret your dig referring to Rally and RUP as a personal attack against Dean given his history with both Rally and Rational. It also comes across as a very unprofessional fit of jealousy against someone who has done a fine job of identifying a need in the marketplace and creating an effective business model to meet that need. Shame on you!
Speaking of “individuals and interactions”… have you taken the time to meet with Dean personally to express your thoughts and concerns about SAFe? Have you exercised “seek first to understand, then to be understood” as all good Agilists should do? Had you come to Nashville I’m sure Dean would have welcomed that conversation… he took time to chat with me I’m sure he would have done the same for you. Have you taken the SAFe training or met with organizations who have had great success with their implementation of SAFe (not the least of which is Wal-Mart, the largest company in the world)? Have you put any thought to markets such as the one I serve (the Federal government) where the use of SAFe is actually helping tremendously large organizations envision making the transition to Agile where previously they thought that doing so was next to impossible? Are you truly interested in learning and understanding, or are you simply trying to tear someone else down because their approach is gaining mindshare and taking away your airtime?
I just left Nashville after a week of interacting with over 1,700 practitioners who are passionate about building great software and promoting Agile to our organizations and our customers, and the overwhelmingly positive experience came largely from a sense that while we all have different circumstances, roles, and approaches, we all believe in the intent behind the Manifesto, and we all want each other to succeed. I’ve never been to a conference in my 25 years of experience where the environment was so positive and supportive as what I experienced at Agile2013. I completely understand if you disagree with the Scaled Agile Framework and do not expect you to get on the bandwagon. Put your own approach into the marketplace of ideas and let the community decide what works best for them. Be big enough to respect the work of others and even cheer an organization on if they are having great success using someone else’s method. In the meantime, an updated post with a mea culpa and a call to Dean would go a long way… your article got a lot of buzz as I was walking the halls of the Gaylord convention center, and most of it reflected the same disappointment in you that I felt. The Agile community is coming of age, and I believe there is little interest or patience for new attempts to start more Agile wars.
I still wish you all the best Ken and look forward to your future contributions to the Agile body of knowledge. Please keep them positive… I know you can do it…
Stephen W. Mayner
MBA PMP CSM CSP SPC
Obviously, responses to this posting have a lot of material to work with and could get ugly regardless of your agreement or disagreement on each of the many points of contention. I’m going to avoid weighing in on any of them, for now.
Everyone has an opinion and everyone has the right to share it. In ‘my’ opinion as professionals there are certain approaches and rules of etiquette that we use when sharing our opinions about the beliefs and views of our peers. Fair or not, the higher we are held in regards to our profession the higher the expectations are of our adherence to these rules of etiquette. I don’t have the golden list of these ‘rules’ but basically, treat someone as you would wish to be treated.
Also, everyone has bad days and I can no longer count the number of times I’ve put something out and wished I’d never said that.
I would hope that in the name or professionalism Ken would rethink this posting and his intent.
Pingback: The Good, Bad and Ugly of Agile 2013 | Jason Little
Reblogged this on systems-software-development-perestroika.
Good point, Ken. I am currently working with a customer, which is currently looking at the SAFe framework to connect the business in their scaling up Agile. Where I do believe that the content of the website and the many practices and ideas that have been gathered there are quite valuable and of use, I also believe that this framework is too ‘complete’ to help the Agile valuesystem of a company thrive, regardless its size.
I must admit I was actually the one pointing out the SAFe framework as a nice reference when thinking of scale, when there were several initiatives to use PMI and all kinds of huge standards to do this. Now it has turned against us a little, as this is now a ‘tool’ the company wishes to ‘deploy’.
I think the nobility of gathering valuable resources on a subject to give an overview or guidance to people seeking security, is actually counterproductive. Yes, the practices are all valuable, and all useful, but arggg, within a year, everything is obligatory and fixed as ‘the new standard’.
The same happened with RUP, with Prince2, with PMI, etc etc. Even in development frameworks like Spring, the elegance of a framework diminishes with the aim for completeness it has.
Scrum is one of of those rare examples, where it is INCOMPLETE by design, and that is why it works. You can safely (no pun intended) ‘implement’ Scrum, and learn to adopt the new values accordingly. Implement SAFe in that way ensures a waterfall of mini-iterations done by the book, with little or no value..
Thanks for this fit-for-purpose post
Eelco Rustenburg
I felt compelled (evil spirits?) to leave one more comment. I’m somewhat confused by many of Ken’s statements but one that stands out is the implication that the RUP people ‘are back’ (said in the tone of the little girl in Poltergeist.) Maybe my knowledge is incorrect or incomplete.
Over my 30 years in the industry I have been involved in many, many processes and methodologies. I was one of the first evangelists of OOAD and distributed objects (i.e. C++, CORBA, DCOM, etc.) During the 90’s I read many books and articles authored by James Rumbaugh, Ivor Jacobson, and Grady Booch. We industry rats hammered these three to collaborate and pick a direction. Their unaligned views were making life tough for those of us in the trenches. Rational Software was founded in 1981. Although RUP, in its infancy was primarily based on the work of Rumbaugh and Booch, RUP wasn’t ‘formally’ created until 1996 when Rational acquired Ivor’s Objectory Process. That was 1996, or 17 years ago, many years before the legendary 2001 Utah summit where all it took was your name on a document to become perceived as a founding father and a thought leader. BTW, there were a lot of names on the Declaration of Independence, 56 to be exact. How many of them went on to do something great? I don’t know. Anyways, RUP, Like Democracy or the American Justice System, wasn’t perfect but it was the best thing out there at the time primarily because it gave everyone a common lingua franca and basis to work from.
Now, I have a long history that pre-dates Agile of working with Colin O’neill, one of the founders of Scaled Agile Inc.. Yes, we used RUP and other iterative processes back then, but even at that time we knew there were better ways and were incorporating them into our work. Many of these better ways that we figured out on our own became Agile practices. However, to label Colin as one of those RUP people is utterly ridiculous. Then there is Drew Jamillo, the second leg of SA Inc. I don’t think anything about Drew could come close to being able to label him as one of those RUP guys. Then there’s Dean Leffingwell, the third and the foundation leg of SA. Dean joined Rational in 1997 and worked there until 2000. When Dean joined them Rational Inc. itself was already 16 years old and the early versions of RUP had already been around for several years. So, timeline wise, Dean left Rational before the legendary Utah summit. Then in 2003 IBM bought Rational and swallowed them up making RUP a wholly owned IBM product. Let’s move forward in time 10 years to Agile 2013.
Although I wasn’t there this year I can only guess that Ken must have ran into a LOT of IBM folks at Agile 2013, or Rumbaugh, Jacobson, and Booch were roaming the halls? These are not the same guys that brought us the Scaled Agile Framework.
I guess you cannot edit a reply once it is made. In my previous reply I stated that I had read many books on processes in the 90’s. That should have been 80’s and 90’s. Credibility is everything.
Pingback: Controversy around SAFe, DAD and Enterprise Scrum
Pingback: Agile Methodology wars | DSDM Atern in the real world
Pingback: I’m coming out as not-Agile and not post-Agile | Mike MacDonagh's Blog
I’ve attended Dean’s session on Tuesday last week in Nashville. And to be honest – I was shocked. Shocked by Dean’s ignorance on what agile is (about). Dean repeatedly stated (I stopped counting after 3 occurrences) that “Agile is just a tool”. Yet, agile is almost everything – a value system, a culture, an attitude, a mindset – but a tool. Of course, it is not helpful to weigh each and every word a speaker says during a presentation. However, if something crucial like this is repeated over and over again, than it can’t be an oversight.
It seems to me (not only because of this statement but also because of the SAFe’s content), that Dean and his colleagues treat agile as if it would be “just a tool”. Unfortunately thinking about agile as a tool seems to be easier for many people than accepting that it will have an impact on their culture, values, mindset, attitude…
Pingback: The Kanban Method Is A Vehicle – It Is Not A Destination « Agile Ramblings
Being a consumer of Agile ( I find a difference in perspective people using Agile and people use Agile for living), it’s about mere commonsense on what is required to bring a business excellence in the given context. It’s a no brainer that problems plaguing large-scale Enterprise include communication and coordination errors at multiple levels people, process as well as technology integration and infrastructure issues. In large Enterprises Programs are complex with multiple LOB/ teams / legacy involved, also importantly large programs are driven by disruptive technologies like Mobile, cloud etc..,
Synchronization of multiple touch points and early integration testing form the two key ingredients in large-scale programs, and SAFe suggest ways to solve many issues that may arise during these stages – Portfolio->Program->Team.
It’s quite natural that people look at something which resonates to their context. The timing and messaging of SAFe hits bulls eye, no wonder it’s the talk in the town. You asks CIO of any large organization ( fortune 100 -50), what bothers them is show me the success of Agile? Let us wait and watch if SAFe is able to show something, as any consumer does, we will look for a new FACE..
Pingback: La tour de babel agile |
Hi Ken
You say that investments are supposed to have returns, and cite various measurements that can be made to that effect. SAFe offers this in the relevant section on iteration management:
“…with adjustments for economics of location, (US, Europe, India, China, etc.), work can be estimated and prioritized based on economics by converting story points to cost”.
This conversion of “story points to cost” seems to be absent as one of the measurements you propose. I can’t say I’m too surprised. I’m sure that such a metric would stick in the craw of most agile developers and their coaches. I challenged Dean on this yesterday, and his response was as follows.
“If you don’t normalize estimating, then there is no meaningful economics; you can’t figure ROI of you don’t know that the “I” is. If you want to scale agile, and there is no meaningful way to bid work across teams, and within a program, you will be blocked before you even try (executive view: “That agile thing; not ready for prime time. They use gummy bears per sprint as their main metric, and they can’t estimate work in any meaningful way. They just don’t get it. I know, let’s just have the PMs do a work break down structure; that we understand. And of course, we’ll need good specs to do that, so let’s stop and write the SRS now”.) Then Agile loses.”
So, here are two questions I’d like to put to you:
1) Specifically, what are *your* thoughts on the conversion of story points to cost?
2) More generally, do you see a fundamental philosophical schism between Scrum and SAFe?
Regarding the latter point, my own observation is that Dean seems prepared to make certain compromises when faced with management dysfunction – story points to cost being one example. I wonder if it is in this willingness to compromise, rather than the values held, that the seeds of debate have been sown.
Hmmm …
Why is it important to accurately estimate a project or longer term effort in advance, especially with the accuracy of story points? Value is derived using Scrum by only doing the important things, and what is important emerges as an initiative proceeds. Focusing on value and discarding low value is a great way to run any effort. For software, this approach also removes having to sustain low value stuff for the rest of our lives.
Executives have used imprecise estimating for years in sales. A goal is set and the way that it is met emerges throughout the year. Everyone understands that conditions, prospects, customers, markets, and competition changes.
Software is very similar. I’ve found that estimates cannot be commoditized. Three primary variables enter into how long work will take: domain expertise, technical skills, and experience working together. Like any complex problem, any changes in any of these may cause unexpected perturbance. If you want predictability through estimates, perturbance is undesirable. However, then you should probably not be managing software development.
To cope with the complexity and unpredictability of software development, Jeff and I devised Scrum so it would use short cycles of development. If you will know the results within two weeks, the need for an accurate estimate disappears. The only reason for estimating is for a team to get its arms around how much they should try to take on. Any more estimating than that is, as Mary P says, waste.
Scrum is based on empiricism. Empiricism counts on short cycle inspection and adaptation to control complexity. Risk is managed through the length of the cycle. The longer the cycle, the greater the risk.
I think the fundamenal philosphical schism between Scrum and SAFe is clarified by your quotes of Dean. Scrum controls risk through empiricism. SAFe tries to control risk through predictability. We have years and years of experience learning that predictability is not possible for complex problems like software development. The rest of the world, both scientific and industrial, has accepted this and moved forward with complex control mechanisms. Only in software is the old dream of safety in predictability still alive and, apparently, salable.
I knew Scrum would be hard to understand. Those who have made the effort to learn to apply empiricism and lean through Scrum have benefitted immensely. I guess the other will not.
Ken
Thanks Ken, your comment that “estimates cannot be commoditized” has stuck with me for days. It’s been a real mindworm, My answer is this: yes, estimates cannot be commoditized, but if you make them transparent, there’ll always be some damned fool who’ll try.
Anyhow, here’s where you and Dean seem to have a point of agreement. You both recognize that some stakeholders aren’t interested in proving success by ongoing delivery, which is a precept of agile practice. They are conditioned to forecast instead and to try and work those forecasts (such as commoditized estimates) into long range plans. The schism between Scrum and SAFe lies in the treatment provided. SAFe plays to the audience, and supplies the boardroom with its usual “fix” of pseudo-predictability. Scrum does not. It challenges it, contextualizes it as a poor substitute for the empiricism needed, and attempts to treat the matter as an educational issue.
Continuing with this rather distasteful metaphor, Scrum is a bit like going cold turkey. Some organizations have the appetite for it, as Jeff Sutherland has shown with the “Shock Therapy” approach. Others, however, do not. SAFe will find that market and meet the demand.
If SAFe was positioned as a “soft option” that gradually weaned executives off their dependency, by keeping them fed with estimates and so forth in the interim, then perhaps this schism might be bridged. Unfortunately though, I don’t see much of an indication that this is how SAFe is actually being promoted.
Ken made a few really good points there. My expirience with SAF and trying to scale Agile and Scrum led me to the following conclusion. Companies, specially larger ones, try to scale up any software development efforts without even questioning the benefit of scaling up. They put themselves in the box by thinking they can only do more with more people involved, thus scaling up becomes a must do. How about instead, do more (value) with less people? Innovate, dusrupt, focus on outcome. Then, you would not be scaling up all the time. In fact, you would be scaling down. SAF is based on the scaling up premise and forces everyone to think they need to expand the number of people involved, etc. How about the opposite? Indeed, global outsourcing plays a big role in company’s desire to expand the work force due to access to cheaper labor. But we all learned that trap by now. Try to apply Lean Startup principles and at least scale up only when needed, after careful consideration and after weighing other options. Just because you can throw more people at the project, does not mean that is the way to go. SAF has a lot of overhead when it comes to scaling down. It expands very fast but it is not very adaptive to shrinking, if you will.
Well said. My experience, also. Value and leanness comes from questions what one is doing and why it is being done,and then proceeding.
OPEN OPPORTUNITY TO BRIDGE THE GAP…
Dear Ken,
Over the last couple of weeks, the Agile/ Lean community has heard critical comments regarding methods of scaling agile. And this has sparked several heated debates on every blog in our corner of the “agile” world. The blog posts by both Ken Schwaber (https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/) and David Anderson (http://www.djaa.com/kanban-anti-safe-almost-decade-already) have become viral and is kicking up a philosophical dust storm.
As an Agile community, we believe that Interactions and two-way conversation is vital to communication and understanding.
Therefore, the Organizers of the AgileCamp 2013 invite Ken Schwaber, David Anderson, Dean Leffingwell to discuss face-to-face the challenges of scaling agile across enterprises and openly discuss the value of differing approaches that each brings to the industry. AgileCamp 2013 (www.agilecamp.org) takes place in San Jose, CA on 9/21 at the eBay/ PayPal campus.
While sessions for this event are already planned, we would pre-empt a part of our schedule to accommodate this community building opportunity.
I believe that the Agile Community would love to hear this conversation and maybe, we can reach a common appreciation and understanding of Scrum, Kanban, and the Scaled Agile Framework.
Thank you for your consideration!
Stacey Louie
AgileCamp 2013 Chair
http://www.agilecamp.org
info@agilecamp.org
I believe that this “SAFe” thing is just to make some money from enterprises. Adaptation of Agile to the enterprises is what enterprises are looking for. But having some strict organizational cultures are preventing them to accept these Agile view. So that I think this “SAFe” thing is not “Scaled” but could be said as “Modified” of Agile vision. And this is so silly… I do believe that any Agile way/work/process should not be considered as “Framework” and launched to people. Agile is a vision and does not step in the mission. If it is packaged as framework, it starts to limit people and organizations and also itself. Every organization or people have/should have their own Agile methods which are suitable for their vision and work-culture. If they are looking some new standards or protect their standards, there are lots of high-level libraries,frameworks(ex. ITIL) which should be considered first and before Agile..
Agile is a set of values and principles. Scrum is the simplest structure possible that instantiates them.
Ken… why won’t you meet with Dean Leffingwell @ AgileCamp 2013 on 9/21 in San Jose, CA (www.agilecamp.org). I will open up a forum for you and him to openly and professionally discuss.
OPEN OPPORTUNITY TO BRIDGE THE GAP…
Dear Ken,
Over the last couple of weeks, the Agile/ Lean community has heard critical comments regarding methods of scaling agile. And this has sparked several heated debates on every blog in our corner of the “agile” world. The blog posts by both Ken Schwaber (https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/) and David Anderson (http://www.djaa.com/kanban-anti-safe-almost-decade-already) have become viral and is kicking up a philosophical dust storm.
As an Agile community, we believe that Interactions and two-way conversation is vital to communication and understanding.
Therefore, the Organizers of the AgileCamp 2013 invite Ken Schwaber, David Anderson, Dean Leffingwell to discuss face-to-face the challenges of scaling agile across enterprises and openly discuss the value of differing approaches that each brings to the industry. AgileCamp 2013 (www.agilecamp.org) takes place in San Jose, CA on 9/21 at the eBay/ PayPal campus.
While sessions for this event are already planned, we would pre-empt a part of our schedule to accommodate this community building opportunity.
I believe that the Agile Community would love to hear this conversation and maybe, we can reach a common appreciation and understanding of Scrum, Kanban, and the Scaled Agile Framework.
Thank you for your consideration!
Stacey Louie
AgileCamp 2013 Chair
http://www.agilecamp.org
info@agilecamp.org
Aargh. Talk about a lot of hot air.
While I like Stacey’s idea for a civilized debate, let’s be careful what we wish for. Dean has already responded to Ken’s post and said: “arguing with any methodologist is like teaching a pig to sing, it accomplishes nothing and annoys the pig”.
http://scaledagileframework.com/safe-sound-and-fud/
@Ian, I take it, then, that Dean doesn’t consider himself a methodologist?
Pingback: Back to The Future of Agile Software Development | Edge of Chaos | Agile Development Blog
OPEN INVITATION TO BRIDGE TO BUILD UNDERSTANDING
Dear Ken, David, Dean,
Over the last couple of weeks, the Agile/ Lean community has heard critical comments regarding methods of scaling agile. And this has sparked several heated debates on every blog in our corner of the “agile” world. The blog posts by both Ken Schwaber (https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/) and David Anderson (http://www.djaa.com/kanban-anti-safe-almost-decade-already) have become viral and is kicking up a philosophical dust storm.
As an Agile community, we believe that Interactions and two-way conversation is vital to communication and understanding.
Therefore, the Organizers of the AgileCamp 2013 invite Ken Schwaber, David Anderson, Dean Leffingwell to discuss face-to-face the challenges of scaling agile across enterprises and openly discuss the value of differing approaches that each brings to the industry. AgileCamp 2013 (www.agilecamp.org) takes place in San Jose, CA on 9/21 at the eBay/ PayPal campus.
While our conference sessions for this event are already planned, we would pre-empt a part of our schedule to accommodate this community building opportunity.
I believe that the Agile Community would love to hear this conversation and maybe, we can reach a common appreciation and understanding of Scrum, Kanban, and the Scaled Agile Framework.
Thank you for your consideration!
Stacey Louie
AgileCamp 2013 Chair
http://www.agilecamp.org
info@agilecamp.org
Ken, I wrote an essay inspired by this post of yours. Here it is: http://www.targetprocess.com/blog/2013/08/back-to-the-future-of-agile-software-development.html. I guarantee that you will find it worth reading: fresh thinking + interesting insights. Sorry for this self-ad, I just have no other choice as to forget about humility and pitch this essay to top, to make it stand out against tons of shallow content on the web. I wish more people wrote stuff like that. This essay gives some tangible, meaningful answers to the year-long dilemmas of agile movement.
I just wonder why the RUP and SAF guys were at our conference and you were not Ken.
Come on. I asked all of you to be polite.
Pingback: Tillbaka till Framtiden för Agile Software Development | Dimmrar
Pingback: Methodology Wars – Contradictory Constraints or More Options? | All About Agile
Pingback: Back to The Future of Agile Software Development | All About Agile
Pingback: ILX gets DSDM and goes Agile… maybe | An Accidental Project Manager
Michael James, CST also wrote about this topic back in January here: http://agilemethodology.org/playing-it-safe-can-a-large-organization-do-agile-without-changing-anything/
Pingback: – Agiled.co
Pingback: Scaling Agile | Tales from a Trading Desk
Pingback: SAFe – Command and Control Agile? | DevOpsNet
Pingback: SAFe under lupp | Squeed Team Blog
Pingback: Desenvolvimento de software, tecnologias e outros assuntos #9 | Andreano Lanusse | Tecnologia e Desenvolvimento de Software
Excellent! I’m a scrum master who now runs the PMO for a mid-size Silicon Valley company. As we’ve scaled I carried forward the principles mentioned above, kept the teams in charge of their slice of the overall roadmap, and we’re doing GREAT (30 teams and growing, 98% on-time). I was skeptical of SAFe due to its origins, but felt compelled to understand it and see what I could borrow. With this I’ll save the conference $s (and four days of my life) and just buy the book. Cheers!!
I know this is an old post but maybe you will get an alert and can answer. I’m currently on a $250m a year software program that is transitioning to SAFe. I have been through the training and I have been doing some agile for some time now (very much in line with the philosophy of the manifesto and non-prescriptive). On face, SAFe does appear prescriptive. However, my take away has been much more along the lines of presenting best practices, patterns, and logical constructs (trains, system/integration teams, product management teams) that embody principles of the manifesto versus providing a strict plan for implementation of the framework. There are some things that are prescribed, yes, but not any different than Scrum. Every Scrum team must implement a retrospective, a demo, have scrum meetings, and a planning session. These events address very specific elements of the manifesto. There are similarly prescribed elements in the SAFe framework.
The reason I am replying here is that I am very open-minded and believe in lean and agile very much. Your post mentioned scaling Scrum to 30 teams. I did some looking and found your post “Agile Portfolio Management” (http://tinypmo.wordpress.com/author/soupshark/). In there you go through some details on how you scale your roadmap based on projects. To me, a lot of the concepts are also included in SAFe. I challenge you to think about how you would structure a detailed explanation and training around your concepts. My guess is it would eventually become “bloated” looking like SAFe. However, you know that it is not because you have lived it and it grew organically. Perhaps the same lens can be applied to the conversation around SAFe.
I am very interested in finding out more about how you managed to scale at that level. The problem our teams are facing is that we effectively have ~300 software developers that need to integrate their products with hardware teams and labs that are not operating in an agile manner. All of the products eventually integrate on one vehicle. This makes for a complex integration tree with multiple levels of fidelity. We can never be truly agile, we know that. My goal is to insulate the individual Scrum teams as much as possible from the churn at the program and portfolio level. My hope is that we can apply many principles of the manifesto with the ground floor being fully (mostly) agile and losing some agility as we move up the stack to the portfolio. Imagine having to do things like earned value management with resource loading and budgeting with 40 scrum teams and not losing some agility.
Perhaps that was the point of Ken’s post. SAFe is not agile because the companies that it will mostly benefit will never be agile due to their governance, financing, budgeting, and just the reality of their dependencies to other organizations. I do not think that precludes them from getting as close as possible. Tuning something like that to be as close to agile as they can be sounds like a fun exercise and one I am looking to see evolve over the next year here.
Interesting comments… large scale agile adoption is not easy to achieve. As someone who has been trying to accomplish this task for quite some time, I’ve come to realize that we need to tie the layers together. And, up until now, there has been very little written to help large organizations achieve that goal. We all know that implementing Scrum with 10 teams or less is much simpler than 100 teams. There is a place for all of us in the world of agility. SAFe has it’s pros and cons, just like all the other agile methodologies. It makes sense in some places and others it is totally off. However, at the enterprise level, it is the first attempt I have seen in our community to give really large companies a way to scale up and follow both the Lean and agile core principles and values.
Yes, SAFe bends these core values and principles some, but compromise is needed when undertaking large scale transformation. Most large organizations must transform over time, and really what is need is a model that moves it slowly towards the goal of agility. Agility is a journey and not a destination… It’s not a “one and done” type of endeavor. What is really called for is a multiple iteration type of model that turns the “enterprise ship” slowly away from waterfall into the world of agility. SAFe gets us partly there, but there is much more to consider on the horizon. I like the direction of the conversation, there just needs to be more of it! And it was the hottest topic in Nashville this year. We should look forward to this dialog because it means agile is moving into the mainstream. Continuing to combine Lean and agile together is a powerful tool and I for one look forward to the evolutionary path we are on!
Iterative, incremental drives lean. Every bit of fat, waste, inventory, and diverted flow show up.
Ken
> What is really called for is a multiple iteration type of model
> that turns the “enterprise ship” slowly away from waterfall
> into the world of agility. SAFe gets us partly there…
I agree, although this contradicts the thesis of Ken’s post, which is that SAFe is “unsafe at any speed”.
SAFe isn’t agile, but it can leave “waterfall” organizations better off for the use of it, a point Johanna Rothman has made: http://www.jrothman.com/blog/mpd/2013/08/comparing-teams-is-not-useful-exposing-another-management-myth.html/comment-page-1#comment-353529
I only have experience of one SAFe project. It did leave the client better off than before, even though they did not become agile and certainly did not master disruptive change. What SAFe did do was to establish a release train that can probably, over time, be steered towards emergence.
Agile and Lean maturity is sometimes correlated to the Shu, Ha, and Ri levels of competence. It would appear that SAFe can be usefully applied at the Shu level, where bureaucracies imitate agile practice to the best of their current ability, but without having yet developed an understanding of the philosophy or the future changes involved.
I still strive for what people can do with Scrum, but I am also content with what your customer accomplished. As you indicated, it moves them along and whets their taste.
Ken
I’m living proof the “layers can be tied together” without SAFe. Its a simple solution we all understand but requires monumental change where its hardest to achieve, the people in charge. I’m a scrum master who eventually took over PMO and, after failing miserably at roadmap mgt I reapplied scrum rituals and artifacts at the roadmap level (“When you have a hammer…”). Five years later *teams* accept projects into their slice of the roadmap like stories into a sprint. *Teams* slot distant projects like epics in a release plan. *Teams* groom their roadmap with stakeholders each week based on actual progress. *Teams* sew themselves together on cross-functional projects by aligning their roadmap schedules (up to 9 at a time). We just completed our 2013 delivery year with 30 teams delivering 235 *revenue generating* projects (30-40% were cross-functional), 230 on time as promised 4 months in advance. 5 missed by a couple weeks. That’s not huge scale, but it proves the concept. I’m sure we deployed well over 300 projects total.
All of this happens in the same tool we use for sprint mgt, albeit heavily configured for this purpose. No new process required. No new tools required. I admit adopting SAFe seems a lot more achievable than what I’ve been through, but it seems a way of masking the problem rather than solving it.
You saw the problem and addressed it in the manner most appropriate for your situation. And you are still free to adjust it in the future. That required thought and persistence.
Congratulations.
Thanks, and great point. We iterate on our process and tools regularly as we scale through mergers, new product lines, internal recommendations, etc. It’s something I took for granted until your comment. Cheers!
I have seen that Agile adoption by enterprises is ramping up. Many companies have stated that they achieved
remarkable results by adopting SAFe. Have I confused this?
No mistake. I am delighted for those who have achieved great things with SAFe. Contrary to my values and intentions, but I don’t know everything.
Ken
(I’m practicing brevity. So I think I can cut my original post down to)
SAFe. Spent 10 seconds looking at homepage.
Thin slicing.
Not interested.
Can’t explain to you why. No point trying.
And your solution to scaling scrum in a multi-billion dollar, multi-national company is… ? If you have a better approach – then what is it?
Scaling Scrum is, I suggest, neither the solution, nor therefore the problem.
In fact I do not accept that there is any fundamental problem to solve here. The principles on which Scrum is based work equally effectively at any scale. I know this from direct experience in the situation you describe.
But ignoring that. Just because one may not know everything does not conversely mean one knows nothing.
I am certain enough that its wrong to justify spending no further time on it. That in itself is valuable knowledge. It doesn’t require me to posit any alternative.
Peace x
Actually I like to try and be helpful if I can. There is no better text on the subject in my opinion than this and I’m sure it will illustrate for you what is required and how to better construct ones thinking… and prove far more helpful than some prescriptive process power-point-management babble
http://www.lean.org/Bookstore/ProductDetails.cfm?SelectedProductID=159
@Sam… Your second post adds more value. Thanks for the link… it is good stuff regarding Lean. A lot of it is actually used by the Scaled Agile Framework.
My point is that if people are not educated in a certain practice (i.e. Scaled Agile Framework), it’s not helpful when they criticize it out of ignorance. It merely creates waste in the form of unnecessary, uneducated debates. I’d offer that prior to criticizing it, people should take a deep look into the framework first and comment from a fact-based perspective… not an emotional & judgmental one.
We’re all about people over processes. We embrace that while we value the stuff on the right, we value the stuff on the left more. It also does not mean that we should toss out the stuff on the right completely. In the future, I’d love a deeper conversation about SAFe where we can have a more full, meaningful, and constructive conversation.
You’re right. The original point I was making was somewhat flippant.
Its just not news to me, after 20 ish years I’ve sort of seen it all before. I don’t doubt for a moment that there’s some good in SAFe… when one considers that many projects were actually delivered successfully using Waterfall the very same must hold true for that. The point for me is that I don’t actually want/think its worth me investing any time or effort into digging into it. I’m not going to take hours and hours digging only to end up discovering there isn’t an original thought in there. (I can’t be certain of course, but I’m an odds player 😉
Frankly there’s so much of this kind of stuff knocking around one has to be quite ruthless about where one spends time and energy.
But to be clear, there was nothing emotional as such about my reaction. After a lot of years looking at this sort of material in one form or another I’m now fairly sure my I can judge a lot from a quick scan, at least just as much as I’d learn from a more in depth analysis..I saw a similar horror emerging at Nokia a few years ago… hence my reference to Thin Slicing..
http://en.wikipedia.org/wiki/Thin-slicing
Two sides to every story. I believe Ken and others is forcing us to think and apply our experience as well.
I see SAFe proponents wanting a roadmap of sorts but again this could produce the same dysfunctions we are trying to avoid.
There are some really nice concepts in SAFe that aren’t as well spelt out in other literature that I’ve seen like the architectural runway (metaphor anyone). In this respect it’s useful to add to your kitbag and subscribe to http://oathofnonallegiance.com/
Overall I have a bias toward Sam/Ken. As this article mentions http://agileatlas.org/articles/item/agile-at-scale-leading-change – we have a crisis of leadership and if we work to solving this then the issue Scrum makes obvious can be seriously tackled.
Pingback: Scaled Scrum | A Moustache on the Mona Lisa
Pingback: unSAFe at any speed | www.thought-bubble.co.uk
He scored a spot on the first page of Google for one of
the things that you need to think about is getting together a lot of information.
For marketing book covers beginners, network marketing books, one of the things that you need to think about is getting together
a lot of good information on network marketing that is not an infinite quantity of prospects.
In the book, some of the best ones that you can use as shortcuts
in your business, but can help you develop your own patch
to success.
Its little bit new for me. I watched RUP conference and waterfall conference video in an other blog.
I think conference is a great place to share your ides, knowledge and Information with other and learn to others experts experience.
We just released a guide that might be of interest to many of you related to this topic. It aligns with the barriers to agility that I have seen for years in both large, commercial entities and multiple Federal entities. Success with Agile, including basic Scrum requires more than individual Agile teams. I have learned through real Agile execution and consulting for over 14 years (and using some Agile and lean practices in Waterfall delivery longer than that), that you also need to implement lean principles and have some ability to integrate those many teams front to back and deep and wide. There are a multitude of great people and frameworks that will get you there faster. Enjoy…
http://www.businessofgovernment.org/report/guide-critical-success-factors-agile-delivery
Pingback: Agile Skalierung: eine Kollage | Stefan Roock
Ken Schwaber is, to say the least, a thought leader of our time. His continuing contributions to the field of software development is undeniable and we’re grateful for that. I regularly read and learn from Schwaber’s writings, be it his blogs, books or publications. Above all things what I respect about Schwaber is that he is a fellow human being, fallible just like the rest of us.
Reading Schwaber’s works it is easy to recognize that he has a very short fuse and has no tolerance for people going off message. Schwaber dismisses these not-so-pleasant qualities with a simple entry in the About section of his personal blog “Ken Schwaber’s Blog: Telling It Like It is” as:
— “My blogs may be edgy, full of unproven opinions, sometimes unsubstantiated, and critical. Some of you will find them useful, even enlightening. For everyone else, the blogs aren’t written with you in mind.”
I’m one of the “everyone else” people, but I will always read Ken Schwaber’s blogs, books and anything else that he cares to publish because he always has something valuable to say. But what enforced my belonging to the “everyone else”‘s camp was when I read his blog entry titled “unSAFe at any speed” and in particular this section of the entry:
— “The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization. They have made their approach even more complicated by partnering with Rally, a tools vendor. Consultants are available to customize it for you, also just like RUP.”
What appears to be driver for this blog entry is the statement “Consultants are available to customize it for you…”. I don’t know much about SAF and from what I’ve seen and read it is not for me so I won’t be promoting it. Again, my knowledge of SAF is very, very slim but even looking at the diagrams of what SAF is makes me dizzy so I remain convinced that Schwaber is right about SAF. But I also believe that it would have been much more useful if he had stuck with the fact that “context” is king or we have the basic framework for Agility in the form of Scrum, and as long the framework is implemented then even home-grown methods will do – just as he puts it so eloquently in his blog post titled What Comes After Scrum? But just as he attacks RUP and SAF for their vulgar commercialism (my words not his), we see, almost in the same breath, he promotes Agility Path (TM) by sharing a link to a pamphlet with the most enlightening sentence at the end of the pamphlet:
— “A licensed Scrum.org engagement manager performs a Snapshot with you. It takes approximately five days. Data is collected and correlated. The engagement manager presents the Snapshot report to you.”
There is old saying; “Those who live in glass houses do not throw stones.”
While Ken doesn’t need defending (he’s obviously quite capable), I think it’s worth noting there is a difference between peddling a “customized” solution and an assessment. The issue with SAFe is not so much the practices involved, but rather the prescriptive nature of the model.
Absolutely. That is what a methodology did, proffered a prescribed approach that will work for any organization, any context. A silver bullet that doesn’t require that hard work of figure out your needs and the best solutions.
Thank you for your reminder and rejoinder.
As people and organizations have responded to the benefits and possibilities and Scrum and agile thinking, we’ve seen an influx of people whose primary desire is money. Their approaches, tools, and methods may be good or not, but benefit is less the motive than commercial gain.
I’ve had many, many customer ask me how they are doing, how much better they are doing than a year ago. The entrance of SAFe, the IPO of Rally, and the flood of “just in time” experts and training companies make an ability to answer that question even more important. If organizations invest heavily into “silver bullet” solutions, the credibility of the agile movement will be the one to take the hit.
I’m posting a blog about this now.
Thanks again,
Ken
Pingback: » Definition of Hypocrisy Siamak Shams
Luis Goncalves made a fantastic comment about the monetary greed involved, those in glass houses shouldn’t throw bricks… to stay a ‘certified’ scrum master I have to pay, nothing more.. just pay…
On the larger picture, sure, this will be another bunch of processes, consultants and money making. The way to beat them is to show that they are not needed not to rant about them. Just getting the basics of an agile process is incredibly difficult, most places fail at least once for various reasons. Practical help, short courses, good discussion forums for people to ask will help stifle the worst of the money making guys.
You really don’t need my email, it isn’t really required, I don’t need a reply to my email account nor do I need it added (by accident or hacking) to even more spam lists 🙂
Pingback: Two reviews of SAFe (Scaled Agile Framework) | Agile Advice
Pingback: Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives? | The Scrum Crazy Blog
Pingback: When to use SAFe (Scaled Agile Framework) | Agile Management
My current organization has gone SAFe and somehow along the way, the additional leveling / structure has increased focus on process and less on the people that perform the work. +1 this is an awesome read; thx for sharing
@apemberton – your message is puzzling me. Is this focus shift from people to process a good or bad outcome for your organisation?
Welcome. If you approach agile as a cookbook, the result is always unfortunate.
Pingback: Why SAFe still does not convince me | Global Agile Software development
Pingback: How much Agile brings you SAFe?
Pingback: In defence of the Scaled Agile Framework (SAFe) | Drive growth, deliver better quality services faster and reduce costs
Pingback: Cults of Personality and Software Process Improvement | Semantic Werks
It seems that if one is not following Scrum rigidly, they are not somehow Agile. You say agile values individuals more than processes, and then go on to prescribe a method (Scrum). You create a shop; selling books, courses, training and certifications. Ironically when someone else tries to propose ideas like Kanban or SAFe, they are somehow evil.
Scrum, XP, Lean, Kanban, SAFe and the whole Agile movement, is not the point. If any of the methodology, practice or principle become bigger than the organisation, their people and their projects, then it all becomes pointless.
I like a lot of things in various agile methods and use bits my organisation and the team needs. Full stop. I don’t need to follow Scrum or Kanban or any other label. One of my Psychology professor said “If someone tells you that there is only one of doing something, be aware, they are selling you something”. If I am not doing Scrum, I am not Scrum-bum or Scrum-but, just because people who don’t “buy” your product, please don’t downgrade them or their efforts.
Oh yes, I am Certified ScrumMaster; which is exactly why I am not using Scrum as-is. It helped me pick up the good bits and things that don’t work for our team. By the way, “Master” isn’t a good word, but that’s another story…
You must be a very wise person to have such perspective and insight.
Pardon me if I am opening up a can of worms again by posting this now. I got to read this post after reading Ken’s new post about Organization blog. Almost 3 years after Ken posted this, SAFe is still around and more organizations are seeking and implementing SAFe. So Why? How long would it take for people to realize SAFe is not Agile. Not that there is anything wrong with not being agile but I can’t help but feel that SAFe folks are stealing or miss-guiding people or disguising themselves as agilists. THAT IS THE BIG PROBLEM.
So, here we go – Tahir you miss-understood Ken’s points on SAFe. SAFe is not Agile, as it violates the very first principle of the Agile Manifesto – Individual and Interaction over Process and Tools. SAFe focuses more on processes and tools over teams working collaboratively creating working software in the name of scaling agile. To scale, we need to have this upfront release plan and lay out all the plans ….
SAFe is not necessary an evil but what bother me is that it disguising itself as agile. IT IS NOT! That is the problem. Call it whatever but don’t call it Agile when it focuses more on the planning than individual interaction.
Agile is 4 values and 12 principles. Nothing more and nothing less. Agility, therefore, is alignment to these values and principles. I see a lot of Scrum teams that are not agile and I see teams that use none of the “agile frameworks” that are infinitely more Agile than most that are. SAFe combines Agile values and principles with the “Principles of Product Development Flow”. The main one to consider is Principle D7: The Principle of Alignment, There is more value created with overall alignment than with local optimization. Your argument: “don’t call it Agile when it focuses more on the planning than individual interaction” just doesn’t wash as it’s just Scrum (or Kanban) under the hood and utilizes the same, exact, time-boxed planning techniques. It just does slight larger batch sizes as an optimization for enterprise level planning. Neither Scrum nor SAFe is Agile by itself. We have to bring it. That’s why I combine SAFe with User Story Mapping and Specification by Example (BDD), as well as the other XP practices.
SAFe is one Agile framework (and so is Scrum, and DAD/AWD…and now LeSS). As I mentioned in my previous response to this, having frameworks that provide guidance on scaling is great, as opposed to having everyone in the world start with the manifesto alone and re-invent the wheel with every client, when the practices have been very well defined in multiple Agile methods/frameworks. BUT…I do concur…that when your focus is implementing the framework with too much rigidity, and certifying people on it, as opposed to using it for delivery of a product/program, and adapting it as you execute, that is where it falls down. I have seen a couple of recent SAFe implementations so far where the focus of an engagement is implementing SAFe (and typically the client forces breakage of key practices), and getting expensive certifications. Like anything, it is all about how you implement it..building stakeholder sponsorship, implementing the practices required to deliver the initial scope of work Agile (for my clients, that has some degree of scale), then continuing to improve.
@Timothy S. Walker – I don’t see “Reply” link to your post for some reason. So here we go. I think you are mixing Framework with Implementation. Here we are talking about whether SAFe is an agile framework or not. My opinion is that it is not. What each does with the implementation of a frame is a topic of another discussion. Please don’t confuse them. You can’t blame the framework cau people not implement it the way it should. You know – “You can lead a horse to water (but you can’t make him/it drink)”
In my opinion – LeSS framework is the right approach at scaling Scrum. Also check out how Spotify scaled their squad -https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/ and https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
Pingback: LAST 2014: Comparing Ways to Scale AGILE | Ruma Dak's Blog
Pingback: Can we introduce real Agile mindset in a large traditional organisation? | LeanArch.eu
Hey this is somewhat of off topic but I was wondering if blogs use WYSIWYG
editors or if you have to manually code with HTML.
I’m starting a blog soon but have no coding know-how so I
wanted to get guidance from someone with experience. Any help would
be enormously appreciated!
To Start either create a Blogger account with Google or the same with WordPress. Its completely free and requires no HTML/coding skills whatsoever and is, to some degree WYSIWYG… you’ll be up and running in under 10 minutes. Blogger is perhaps a slightly lower barrier to entry, but WordPress tends to be more popular and there’s more technical wizardry available further down the line..
WYSIWTG
Pingback: Scrum, XP, SAFe, Kanban: Which Method Is Suitable for My Organization? | Toocan
Pingback: A case study on applying Scaled Agile Framework (SAFe) | Nguyễn Vũ Hưng's blog on Free and Open Source
Pingback: Is agile is the new Unix? | TDB Systems
Pingback: Scaled Agile Framework (SAFe) – Is It Agile? | Making Better Software
Pingback: Really, how SAFe is it?
Pingback: Thou shalt cause no harm, Thou art SAFe! | Niraj Bhatt - Architect's Blog
Pingback: So: What does “#NoEstimates” even mean, Anyway? | cumulativehypotheses
it will be quite secure in the coming days. Nigeria seems to be the next population for btc to be put in circulation
@Timothy S. Walker – I don’t see “Reply” link to your post for some reason. So here we go. I think you are mixing Framework with Implementation. Here we are talking about whether SAFe is an agile framework or not. My opinion is that it is not. What each does with the implementation of a frame is a topic of another discussion. Please don’t confuse them. You can’t blame the framework cau people not implement it the way it should. You know – “You can lead a horse to water (but you can’t make him/it drink)”
Bottom line: We bring agile to the framework, not the other way around. If you would posit that SAFe is not agile (you’d be right, it’s a framework, not values and principles), that you would be remiss in not saying the same about Scrum.
The SAFe is a framework that posits a value system and principles. Exactly like the Scrum framework. In fact, the SAFe inherits its value system from the same management theories as Scrum.
Recent update to Scrum Guide include values. The updates that will include the Scrum Development Kit will contain immutable development/operational principles and suggested practices.
All, really agile, and free.
Pingback: When and how can Scaled Agile Framework (SAFe) help you spread agility throughout the enterprise? - Henk-Jan van der Klis
Pingback: Back to The Future of Agile Software Development | Targetprocess - Visual management software
Reblogged this on and commented:
Schwaber and his negative feelings about SAFe. Reads a lot like the jilted sister. “Only I am allowed to improve. If anyone else does it, they are merely copying me. – Ken”
The idea that SAFe is crap is at best misguided. Any framework is OK as long as the people affected are choosing to try it on an experimental inspect-and-adapt basis. This includes SAFe. The reality is that 99.9% of SAFe implementations are a mandate of specific practices by authority. And THAT’s the problem with SAFe. This mandate almost never works long-term, as it just literally kills self-organization. Self-management (aka “self organization”) is the true source of genuine Agile transformation and any genuine (exponential) progress with KPIs.
By this measure, even Scrum is in trouble when it is mandated by authority without consent of the governed. The way to get consent is for authority to teach “committed experimentation,” and invite experimentation. And also for authority (this is essential) to promise and deliver an “all-hands,” opt-in, inspect-and-adapt retrospective event, at the level of enterprise. This is exactly how OpenSpace Agility (OSA) works.
The problem of course is that authority is usually unwilling or unable to “go all the way” and apply Agile principles to the Agile adoption itself. “Push” is used to implement Agile “pull” systems. These mandates smother any possible emergent self-management. This is an obvious problem worldwide. The solution is obvious and it can be so much better.
Very few organizations who adopt Agile even begin to discuss (let alone arrange) an “everyone invited, 1-day or more, periodic retrospective on the so-called “Agile transformation.” The entire idea of an all-hands, everyone-invited enterprise-wide retrospective (inspect and adapt cycle) is not found anywhere in the Agile literature, except in OSA. If it exists, can someone please direct me to where any reference to it can be found?
Any framework is OK as long as the people affected are choosing to try it …on an experimental inspect-and-adapt basis. This is not the state of the art in “Agile transformations” today. Perhaps this is a (major?) contributing factor to the very poor results most organizations achieve in their very expensive “Agile transformation” programs?
Daniel Mezick
http://www.openspaceagility.com
Daniel, you need to look at Day 2 of the Program Increment Planning event in the SAFe. Learn before you judge.
Yo, hingedthinker. That’s exactly where I want this conversation to go. PI Planning is great.
Question: is Day2 an optional-to-attend meeting??
I reassert: the entire Agile community mandates practices on a forced-march (no opt out) basis. It’s not an experiment. It’s a mandate of practices. Often without any emphasis on the “why” of the 12 principles.
And there is no opt-in, enterprise-wide, at-least-one-day retrospective in the Agile adoption itself. Not an enterprise retro on the last delivery. Usually by a few authority figures (not the whole group.) Rather, I’m talking an enterprise wide, everyone-invited, no sanctions for not attending, retro on the entire Agile adoption process, up to Now. No one is doing this. This technique is 100% aligned with Agile principles. And no one does it. Push is used, push is standard. All in the name of pull. This makes no sense whatsoever. Unless there is something besides genuine Agile going on.
and also, you are wrong about SAFe being a mandate. Utterly wrong. So the reality is that you are 99.9% wrong. It is a framework. Why do you guys spend so much energy trying to tear down other frameworks? So negative.
Can anyone out there show me a SAFe implementation at scale that is not a mandate of practices from formally authorized leaders? To be clear, SAFe is a set of practices. Therefore, any mandated-by-authority SAFe is by definition a mandate-of practices, the exact opposite of an an experiment-with practices.
Any non-mandated SAFe needs to be: 1) an enterprise-wide time-boxed experiment to be inspected, and 2) an experiment in which everyone involved has “no objections” to trying in advance of a complete retro of inspect and adapt. I assert that almost all improvement from KPIs long-term come not from practices but rather, people who self-manage aka “self organize.” You ain’t gonna get much self-management from people who are not making decisions.
To be clear, 99% of Scrum implementations are also flawed in this very same way. I’m not singling out SAFe here– mandated Scrum or [whatever] is also a crime. Mandated practices give Agile a bad name. The mandate is the antithesis of Agile. It’s not respectful. These are mandates– not experiments. This makes no Agile-sense whatsoever. See also http://martinfowler.com/bliki/AgileImposition.html.
Can I give you an exact project – no. That’s because enterprises that are adopting SAFe do this on their own. They always adjust the framework for a variety of reasons; culture, industry etc. and are encouraged to “experiment”. It has to start somewhere with something but morphs to what works best on a continual basis and those experimental changes or ideas come from all levels; teams, programs, etc. Does it start off with a heavier hand of prescription than we would all like? Yes. At least face the reality to turn an enterprise around fits the oil tanker analogy. It takes time, commitment, and a lot of moving parts but each one is unique in process and procedure based on empirical experience of their ship. Along the way I have always seen things change from introspection, many contrary to the core SAFe framework. That’s not saying it’s the only game in town. But really, Agile was not created with the idea of 10-15 teams working in concert with large enterprise standards and core groups like Devops, etc. I’ve done this long enough to know that large enterprises IT needs and setup are simply cluster f….s. and need some prescription up front to begin to unwind the mess and confusion – much less culture.
I guess I was wrong. Just look at the many SAFe success stories: John Deere, Capital One, …
You can. Here they are: http://scaledagileframework.com/case-studies/
True or False: SAI is offering discounts on annual licensing fees for SPC4 if and when you submit an approved case study.
If True, I assert that this amounts to paying compensation for positive “case studies”
Pingback: Scaling Agile with SAFe (the Scaled Agile Framework) - Elabor8
Pingback: unSAFe at any speed |
I just had a two-day training on SAFe. This framework is engineered to appeal to decision makers of big organizations, especially when it comes to budget spending. Unlikely to deliver value (theoretically it could at very large companies which wish to pretend they are agile) but guaranteed to attract spending. Genius work!
Rock on!
Good article and straight to the point. I don’t know if this is really the best place to ask but do you people have any ideea where to get some professional writers? Thanks 🙂
We implemented SAFe in July last year, and I can draw a few conclusions
a) it gives management more control
b) it alienates people
c) it provides SAFe consultant an IV line into your business (we still have our residence SAFe leech sucking us dry)
d) it makes CIOs look good to the CEO.
e) any extra value delivered is offset by the overhead and ceremonies of SAFe
My advice, stick with Agile\SCRUM\Kanban, ease people into across the business (IT and non IT) use Atlassian tools like JIRA and Confluence and make sure the whole business leverages them, also use your Kanban boards.
SAFe is self serving for nest feathering managers and leech consultants, you don’t see people at the coal face pushing for SAFe do you ?
Dear Ken
It has been quite some time since you wrote this. Though you made sweeping reference to ‘John Deere, Capital One’ I wonder what is your current position.
Here are some questions for you.
– Even though other early models like Rapid App Development, etc. followed empiricism theory, it wasn’t disruptive. Its successor ‘agile’ was disruptive because it recognized the most critical element ‘the human’ in SDLC. SAFe actually takes that into account in its own way and allows the people to start from ‘Shu’ part of Shu Ha Ri like Ian Mitchell called out.
Even the Scrum starts from Shu as well. Wouldn’t you agree if a team breaks a rule of Scrum in Shu stage? The level of prescription by SAFe is more probably compared to scrum. But SAFe allows every single prescription to be customized or broken as the team moves to subsequent stages. What hurts you more? Is it the emergence of agile thought leadership from non-manifesto group or is it the fundamental flaw in SAFe itself?
– SAFe brought many elements of lean in the context of Agile that Scrum or XP or even Manifesto didn’t leverage much. For example, the ‘flow.’ It is such a powerful concept that many manifesto signatories wholeheartedly claimed later as part of agile. If Empiricism is your push Flow is SAFe’s push. Why can’t you allow SAFe to hold this contribution like you do it for Empiricism?
– SAFe also gave shape to another proven human-machine concept ‘There is a time and place for innovation.’ It is manifested in its IP iteration. Would you disagree that many scrum teams that steadily improve over the Sprints get stuck later without disruptive product ideas later, may be because there is not enough enablers like SAFe has?
– SAFe was the first to talk about synchronization and cadence between multiple scrum teams. In your early version of nexus it wasn’t there. In later version, you appear to endorse that a lot. Why won’t you view that this place is continuously evolving and someone else might have had an early breakthrough before you?
– SAFe was the first one to arm twist the organization managers into thinking about their relevance in agile world. It pushes them to become lean agile leaders. While earlier version of scrum (even the current guide) denies any role of managers within the team, a lot of Scrum experts (your PSTs) seem to endorse that line managers will continue to exist and they have a role to play. Won’t you concede that SAFe did a better job here?
– I do agree that SA is commercially oriented, their training is expensive, there is recurring revenue stream from certifications and expensive renewals, etc. I have a lot of respect for your certification schemes like Professional Scrum Master that continue to hold high standards for passing while many counterparts have gone the ‘make it easy to get certified and make money in the process.’ Probably SAFe wants more financial viability for future work leveraging their knowledge without diluting the standards though. Is it wrong to charge (may be bit more premium) money for the work?
I have more questions to ask. I will hold until I see your response. Meanwhile, I am sure you haven’t spent any ‘unbiased’ time on knowing about SAFe. May be the amount of material on scaled agile website scared you. Here is a fantastic short book on SAFe fundamentals “Get SAFe Now” (https://www.amazon.com/dp/B01M1GI80M) that you can quickly skim through before the response.
My intent is to present an honest professional view point from my vantage point. I am eager to listen to you and learn.
Tom
You clearly have given the subject much thought, as have many others. There are many ways to use Scrum. Unless I’m really shocked by the topic or approach, my approach has been: measure it and see if it improves or worsens the delivery of software. For this purpose, I developed evidence based management (EBM), and objective way of assessing the value of a software development approach. Why don’t you try it and see how your different approaches turn out. In that inner we will talk about outcomes, not philosophies.
Best,
Ken
I do respect the knowledge that you all have in this field, however I can’t see anyone (except maybe Sanchez) highlighting the real chasm between the waterfall approach and the agile way of working which to me is budgeting and PMO, the whole Command and Control apparatus. All too often I see PMO’s assigning resources to projects and teams who then do Scrum underneath the hierarchy driven by Command & Control. This hybrid way of work is all good to a point. But beyond that I think you need to address the hurdles of stopping and going when trying to get a value stream to adopt and implement requirements across a spectra of supporting systems. Even if this might be a well-known aspect within the Agile community I seldom see a discussion addressing the way a company does development seen from an executive level. What is the point of doing agile if you constantly are feeling misunderstood by upper-management? Sometimes it seems to me that the rebellious attitude of the agile community is more important than the actual improvements we are trying to achieve. From my viewpoint, often in the gap between the managers expecting progress without own effort and the developers busting their asses to reach the highly set expectations, I have not until now found a framework/platform that gives me a set of good arguments on why LEAN/agile within software development should be approached holistically, i.e. adaptions are necessary on all levels within the organisation to reach flow. To me this weight tons if done correctly.
Traditional software organizations have diametrically different values and operation from an Agile, Scrum based organization. You cannot simply paste a new approach on top of a traditional organization.
I wrote a presentation on this problem and how to measure its impact on staff ( https://goo.gl/jNm9eD )
How do the good folks at Google and Facebook do Agile at scale? I have read there is no process there.
Not an expert but it would seem that any methodology would become prescriptive and therefore dependent on context. No methodology is a cure all.
If context is everything then rather than trying to duplicate Google, Facebook or Netflix’s approach, wouldn’t it better if we understand the underlying philosophy of these companies and then operationalized that philosophy in our own specific context?
SAFe and others are trying to plug the operationalization gap by offering managers and manged a system of paint by numbers and checklists (they don’t exactly call them checklists but the end result is close enough) and promising them a better future. One doesn’t need to be a Mensa champion to work out that the paint by numbers agile implementations are most likely to fail durability and longevity tests.
In this fast moving, nationally and globally competitive, do or die commercial world, the executives of companies may feel vulnerable and almost all recently introduced enterprise agility methods and frameworks are trying to profit from such vulnerabilities by offering people fake magic solutions. That is dishonest and objectionable.
Back to “how do others do it so well?” question. It’s easy to find out about the underlying philosophy of the successful companies. Netflix says about this matter here: “http://www.slideshare.net/reed2001/culture-1798664”
These companies seem to have three intertwined and inseparable components working together:
— Clarity of shared purpose,
— An organisation designed to deliver the shared purpose in the most efficient and effective way,
— Skilled, empowered, self-organising group of people with rights and responsibilities to deliver the shared purpose.
Getting the above three components implemented in the context is the real magic – and it is the successful implementation of the above that separates Google and Facebook and others from the rest of the pack.
Incidentally here is a publication on Agility in Context worth reading: “http://homepages.mcs.vuw.ac.nz/~elvis/twikipub/Main/RashinaHoda/oopsla2010.pdf”
Don’t know. When I visited Google in 2005, they were just experimenting with Scrum, over make it yourself
Please stop with SAFe being RUP model version 9. Yes, Dean did learn a lot about marketing at RUP, and yes, some of their sales techniques and model are similar. It worked well enough to get IBM to buy them. But saying that SAFe is one size fits all is a fallacy. SAFe is for large scale efforts and it is a framework where pick and choose what you need, modify what you need, rtc. Not a single company I’ve worked with pastes on SAFe and follows it in it’s completeness. I’ve seen some outrageous changes that don’t deviate from the Lean/Agile base.
What is the one thing every customer says? ‘We’re different.’ and you have to work with that.
Good question. This, from a Google developer in 2006, is (still) excellent. It’s 11 years on but I’d be surprised (and horrified) if they’d converted to SAFe, or Scrum.
http://steve-yegge.blogspot.com.au/2006/09/good-agile-bad-agile_27.html
Me too, especially now that they are an alphabet soup.
Pingback: FABRICATION SANS GASPILLAGE ET AGILITÉ EN DÉVELOPPEMENT LOGICIEL LEAN THINKING AND AGILITY IN SOFTWARE DEVELOPMENT – Michael Ouellet Conseiller Agile
Pingback: Is SAFe® Agile? - Digité Blog
Pingback: Ten cuidado y no estés tan seguro con #SAFe - Javier Garzás
Pingback: 6 mois de SAFe (c), ce que j’en pense ? – Culture Agile
Pingback: Scaling agile safe and sound – Dr. Agilefant's Blog
Pingback: 6 mois de SAFe (c), ce que j’en retiens ? | OCTO Talks !
Ken,
How does Nexus differ from SAFe? Do you still feel the same about SAFe after all these years?
Regards,
Joe Townsend
Nexus is a simple framework that fits on top of Scrum, facilitating productivity in the face of dependencies. It is hard to implement, because you still have to do the thinking. Nexus will probably only be favored by hardworking, professional people.
I still feel the same about SAFe. Great name, but a terrible money play that distracted any number of companies until they underwent the catastrophe of using the wrong processes on the act of software development (etc.).
Doing things that have dependencies by ignoring them (as the many Scrum Teams practice) is simply wrong and should not be done at all. In my practice, Scrum does not work across several Teams tasked with a shared task, i.e. a thing like Nexus is a must have, it is not an add-on. SAFe has full freedom to change the process at any moment with no or minimal impact on other parts of the framework because they are not tied but loosely-coupled. What “catastrophe of using the wrong processes” are you talking about and why a wrong use becomes a problem of the thing used?
Pingback: Frameworks to Scale Agile - Some comments - Lean Agile Training
Pingback: A Brief History of Agile – Agile Ideas
Pingback: Back to The Future of Agile Software Development - Targetprocess - Visual management software
Pingback: Flavours of Agile – patkua@work
Pingback: 来自PMO的反击 | DevOps 博客
Pingback: Pensando produto e evitando armadilhas - Knowledge21
I worked as a software consultant with a company who was adopting SAFe Agile from a vendor. I found this article while researching why in Holy Hell they had division-wide scrum ceremonies where all teams presented their retrospectives in front of management. Over the last many years, I’ve seen scrum corrupted by organizations and metrics co-opted by management. I spend more time in meetings and gathering requirements than I do coding. Thanks for the insights.
Spend “more time in meetings and gathering requirements than… do coding” id the right thing to do! Coding unnecessary things is stupid. “Seven times measure and cut only once” – this is a people wisdom.
I suppose I used the word “coding” as a catchall term, which was a mistake. What I meant was “developer things,” which includes software design, code reviews, development team discussions on strategies, finding the best solution to the problem, ensuring efficiency and scalability, etc. “Gathering requirements” I intended to mean “business groups and business analysts figuring out what they want to do.” The more time I sit in meetings listening to groups decide what they want to do, the less time I have to do it when they do decide. After all, the business groups don’t attend my code reviews and architecture meetings, they are not part of discussing how to ensure thread safety or scalability. I hope this clarifies things.
Pingback: JAX 2018 Leadership at every level | elofturtle.com
Pingback: Is SAFe (Scaled Agile Framework) Agile?
Agile Development is not development anarchy – it requires strict governance and clear separation of duties. There are and always were a significant difference between managing a project vs. programme vs. organisation producing products. I see Agile Team as a team of builders – they know better than anybody how to build a wall or a roof, but they far from perfect in knowing what wall or roof should be built. An attempt to escalate the decision-making role of an Agile Team is unjustified and creates more noise and harm than positive outcome.
IMHO, the management part of SAFe is the best available in modern development realm. All agility and flexibility needed by the company from development are concentrated in the professional architecture (not in “Agile Architecture”, which is a developer’s hallucination). Any Agile Development Team may develop only what is required by business capabilities and defined by Architects though how to develop depends on the Team unless it provides the expected outcome (including quality and flexibility).
At the moment when an Agile Development Team alters architectural solutions or replaces them by their own, the outcomes are in trouble simply because such Team does not have concerns and requirements which the Architects operate with.
A mandatory presence of Architects across Agile Release Trains in SAFe puts mandatory constraints on the SW development process, which was omitted in the Agile Manifesto.
The first question of the mouth of my fellow SAFe trainee was, and I kid you not, “will this be on the test?” This person was a manager held in a modicum of esteem. “Keep the values, keep the principles, think for yourself.” This is spot on. I pronounce SAFe; D-O-A.
I thought it had died on the vine.
Pingback: Really, how SAFe is it? | BeardedEagle
Pingback: A Brief History of Agile – Agents of Awareness
My points with SAFe are the hierarchy of things and the strict connect between business and IT.
One, it’s Top Down. IT teams are supposed to make what has been decided by a higher level (project/program/portfolio). This may have worked to some extend in the slower paced past, but with todays companies actually being IT companies that sell a marketable product, it doesn’t hold anymore. It must be the other way around. IT teams create value with the support of business. In today’s world IT is the profit center.
Two, organizational divisions are too tightly coupled. This rigidity doesn’t allow for true Agility and requires to ‘follow the plan’. With too tight Business and IT alignment you loose in Agility. There needs to be some slack.
As with any framework and/or process you can use it as a toolkit for your own implementation of creating and maintain an Agile organization. There are interesting and useful things also in SAFe, but the 2 items above do not contribute to that.
Pingback: All Your Scrum Team Questions Answered - Microsoft Dynamics 365 Community
You obviously have never had the experiences that many have.as one comment in this section said, “SAFe is self serving for nest feathering managers and leech consultants, you don’t see people at the coal face pushing for SAFe do you ?”
Dear Ken,
I just wanted to highlight that SAFe makes explicit statements that “on the team level” it is possible to use Scrum, and even mostly they do… Moreover, they even call one role “the Scrum Master”! We believe that this brings severe damage to organizations and people by means of creating critical misconceptions about Scrum in general and particularly the role of Scrum Master. Now we explained our position with a few arguments based on the current SAFe description. And we invite all Scrum enthusiasts to support this by signing our objection. It would be extremely important to know your opinion about this.
http://remove-scrum-from-safe.tilda.ws/
P.S. Thank you for Scrum – it really helps people to become better, to achieve more at work and life! Self-organization works excellent when the organization creates the necessary conditions. Those who disagree – they just didn’t try the real Scrum.
It’s interesting that you still feel this way about SAFe when more of your colleagues in Scrum.org have embraced SAFe becoming advocates, SAFe consultants SPC’s & SPCT’s. Many Scrum.org trainers now offer your courses as well as SAFe courses in addition to promoting SAFe through presenting at conferences.
Some – yes. But many don’t. This is rather a human nature whether a person has principles strong enough to make it impossible for him/her to promote something that they believe is wrong, but just for the sake of money. Even if you simply check the fast-growing list of signatories on our objection site
http://remove-scrum-from-safe.tilda.ws
you will find a lot of certified Scrum trainers there.
They were following the money. Measure the result.
A Certified SAFe 4 Agilist SA is a SAFe enterprise leadership professional who is part of a Lean-Agile transformation. Key areas of competency include Safe Agilist
Pingback: Practical Agile | Scaling organizations to safety
Pingback: Ten cuidado y no estés tan seguro con #SAFe - Javier Garzas
Pingback: Safe and unsafe words…
Ken, sometimes I just come back and savor this post. It is like a fine wine that seems to get even better with age. Now that we 7 years later, are in a predominantly SAFe world, we can potentially say the forces of Waterfall have won out. And from what I hear, SAFe is still unsafe at any speed.
I am delighted to hear that any way develops software. I prefer Scrum because it doesn’t add unnecessary costs and leads to consistent improvement.
But, it is a free country.
Ken
In witnessing SAFe in action a couple times, I’d say one flaw is the multiple sprint planning that occurs at PI initiation. It appears to lose some of the backlog advantages and moves toward waterfall.
After years of consulting, only those with honesty and a need can overcome tradition.
I agree with Ken’s assessment from many years ago and his stance in general. SAFe provides little value and only adds cost and unnecessary overhead for no real gain.
Srum is enough and using Scrum of Scrums gives you the ability to roll up what needs to be rolled up to Management.
As far as the money question goes, that will always be an issue with certifications, changing Scrum i.e.into SAFe Scrum and other bastardizations of concepts.
Not sure how Ken feels about all this, but I think getting all of them in a room will provide little value or no more than this post has.
To sum it up, Scrum is all you need don’t burden yourself with SAFe….you will only be disappointed.
Regards,
Joe Townsend
Pingback: SAFe is Not Agile | Jeff Gothelf
Pingback: What is SAFe in Agile? - Ascend IT Management Consulting
Pingback: Pensando produto e evitando armadilhas – k22
Pingback: SAFe: Market Share Increase. Rapid Growth. What is the recipe? – Coaching, Consulting, Training
Pingback: The battle for Agile’s soul: Is Agile Theatre taking over?
Pingback: Pensar en el producto para evitar trampas
Pingback: SAFe ist nur eine mittelgute Idee – digitalien.org — Stefan Knecht
Pingback: SAFe ist nur eine mittelgute Idee – digitalien