unSAFe at any speed

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

135 thoughts on “unSAFe at any speed

  1. 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?

      • 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

      • 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.

      • @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

    • 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.

  2. Pingback: ken Schwaber’s rather incendiary rant against SAFe… | brianwernham

  3. 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.

      • 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

      • 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.

  4. 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.

  5. 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.

  6. 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.

  7. @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.

    • 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.

  8. “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

  9. 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.

  10. 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.

  11. 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.

  12. Pingback: Thoughts on how the Scaled Agile Framework is perceived by Agilists

  13. 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.

      • 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.

  14. 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.

  15. 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.

  16. 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!

  17. 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

  18. 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.

  19. Pingback: The Good, Bad and Ugly of Agile 2013 | Jason Little

  20. 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

  21. 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.

  22. 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.

  23. Pingback: Controversy around SAFe, DAD and Enterprise Scrum

  24. Pingback: Agile Methodology wars | DSDM Atern in the real world

  25. Pingback: I’m coming out as not-Agile and not post-Agile | Mike MacDonagh's Blog

  26. 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…

  27. Pingback: The Kanban Method Is A Vehicle – It Is Not A Destination « Agile Ramblings

  28. 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..

  29. Pingback: La tour de babel agile |

  30. 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.

  31. 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.

  32. 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..

  33. Pingback: Back to The Future of Agile Software Development | Edge of Chaos | Agile Development Blog

  34. 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.

  35. Pingback: Tillbaka till Framtiden för Agile Software Development | Dimmrar

  36. Pingback: Methodology Wars – Contradictory Constraints or More Options? | All About Agile

  37. Pingback: Back to The Future of Agile Software Development | All About Agile

  38. Pingback: ILX gets DSDM and goes Agile… maybe | An Accidental Project Manager

  39. Pingback: – Agiled.co

  40. Pingback: Scaling Agile | Tales from a Trading Desk

  41. Pingback: SAFe – Command and Control Agile? | DevOpsNet

  42. Pingback: SAFe under lupp | Squeed Team Blog

  43. Pingback: Desenvolvimento de software, tecnologias e outros assuntos #9 | Andreano Lanusse | Tecnologia e Desenvolvimento de Software

  44. 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.

  45. 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!

    • > 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!

    • 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

  46. (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

      • @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

  47. Pingback: Scaled Scrum | A Moustache on the Mona Lisa

  48. Pingback: unSAFe at any speed | www.thought-bubble.co.uk

  49. 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.

  50. 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.

  51. 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

  52. Pingback: Agile Skalierung: eine Kollage | Stefan Roock

  53. 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

  54. Pingback: » Definition of Hypocrisy Siamak Shams

  55. 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 :)

  56. Pingback: Two reviews of SAFe (Scaled Agile Framework) | Agile Advice

  57. Pingback: Is SAFe(tm) Bad? Is it unsafe? Is it Agile? Are there alternatives? | The Scrum Crazy Blog

  58. Pingback: When to use SAFe (Scaled Agile Framework) | Agile Management

  59. 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

  60. Pingback: Why SAFe still does not convince me | Global Agile Software development

  61. Pingback: How much Agile brings you SAFe?

  62. Pingback: In defence of the Scaled Agile Framework (SAFe) | Drive growth, deliver better quality services faster and reduce costs

  63. Pingback: Cults of Personality and Software Process Improvement | Semantic Werks

  64. http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

    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…

  65. Pingback: LAST 2014: Comparing Ways to Scale AGILE | Ruma Dak's Blog

  66. Pingback: Can we introduce real Agile mindset in a large traditional organisation? | LeanArch.eu

  67. 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..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s