When Scrum is too Much

Scrum was designed as a lightweight process framework for software development, with the intent to impose a minimal amount of overhead and structure. So it is interesting to consider cases when Scrum is itself too “heavyweight” for a project, and something lighter is more appropriate.

The “Sweet Spot” for Scrum

Scrum is optimized for projects that have high uncertainty (due to the inability to estimate effort accurately), a high likelihood of frequent changes of direction (due to rapidly-changing requirements), and the need to respond quickly to customer requests. For these reasons, it mandates short development cycles of uniform length, to minimize risk and maximize responsiveness to rapidly-changing customer needs. The emphasis on short cycles enables a predictable schedule of releases, each of which is the result of one or more development cycles.

The “Sour Spot” for Scrum

Let’s think about some examples of projects for which Scrum is not particularly useful.

I don’t use Scrum to make a cheese sandwich. I use a waterfall process, following a template devised long ago: I get out two pieces of bread, slice enough cheese for the filling, and assemble the sandwich.

I also don’t use Scrum to build a set piece for a play. Instead, I collaborate with as many other volunteers as we can reasonably use, and work on the piece until we have to quit for the day, or until it is done. After one or more work sessions, we finish the piece and move on to the next. This process is neither Scrum nor waterfall in nature, but bears more of a (rather vague) resemblance to Kanban.

So what do these examples tell us? Basically, they say that Scrum is much less useful when the work is thoroughly understood in advance, or when the delivery date is not specified, and not cyclic.

A Real-World Example: LifeHints

I’ve been helping out some friends at LifeHints over the last year, working with them to set up development guidelines. My first thought, of course, was that the LifeHints folks should use a Scrum process, but I soon changed my mind.

Why not use Scrum? Well, before their first release, they had no established customers, and so no customer requests, for features or release schedules. Thus the cyclic nature of Scrum provided no particular benefits, and responsiveness to customers was not an issue.

What was in issue was the need to build a system incrementally, starting with the simplest scenario (logging in and showing a home page), and adding functionality bit by bit over time until the application had enough to be useful. This process definitely required agility, as the requirements evolved in unpredictable ways over time. It also required daily, or near-daily, builds that worked, so that everyone could see how the new features were shaking out.

In a nutshell, the LifeHints team, which contained both Product Owner and Team member roles, worked in short but variable-length iterations, refining requirements and refactoring code as needed, until the evolving vision and the evolving product converged to a useful reality.

This process was very effective, and I suspect it occurs frequently in pre-release startup companies. I also suspect that, as the company and its customer-base grow, something more formal will eventually be required, and Scrum will become an attractive option.

Conclusions

Everyone knows the saying, “When your only tool is a hammer, every problem looks like a nail.” Scrum is a tool in the toolbox of project management, and, like any tool, is better-suited for some situations than others. For the people at LifeHints, Scrum was too structured and prescriptive for the company’s stage of development. Given the focus on Scrum as a lightweight framework, I find the irony gently amusing.

(For the curious: LifeHints provides guidance on what things you need to do to live a life that reflects your personal preferences. You can check it out at www.lifehints.com.)

Advertisements
Explore posts in the same categories: Uncategorized

8 Comments on “When Scrum is too Much”

  1. Peter DeYoe Says:

    Hello,

    Forgive me but I am not sure I understand. You said:

    “What was in issue was the need to build a system incrementally, starting with the simplest scenario (logging in and showing a home page), and adding functionality bit by bit over time until the application had enough to be useful. This process definitely required agility, as the requirements evolved in unpredictable ways over time. It also required daily, or near-daily, builds that worked, so that everyone could see how the new features were shaking out.

    In a nutshell, the LifeHints team, which contained both Product Owner and Team member roles, worked in short but variable-length iterations, refining requirements and refactoring code as needed, until the evolving vision and the evolving product converged to a useful reality.”

    What part of that discussion is not characteristic of Scrum? It sounds to me like they are very much a fit for scrum. I do agree with you when you say that “Scrum is much less useful when the work is thoroughly understood in advance” I have experienced this myself. When we were asked to rewrite an existing system and Scrum was used…not a good fit.

    But please help me understand how your real world example was not a fit for scrum?

    Thanks,

    Peter DeYoe
    http://www.peterdeyoe.wordpress.com

    • AskelKana Says:

      The making of a cheese sandwich is not a good example, as you’re talking then about production as opposed to development. Projects are about implementing change, not churning out product. So, Scrum is excellent when you have an array of sandwich fillings to choose from (assuming untasted), and you don’t want to commit to making a whole sandwich before sampling many fillings.

      1. Take a morsel of bread
      2. Apply the filling
      3. Taste
      4. Repeat until:
      – enough fillings tried and decision can be made
      – run out of bread
      – full from eating all those morsels, so who needs the sandwich?

      • Kevin Thompson Says:

        “Projects are about implementing change?” I’ve never seen that definition of a project before! In any event, Scrum is not a project, but a process, and I described a non-Scrum process for making a cheese sandwich.

        I enjoyed your sandwich example (which almost sent me off to the kitchen to experiment), but I don’t think it really matches a Scrum process, as described. An agile one, perhaps, but not Scrum, which has a more specific structure.

        Now I’m going to have lunch… Thank you for writing.

  2. Kevin Thompson Says:

    Peter,

    I’m not saying that the project could not have been conducted according to Scrum, because it could have. However, there are certain features of Scrum that did not provide enough value to the team in these circumstances such that their adoption was clearly beneficial. Chief among these were fixed-length development cycles, and associated ceremonies (sprint planning meeting, retrospective) with the usual formal structure as practiced in Scrum.

    So I would characterize the process as agile, and it resembled Scrum with respect to iteration, re-factoring, and changes in direction, but it did not fit the Scrum framework as such.


    • Hi Kevin interesting post. The bottom line is that as long as your process fulfilled your goals then it’s a win. I am curious and have a few questions.

      You mention that you didn’t have sprint planning meetings. How did you handle the planning of what features would be developed when, and then how those features would be built out?

      You also mention that you didn’t hold retrospectives. Did you hold to the exact same process throughout the building of the app or did you modify as necessary?

      Thanks for your time and response.

      • Kevin Thompson Says:

        Robert – Frequent discussions, held on demand between the developers and informal product owner, provided all the planning that was needed.

        Since the work was relatively unstructured, I’m not sure the process qualified as something that could be exactly the same throughout, so I’d have to say it was modified as necessary.

        I don’t hold this example up as a model for software development in general, but for a small team, working on a new product that had not yet been released to the public, it worked well enough.

  3. Roy Crisman Says:

    Whoa, you have a website that has no “customers”? I don’t think SCRUM has ever defined “customer” to mean only an external customer. In the case of a web startup, the customer is the person/people with a vision of the product, ideally funnelled through a Product Owner. The way you are using “customer” feels almost as if you’d then expect the real customers to take over the role of the people with product vision in this case…..or maybe you’re just used to projects that are a software delivery for an external client?

    Ah….at least some of this is due to the “evolving vision”. It wasn’t that there was no “customer” or Product Owner to represent the needs of the system, it’s just that the vision was changing very frequently. As long as the Team isn’t finding this aggravating, they may not need the protection of SCRUM to get the visionaries to figure out what they really want ‘for now’.


  4. […] I found this blog post about Scrum on LinkedIn:  When Scrum is too Much « Deep Scrum. […]


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


%d bloggers like this: