Hoot Hoot Hoot!

Right in the center

Does Scrum Leave Holes In Your Software

Posted by kostub on October 21, 2010

Quality far beyond that required by the end-user is a means to higher productivity.
– Tom DeMarco, Peopleware

In the previous post, I outlined some of the drawbacks of Scrum as a software process. One of the reasons that I mentioned, but did not elaborate on was that Sprints result in a lack of solid software. In this blog post I’ll discuss that issue in more detail.  Awareness of these issues which can and do occur in Scrum makes it possible to come up with effective solutions to combat them.

In my opinion, the primary reasons why software quality suffers in Scrum are as follows:

1. Lack of proper design
2. Artificial deadlines
3. Community ownership

Lets start with how software design is handled under Scrum. The design task is one of the hardest to plan for within a Sprint. In fact, Scrum assumes that the design should be completed before a project is even planned. This works only in teams where someone else provides a functional or technical document describing what needs to be done. At every place where I have worked, that has never been the case. The process of designing software is highly asynchronous, involves lots of external dependencies and is difficult to estimate. When using Scrum, people typically follow one of two approaches – including design as a separate story in an earlier sprint, or bundling design and implementation in the same sprint. The first approach works better in practice, but is harder to coordinate. This is especially true when Sprints are longer than 2 weeks, as it creates an unnecessary artificial gap between the design and the implementation. The implementation cannot be scheduled until the next Sprint and sometimes may have to be de-prioritized until the following Sprint or sometimes even later.

The second approach to design, viz. bundling design and implementation as one story, is more natural to execute but is more problematic. The pressure to finish both design and implementation by the Sprint deadline provides little incentive for the developers to complete the design properly by engaging all the stakeholders. For example, after two of our projects were delivered our stakeholders indicated that this was not usable for their purposes, resulting in both the projects getting no usage. The reason for failure was that the customers were just not asked for input during the design phase. The team had two choices either finishing off the implementation with a design with limited external input, or waiting for input on the design but be idle during that phase as nothing else was scheduled for the Sprint. The team obviously chose the former approach. This example is a bit extreme, but even for simpler tasks I have seen that people tend to jump into implementation sooner than they should have, if both the design and implementation are scheduled in the same Sprint.

The next issue is that of constant artificial deadlines. Recall that Sprints are planned 1-4 weeks at a time. At the end of a Sprint, the team is expected to complete everything that they planned on. This is almost never the case since either the plans are too optimistic or the team gets waylaid by other problems. When faced with too many deadlines, developers tend to take shortcuts. This primarily manifests itself as missing or inadequate unit testing. But sometimes it also means that a developer will skip a better solution for a hack just because it would have taken them a few more days to implement the better solution resulting in them missing the deadline. That leaves unnecessary broken windows in the code and repeated deadlines leave the code in an extremely vulnerable state. In one of the teams, we had to completely throw away a code base built over a couple of years as it was damaged beyond repair. Constant use of hacks and lack of testing made the code was impossible to modify without causing any regressions. Even after the team spent 6 months fixing bugs it could make little headway. We rebuilt the code base in six months after we dropped Scrum and concentrated on building a solid product instead. While code rot is a common phenomenon in many projects, it seems to be exacerbated when using Scrum.

The last issue is that of community ownership.  In Scrum, the entire team owns the software and not an individual. While this ensures that tribal knowledge is spread around, it also means lack of individual responsibility and accountability. I firmly believe that developers should have complete ownership of the software they write. That means if they release software with bugs, they are responsible for the support and fixing the bugs or to put it in simpler terms – “Everyone must clean up their own shit.”  Lack of individual ownership causes people to throw poor code over the wall to others. There is no one clear individual who is the goto person for a particular functional area of a piece of code. Rather everyone makes patches everywhere. This was another reason our code base was unmaintainable in the aforementioned team. Sprint planning allowed for any developer to pick up any task, and rather than steering a task to the best person to make the change. This made it a predominant practice to have one developer fix bugs left by another instead of having that person go back and assume responsibility for that code.

