Important Words about Scrum and Tools

Ken Schwaber, the founder of Scrum, has a blog.  In it, someone mentioned that Scrum is changing.  Ken responded:

If you change the Scrum framework you just simply aren’t using Scrum and are probably canceling some of its most important benefits.

Thank you Ken!  I wholeheartedly agree.  Every CSM class I teach, I emphasize the complete nature of Scrum as a single tool, not a collection of tools.  Learning Scrum is about learning the tool, not learning how to pick and choose pieces of a tool.  Let’s explore this metaphor of Scrum as a tool.

Consider a hammer.  A hammer is ideally suited for pounding nails into wood.  It has two parts: a head and a handle.  If you take the parts and use them separately, they can still be used for pounding nails into wood… but they are very ineffective compared to the hammer (although better than using your bare fist).  It is non-sensical to decompose the hammer and try to use the pieces separately.  However, a hammer is not suited to other purposes such as driving screws or cutting wood.  It’s perfection is not just in its form, but also in its proper application.  A hammer works through a balanced combination of leverage and momentum.

Scrum is like a hammer.  It has parts (daily Scrum, Sprints, ScrumMaster, etc.), but taking the parts and trying to use them separately is… you guessed it… non-sensical.  The parts of Scrum combine to be an extremely effective tool for new product development.  Just like a hammer, there are things you wouldn’t want to do with Scrum such as manufacturing or painting a wall.  (We might not all agree on the limits of the use of Scrum… that’s something for another article.)  Scrum works through a combination of pressure on the organization and “inspect and adapt” (continuous improvement).

Please.  Don’t modify Scrum.  If you must change things about Scrum, please stop calling it Scrum.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

