Hoot Hoot Hoot!

Right in the center

Archive for the ‘technology’ Category

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 »

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

It’s A Marathon, Not A Sprint

Posted by kostub on August 31, 2010

There is no single development, in either technology or management technique,
which by itself promises even one order-of-magnitude improvement within a decade
in productivity, in reliability, in simplicity.
– Fred Brooks, Jr

In the past few years, I’ve worked at various companies which used Sprints to plan their work. Agile methodologies, such as Scrum, have become the latest fads in software development. Every company I’ve interacted with touts how they switched to the Agile software development processes and it is the most frequently cited silver bullet for many establishments. There are many processes that the agile methodology advocates, but the one that is being adopted most rapidly is Scrum. You can find innumerable books, websites and blogs that will extol the benefits of Scrum, but any criticism of the process is really hard to find.

Scrum has many advantages similar to those of other iterative or rapid development processes. But due to the high popularity and the heavy marketing of Scrum as a panacea, very few people realize the potential drawbacks they could encounter. This post describes the various issues that I have observed in the companies that I worked at. I will not go into the details of how Scrum works, you can find many great resources on scrum websites. However, my favorite of post on agile is Steve Yegge’s sarcastic post on Good Agile, Bad Agile.

So what are the drawbacks of Scrum? The two symptoms I’ve seen commonly are:

  1. Sub-optimal execution
  2. Lack of solid software

Sub-optimal execution is any activity that results in rework or unnecessary wasted effort.  In this post I’ll concentrate on the this issue.  A follow-up blog post will delve into details of why Sprints may lead to poorer quality software. Let us look into some of the aspects of Scrum that could lead to sub-optimal execution: Read the rest of this entry »

Posted in technology | Tagged: , , , , , , | 1 Comment »