Skip to Content

Why is there so much SCRUM?

There seems to be no question that agile software development has benefits over traditional methods for certain types of projects and organizations. With so many different agile methodologies to choose from, why is SCRUM emerging as the dominate one? It is fundamentally very simple (there is a 13 second YouTube describing SCRUM). It imposes very little about how engineers approach design and code. Are people just lazy and picked the easy target? Einstein said the development methodology you choose should be a simple as possible, but not simpler (paraphrased a bit). Does SCRUM just happen to fit those criteria? Is methodology adaptability a critical success factor for implementation in any organization?

I would love to hear your thoughts. Do you use SCRUM? Does it work for your organization? If not SCRUM, what else?

You must be Logged on to comment or reply to a post.
  • Hello,

    at the moment we are trying SCRUM first time in a BI project. What I like is, that you break your objective down to sprints and speak in daily scrums about your next step today. I thing this brings internal conversation forward and problems won’t be procrastinated. We also use a wiki for documentation and the backlogs. I think this is very interesting here and supports the method.

    Please, I would be interested in the 13 second scrum video. Maybe you can post the link?

    Best regards,

  • As you probably know, Scrum is a result of Lean principles being applied to the software development area.

    The main focus is to identify and make visible to the organisation work that doesn’t add value and is therefore waste.

    In order to achieve this Scrum has some simple absolute rules that are designed to bring waste up to the surface. How the organisation handles the wastes Scrum identifies is not covered, as this is dependendt on the actual waste. For example if your are not able to produce finished code for a functionality within a sprint of two weeks because of testing effort, you probably need to look closer at automated regression testing.

    I believe it is this simplicity and abstraction that makes scrum so powerful and appealing to organisations; especially ones that are allready implementing Lean principles. Because of this it is much easier to sell the model to mangement compared to individual software development techniques such as pair-programming, TDD and so on. And if you want to stand any chance at all at reducing the wastes/dysfunctionals of your organisation that Scrum brings up, you need to have your corporate champion and management support for the principles of Scrum. For example try getting a 100% allocated resource to the Scrum team in an organisation used to running waterfall projects.

    And there is no reason why scrum should only be used for Software development. In fact Scrum IMHO is applicable to all processes/projects where you have a high degree of uncertainty. I’ve seen quite a few examples of business stakeholdes for IT projects that bring the ideas into their own non-IT organisation with good success.

    However, it should be noted that in the same way as Lean, the rules of the game are simple but take years and years to master.

    Regards Dagfinn

    • Dagfinn, you mention that SCRUM is easier to sell to management than TDD, pair-programming and other development techniques. However I find that SCRUM can be somewhat dangerous if it is indeed not combined with such techniques — since SCRUM focuses on frequent deliverables (in each sprint) it can be easy for the team to get carried away with producing new functionality at the cost of code quality. This point of view is discussed in the following blog:
      • A critical aspect of SCRUM is the concept of complete. If you make it too easy to be complete you are almost certain to fail. I was at a presentation by Microsoft where they had defined complete as code passing all tests where the tests must have a least 75% code coverage where coverage was measured by the Visual Studio tool. You could argue that, that is too simple of a metric, but if nothing else it is a reasonable start. If you find that too many bugs get through then it makes sense to try to understand why during your retrospective then update your definition of complete with whatever you learn.

        Perhaps the problem with SCRUM is that the concept of complete is left totally to the implementor. Same thing goes for estimation and prioritization. It does not dictate how, but you could easily do it well or poorly and SCRUM will succeed or fail in a relative fasion.

      • I definitively agree with you and I believe it is our responsibility as software developers to bring these techniques to scrum projects. Projects will not be successful without them, but at least Scrum will make the problems visible early and will allow you to fail fast instead of failing in a big bang.

        Such practices and techniques do change over time and it is very challenging to standardize on best practice for a diverse set of projects/products. (and sometimes we are too passive with regards to challenging existing best practices). Scrum however is intended to be timeless (there will not be a scrum 2.0)

        In addition, Management doesn’t take ownership for these techniques and we should not expect Product Owners to prioritize investigating them. Instead we should as part of our profession state that this is how we do it in order to deliver quality over time.

        At TechEd I had an interesting talk with Margareth Anderson who has been important in the process of changing all of SAPs software product development to work in a lean and agile way by using scrum. But they don’t call it scrum. They call it Lean@SAP because it is much bigger than introducing scrum to your product development teams. You need to change the entire organisation!
        (I was even corrected by Marge Breya when I asked about which business value, if any, they’ve seen after introducing scrum to the product development 🙂 ).

        Now, SAP should help deliver even more customer value and reduce TCO by sharing experiences and adapting the business suite and other products so that they customers can more easily extend them with an agile approach.
        (for example why not ship all unit test SAP has internally with the product?)


        • Now there is a cool idea for a showcase… SAP RUNS SAP and does it with Agile. Right now I just hear a lot of “but you can’t do that with R/3”. Unfortunately my software engineering and SCRUM experience is with Java and Web technologies, not ERP, so I need ideas from elsewhere on this one.
    • Hi Dagfinn,

      I am not convinced that SCRUM was developed with lean principles in mind. In fact, I think Jeff Sutherland has stated that it sprang from chaos theory among other things. That said, there are some clear comparisons:

      – The fixed (time boxed) iteration is the takt rate of the value stream.
      – Customer value determines the process prioritization.
      – Standard work is defined, standard output is monitored, and corrections to deviations are immediate.
      – The team knows the best way to perform the work.

      For an org implementing lean management, I expect that SCRUM would help a lot by containing the complex knowledge work that is software development.

      I am with you on this “why just software” comment. If you have a complex problem with many unknowns or frequent changes SCRUM could make sense. Like for software you need to figure out how to estimate and what “complete” means.


      • Hi Russ,

        I managed to find an old presentation from Jeff on the roots of scrum where he talks of the link between Toyota Manufacturing Process and scrum. Very interesting.

        The similarities as you point out are quite a few, but there are elements such as “Individuals and interactions over processes and tools” from the agile manifest which is a bit in contrast to Lean.


        • Ah yes… I know this one. It is more good material from Jeff.

          I think even on this element there is a good link to lean. Of the 14 principals of TPS, I think one of the first ones is all about people. At SAP we define a lean “mindset”. One of the 4 elements of the mindset is “respect for people”. I suspect with a little thought we could also find a lean analog for “interactions”.

          Perhaps it is not so useful to look for such direct comparisons. Lean looks at the customer perspective first and everything else comes from there. Perhaps the biggest difference from the agile manifesto is that the customer perspective is third on the list. Probably not a big deal.

          My interest these days is how to connect lean and agile and IT. Agile is a way to develop software, but can we use it to implement and maintain an ERP application life cycle over many years? Can we improve the broader process space of an enterprise IT organization with lean and interconnect with agile development? I am pretty confident the answers are yes, but the devil is in the details and it is pretty hard to find any mature examples of such an org, so I suspect hard work ahead.

          • Let us know when you’ve solved it 😉

            And while your are at it, bring beyond budgeting into the mix (recommended book: “Implementing Beyond Budgeting” by Bjarte Bogsnes)

          • Ya, of course. Great story to tell if we can make it all work.

            The plan cycle must also be a huge part of a lean transformation. We already have experience of where it complicates and or prevents Agile. Talk about inventory!

  • Agile/Scrum has caught on precisely because it is technology and engineering discipline agnostic.  Management (me…I’m the CEO of my company) LOVES Scrum because it is the only way to get a true and accurate reading on project progress.

    We use the methodology at b2b2dot0 for everything we do.  Sure we use it to develop our products, but we also use it for all of our customer implementations, partnering programs, internal process improvements, sales and marketing programs etc. 

    It’s not just about managing risk either.  It’s about assessing real customer value.  If a simplified working model doesn’t excite the customer, than we have to ask the question “what makes us think a further investment will?”

    Management loves Scrum because of visibility.  Project teams love Scrum because of the emphasis on delivering value and overcoming obstacles.  Customers love Scrum because of the emphasis on delivering “real product” to evaluate.

    Seriously, Scrum is not an option in our company.  It is our company.