9 thoughts on “Important Words about Scrum and Tools”

  1. Agree that Scrum is Scrum – one tool and a good tool but not the only tool, that can help to get the job done. Also agree that if you are not using Scrum as it is prescribed you shouldn’t call it Scrum. I sort of feel a degree of defensiveness about the comment that “Scrum is changing”. Defensiveness or resistence to change often comes from having something to lose and reminds me of the fact that those that do not change and adapt are often left behind. It is the same with tools / methodologies / frameworks / beliefs.

    Agile practices are changing and new agile tools are developing and appearing all the time – change is constant, that is a fundamental fact of life in IT/software development and it is a good thing.

    Is Scrum the perfect answer for new product development? Maybe but over time it will be challenged by other “tools” that may prove better. There are also many external factors that determine the appropriateness and utility of Scrum as a new product development tool that mean Scrum in its pure form might not be accepted therefore it is not the best tool.

  2. Mishkin, I agree with your comments. I find Scrum is like a piece of cloth and when you pull out one of the threads then the whole thing starts to unravel.

    However, when coaching organizations to use Scrum, or better still, to be agile, I have found that being dogmatic about Scrum or agile practices does not help. I often find that if the people can understand why the principles are in place then they can start applying practices and get better at them over time.

  3. To extend your hammer metaphor, there are many different types of hammers: claw, ball peen, tack, shingling, chasing, drywall, … They have core commonalities (handle, head) but also different features (claw, ball, blade[yes, on shingling]). And even the commonalities between different types are similar, but different. Handles are wooden or fiberglass, have an added grip or not, and so on.

    So which one of those is “a hammer” and which ones are not? Don’t get me wrong – I’m clear on how ineffective “scrumbut” is. But I think it’s useful to view “scrumness” as a continuum. And like any continuum, it’s difficult to draw a hard line between when something is and when something isn’t. But to me, there’s room for processes with minor modifications to still be called Scrum.

    1. Hi Jeff, thanks for your comment… and for taking the hammer metaphor way farther 🙂

      It is true that it may be hard to draw exact lines. For example, if the ScrumMaster of a team changes the time box for the Daily Scrum from 15 minutes to 5 minutes, is it still Scrum? Or what about if the team decides to do Sprints that are five weeks long? Or what about two people on the team regularly switching into the ScrumMaster role? These questions are interesting for a methodologist (and maybe for an expert coach)… but are they really important for a team that is just starting out?

      We know that the Agile Manifesto delineates some values and principles. Certainly if we compromise those, then we are not doing Scrum. Scrum also adds some important principles (e.g. Inspect and Adapt). If we break those, just as certainly we are not doing Scrum.

      I think what is most interesting is to include in our thinking not just values, principles and rule, but also purpose. What is the purpose of Scrum? Is it a do-anything system for “Transforming the World of Work” or is it a framework for helping organizations create high-performance new product development teams? If the latter, then the rules of Scrum _must_ be extremely flexible. If the former, by virtue of being a much narrower purpose, then the rules of Scrum must also be much less flexible.

      The problem that then faces us in the former case is that too much flexibility leads to meaninglessness, and, I would assert, uselessness. What is the “nail” of the hammer called Scrum?

      Based on my observation (not a scientific study), organizations that try to apply Scrum beyond new product development find that it is a much weaker tool. They always get modest results. Organizations that apply Scrum to new product development might also get modest results, but sometimes they get truly amazing results. It is this potential for amazing results that seems to only exist in new product development that I hope we can strive for.

      Is Scrum a proper name (or a brand)? Or is it just a concept? Personally, I would like Scrum to remain a definite thing that has a great deal of strength to transform specific situations, rather than it becoming weakened through too much flexibility.

  4. Is scrum so tough that I can not add any”overhead” ??
    Cannot I enbody prince2 processes or pmbok technics to improve or reach any goals ?
    Is it to change , improve or adapt scrum?

    1. Hi Bruno,

      I think you are welcome to do anything you want with Scrum! You can add to it, remove things from it, change the names of bits of it… anything! There are no “Scrum police” 🙂

      That said, when you make changes to Scrum, you are doing so at your own risk. This is why so many organizations get modest qualitative results when they use Scrum. On the other hand, organizations that use Scrum properly get extremely good results which means teams that quadruple their productivity, dramatically reduce defect rates, and have customers and users who are delighted by the results of the team’s work.

      It is easy to compromise. It is hard to do Scrum properly. Often we compromise because we think it won’t be a big deal… but we often miss the incredible benefits because we aren’t willing to do the hard work of changing our organization.

  5. False argument, wrong goal.

    A hammer has irreducible complexity, removing one of it’s parts doesn’t just reduce it’s effectiveness it eliminates it’s form. A better analog would be trying different handles and different heads, or two heads, or different grips, or no grip, or a longer handle etc.

    Scrum is an empirical process control framework, changing out time boxed iterations and replacing it with a theory of constraints does not change what it is, only how one of it’s goals is reached and which is more effective should be the only test.

    Removing inspection and adaption events (of any type) on the other hand would be eliminating a basic requirement of Agile and probably would reduce it’s effectiveness to the point where it might fail.

    If your goal is keep scrum “pure” then you are nothing but a dogmatic follower of a movement, the real goal should be to improve upon the framework to achieve better results regardless of whether or not it is “pure” form of scrum.

    Everything should be open to validation and improvement, Ken is protecting his domain be refusing to engage in debate and honest analysis.

    1. Hi Tim,

      I’ve been busy with a move so I haven’t gotten to the comments here for quite a while. I’m not sure if you are still paying attention to this post, but I’ll reply anyway.

      My overall response to your comment is this: I’m not a Scrum fanatic or fundamentalist, or a “dogmatic follower of a movement”. Why do I say this? Because of the following facts:
      1. I don’t always (or even often) recommend Scrum to my consulting clients. (I recommend any number of Agile methods, most often from among the list of OpenAgile, Kanban, Scrum, Extreme Programming and Crystal Clear.)
      2. I don’t always follow Scrum “by-the-book” when I do use it with clients. (Sometimes an organization needs to start with a Scrum-like process that is “easier” to use and then move up to full Scrum even though this temporarily hides some of their impediments.)

      That said, as a Certified Scrum Trainer (with the ScrumAlliance) and as a student of Ken’s, I like to think that I have a clue about Scrum.

      Keeping Scrum “pure” doesn’t mean that Scrum does not evolve. It just means that at this point in time, we have a clear definition of what is Scrum and what is not Scrum. For example, in the “black book” by Ken and Mike, there is a behavior that is no longer considered part of Scrum: the developers do a detailed breakdown and estimation of tasks and sign up for all of them during Sprint Planning. This behavior might still happen in Scrum teams, but the specifics of the detailed breakdown to tasks, estimating them and signing up for all of them are now just considered one way to do Scrum. Another way is for the team members to do the breakdown but instead of estimating them, just start working on them one at a time throughout the Sprint. This is also acceptable behavior (now) in a Scrum team.

      Scrum is open to improvement, but Ken also has defined a very clear boundary as to what is and is-not Scrum. This is good because it is like any other brand protection: you know that if you don’t use Scrum (properly) your results may vary significantly from what Scrum might enable. And by the way, I don’t mean that your results will be poorer. In some cases, not doing Scrum by the book may be exactly the right thing to do. Just please, don’t call it Scrum.

Leave a Reply

Your email address will not be published. Required fields are marked *