As with the drawbacks mentioned in the earlier post, none of these issues are insurmountable or even endemic to Scrum. The important thing is to realize that these are genuine problems that can become significant issues if not addressed soon enough. Once you are aware of the potential drawbacks, it makes it a lot easier to avoid them. In a future post, I’ll outline some guidelines to avoid these pitfalls within the context of Scrum.


10 Responses to “Does Scrum Leave Holes In Your Software”

  1. Jamie said

    Corey Haines just tweeted this:

    “coreyhaines Corey Haines
    🙂 RT @dchelimsky: Just because you have no clue how to use mocks doesn’t make them bad”

    It’s the same with Scrum… you need to do your homework because you misrepresent it here.


    • kostub said

      Just like Scrum you can create quite a mess with mocks to. But the problems with mocks and how to use them are well understood.

      Scrum is very heavily advertised and you will not see any criticism of the process anywhere. The benefits of Scrum are explained in everywhere, but no one talks about the flip side. This is what I have attempted to do with this blog. People who intend to try Scrum need to be aware of potential issues they will likely run into, so that they can improve their processes.


  2. Cindy said

    I thought I was the only one that could see the issues associated with Scrum. Thanks for posting this.

  3. Jamie said


    Cindy, these problems have nothing to do with Scrum. There’s something else going on in your project… don’t give Scrum too much power. Don’t use it as a scapegoat.

    • Cindy said

      None of my projects use Scrum. I have read about it. I have had people who use it explain it to me. And the issues described in this article were the issues I thought would be the case.

      It sounds like the Spiral methodology on speed but without a road map to ensure that your building blocks fit with each other. Would you build a house without a blueprint? No.

      With well defined requirements at the spec level, versus “bring me a rock” level, and a design (assuming there is an interface), scrum/agile sounds like an interesting way to do rapid development. But requirements and design seem to be washed over when scrum is described. That concerns me.

  4. Kostub/Cindy,

    Please don’t take this the wrong way, but you both have a very naive view of Scrum.

    Scrum is a framework, not a full fledged process. Scrum encourages you to innovate, inspect, and adapt within the framework. The problems you describe are generally a result of your adaptations within the framework, not with the Scrum framework itself.

    Scrum is fairly simple to understand, but is very hard to master(much like Mocks, btw). For instance, Scrum does not prescribe a requirements process, it encourages you to pick one you think best for your team. What Scrum does do is it creates an environment where your chosen requirements process is transparent(aka visibility), allowing you to inspect and adapt it to make it better each Sprint. You still need well defined requirements to do Scrum well.

    I encourage you both to take the Scrum Open online assessment to see where your understanding of Scrum is. Here is the link:

    • Cindy said

      thanks for the link Charles. Like I said before, I have not used Scrum. I only know what I read and hear. I just looked at the guide in the link. It isn’t until page 16 that requirements are mentioned and my concerns about this framework are confirmed. It says requirements make up the backlog. That is good. But it also says “The product backlog is never complete.” Then it says “the product backlog represents everything necessary to develop and launch a successful product.” So if it is never complete, how can it contain all that is necessary. How would someone interpret this? Later is says “To minimize rework, only the highest priority items need to be detailed out.” Unfortunately, sometimes it is the low priority items that holds a crucial requirement that can affect the high priority items. Then what happens? When I read this section of the guide, I saw opportunities for inconsistent implementation of the framework. That might not be the intent but no one comes to a development methodology without their own experiences (or lack there of). It seems the framework makes assumptions that people using it have the prerequisite skills to use it successfully.

      I think the framework described in this official guide leaves room for interpretation and that interpretation is what causes problems. But every development methodology has its pros and cons. If there are interpretations/assumptions to be made in a framework, I think the framework might be vulnerable to being misunderstood.

      So when I am told about scrum, I am getting different the interpretations. But for the most part, it is the requirement details that are being overlooked. From my experience, details can get you into trouble if they aren’t included. Hence, why I am not surprised by the observations in this post.

  5. Ignore this post. Subscribing to notifications.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: