NOT Doing Scrum – Back to the Basics

[Guest Post: Don Gray is an Agile Coach whom I have had the pleasure of working with on one of my biggest clients. There is too much to say about him. He kicks ass. You can find him blogging on his website and follow him on twitter @donaldegray] – He also purposely tries to confuse me and challenge me at any given moment.

I recently talked with a company who wanted to use Scrum for their production support team. The team had 670 defects ordered in business priority and needed to work from the top down. Corrected defects would be deployed to production once a month, except quarterly when then deployment would synchronize with new development’s deployment. No planning meetings needed and no demo prior to deployment.

About a week ago the following question was asked on the scrumdevelopment listserve:

“Sometimes, I feel ScrumMaster role is redundant. Is it possible to have Scrum without ScrumMaster?”

Once from the top with feeling

I did not define Scrum. Those who did (Ken Schwaber and Jeff Sutherlund) created a simple process framework and minimal interacting roles.

The process has these ceremonies, or meetings if you prefer:

  • Sprint planning – happens at the beginning a sprint. Sprint means a time period (usually between 2 – 4 weeks and shorter is better in my experience) where the team produces the value they agreed they would. Sprint planning often divides into two meetings: first the team estimates the amount of work they can accomplish, then they task the work and have a sanity check.
  • Daily standup – occurs every day at the same time. The team members share their progress since the last standup and report any blocking issues.
  • Sprint demo – where the team demonstrates to the product owner the value they completed in the sprint. The product owner has final say on accepting the work products, or not.
  • A retrospective where the team inspects the previous sprint and selects an improvement goal for the next sprint.

Interacting roles:

If it looks like a duck …

If you’re not following this process, and don’t have these roles in place, please don’t say “We’re doing Scrum.” You’re not. You may be following the agile principles,, and that’s great. But you’re not doing Scrum.

19 Replies to “NOT Doing Scrum – Back to the Basics”

  1. It’s not uncommon to discover, while interviewing members of failed “Scrum” implementations, that none stuck to the basic framework (processes and roles). The modifications have included, “we added this process and we took away that role.”

    When you have a ScrumMaster who is estimating and assigning work to a team, it’s not Scrum. If you don’t have cross-functional teams, you’re not doing Scrum.

    If you fail, don’t blame Scrum.

    1. Oh right, when Scrum fails, it’s always because someone didn’t do it right.

      But when Waterfall fails, it’s because the entire method is broken, right?

      Maybe people just don’t know how to do waterfall properly.

      Scrum is a medieval, even prehistoric method of management — that is nothing to get excited about.

      The fact is companies that have a pretty well defined project with fixed deliverables would be better off with a more traditional approach, but the agile industry rarely tells them the truth about such matters.


  2. Jordan, I did not say if Waterfall fails, the entire method is broken. What I am saying is regardless of your process, you need to have skill and discipline. If you intend to label and follow an approach that is to conform with a set of practices and processes, and you do not follow them, don’t blame the practices or the processes. If you are going to do waterfall, be disciplined! If you are going to do Scrum or other Agile method, be disciplined!

    So, I would have to disagree with you.
    When Scrum fails, you need to discover the root cause and not blame Scrum.
    When Waterfall fails, you need to discover the root cause and not blame the entire method.

    1. Fair enough, but I don’t believe that it is important to follow “all” of either method.

      People have been successful adapting and modifying waterfall, and they should be successful adapting and modifying Scrum.

      You do seem to be blaming people for not doing Scrum “properly”.

      My take is:

      1) What is the definition of proper? Just because Ken and company says doesn’t make it so

      2) Let’s say, for the sake of discussion, that Scrum fails at the same rate regardless of it it’s done “strictly/properly”.

      Let’s also say most shops are not “doing it by the book”. Then, most of the failures will be shops not doing it by the book — just because that is most of the population! Correlation != Causation

      This is no different from the fact that most shark bite victims are wearing black wetsuits; it could be that sharks target black wetsuit wearers, but it could also be color is not important to sharks, but since the vast majority of wetsuits are black, then the vast majority of attacks are on people with black wetsuits.

      Finally, even if it WERE true, that people modifying Scrum or not adopting it fully, led to it’s failure (which I don’t agree with) that is yet more evidence that Scrum is “too fragile”.

      If a stove makes dinner for 25% of the people, and blows up the house of 75% of the people, you cannot merely blame the users of the stove. The stove is either too incompletely designed, or customers are being sold stoves when they should not be.

      Ultimately no matter what side of the argument you take, it’s lacking in reasonableness — Scrum can not be the ultimate methodology and fail most of the time … which it does.


      1. Jordon, I agree with you that you do not necessarily need to follow “all” of either method. I think regardless of the approach, if the people leveraging it don’t understand WHY they are doing what they are doing, they have a problem. To blindly follow a set of practices without knowing why you do them is foolish and reckless. Granted, sometimes you have to play the hand you are dealt. I do believe people should understand available approaches and recognize the risks and benefits. From there, they need to accept or mitigate the risks of the chosen approach.

        Like you said, there may be correlations but I don’t think any method is the cause for a project to fail OR SUCCEED. I would say human actions leave us with wildly subjective reasons for blaming or praising a set of practices or processes.

        I hope I clarified that I’m not saying the individual refining the usage of Scrum practices is the cause for the failure of a project. But I also hope that person takes pause before they vilify Scrum if the project fails. They would have probably failed, regardless of the approach.

        I appreciate you making the points that you have. I think the conversation is worth having.


        1. It’s possible that the project would have failed with either approach, but in my experience, it is the most broken shops that adopt scrum.

          True, they may have unrealistic expectations, true, they may have poor engineers, true, they may not know what they are doing.

          But these are the people I see adopting Scrum. I don’t see the talented organizations adopting it, and my colleague reports, for instance, that there is no sign of Scrum at google.

          I see Scrum as simplistic and somewhat problematic in itself.

          But I see it as more of a symptom, of poor management, flailing at solutions and going with whatever is the most popular and whichever salesman promised them the most.

          So, to me, when a possible project says they are doing Scrum, that to me is a huge red flag, just like if they said they are a startup or they are offshoring.

          I would rather see them create and own their own processes, and demonstrate knowledge and control than slavishly adhere to one and demonstrate that they are unable or unwilling to take charge of their process.

          If they are going to slavishly adhere to one, I’d rather see them slavishly adhere to traditional processes than nontraditional ones.


          1. Jordan, I both agree with and disagree with your comments.

            I agree projects fail for more reasons than misapplied Scrum or traditional processes. This indicates more ways exist to fail than to succeed.

            I think we should look to the context to determine what development method to use. I don’t suggest Scrum to every client.

            I don’t agree that Scrum is simplistic and medieval. As I mention in “A Multi-use Model” Scrum’s foundation consists of cascaded feedback loops. This allows daily decision making to make sure the team meets its sprint goal and decisions at the sprint boundary to make sure the project stays on track. Used properly this provides superior information and decision making ability.

            And I still say, if you’re [the generic you’re, not specific to Jordan] not following Scrum as defined by Ken Schwaber and Jeff Sutherland, don’t say you’re doing Scrum. You’re not.

  3. Independently I also ran into the “who’s to blame (process or people)” question. I think that formulation points to the real problem. Namely that the activity is affixing blame. Which I hope we can all agree isn’t productive.

    When things don’t turn out as we’d hoped, if we didn’t follow process X then I don’t think it’s intellectually honest to say process X is bad. I think a better formulation would be “Our adaptation of process X did not have the desired outcome.” Unfortunately that won’t get you nearly as much attention.

    On the other hand, it is equally unreasonable to say that process X will always succeed if done properly. I see that as an information free tautology.

    I do think it will pay dividends if we can all get more nuanced in our conversations about process and activities. These are not states or badges, that can be straightforwardly attained and then held without thought. They are organic things, like our own learning, that much be constantly monitored and supported.

    On an even smaller scale, take retrospectives. Lots of people do them. I’m betting there’s a very wide range is how they are carried out and how effective they are. People will say that they are doing retrospectives. But that claim is now almost information free as a label. Precisely because it is used to name so many different things.

    More story, less slogans.


    1. Yes, well, I agree with those points — in fact I had coined what I called a “jordanism” to encompass that — “Sloganeering”

      IMHO what is important is to have, for instance GOOD communication. It doesn’t matter if that communication is written, skype, email or whatever.

      Scrumists believe that “ad hoc” “collocated” is “best” — they talk about the how’s, and they do it in a way that could easily work and probably did in fact work in midieval or even prehistoric times…

      Get everyone in the cave, put some drawings on the wall, talk about the issue and get to work…

      So I think there are some things about it that make it more failure prone — but I also think there are some things about it that make it right for certain organizations.

      I think we should move beyond talking about the HOW’s at all — and talk about the WHAT’s — good communication, customer involvement, shorter cycles etc.

      Scrum and it’s devotees focus too much on the HOW’s — how to fold your shirts, how to track your project, how to communicate everything verbally.

      It’s like a Martha Stewart kind of thing — you’re not cool if you don’t fold your shirts like Martha Stewart does (she has a really high tech method she demo’d once on Conan O’Brien — I’m sure you can find it on youtube).

      It doesn’t matter how people fold their shirts — it only matters that they got folded, so let’s move beyond the whole methodology distraction entirely is my thinking.


  4. You’re entitled to your opinion, you certainly can have that Don.

    But then by the same token, people should stop saying User Stories are part of Scrum. They are not part of the Scrum Guide 2011.

    People should stop saying Burndown charts are part of Scrum. They are not.

    People should stop saying TDD is part of Scrum — it isn’t.

    People should stop saying waterfall always fails, or that waterfall require ALL design up front before any coding is done — it doesn’t, and even the Royce paper says it doesn’t.

    Heck, even the papers by Xebian, and even Sutherlands 100% money back deal that he offers now, uses (or requiers) uses of patterns beyond scrum to succeed.

    If they require additional processes beyond Scrum to work, they should stop saying “Scrum” works.

    It goes far beyond the single issue you are brining up IMHO


    1. Jordon,

      I agree the activities and artifacts you mention are not part of Scrum.

      > If they require additional processes beyond Scrum to work, they should stop saying “Scrum” works.

      To me Scrum is a lightweight product development process. It gets used in other domains besides developing software products. As such, each domain should add the necessary construction (TDD, burndown charts, user stories, big visible charts, whatever) activities.

      If I go meta one logical level, our conversation seems to coalesce to “know what you’re doing and how to name it so others can correlate it to other experiences.


      1. Possibly; if I went meta one level I’d say the industry should stop discussing Scrum entirely.

        It’s as I’ve pointed out, not just simple, but simplistic. Calling it a framework to paper over it’s simplisticness is not sufficient.

        We can get beyond the whole conversation of “is it Scrum or not” by not even having Scrum as part of the equation.

        That is the best overall solution IMHO. Don’t do Scrum, and therefore don’t worry about what it is called.

        Do what you think makes sense, not build upon a shaky foundation.


  5. Pingback: NOT Doing Scrum – Back to the Basics | Agile | Syngu

Leave a Reply