Hoot Hoot Hoot!

Right in the center

Posts Tagged ‘software quality’

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.

Read the rest of this entry »

Advertisements

Posted in technology | Tagged: , , , , , , | 10 Comments »