Disruptive versus iterative change

Scrum is a rather interesting phenomena. As a process, the feedback system it incorporates encourages incremental and iterative improvements not only in the software, but the process itself. Once scrum is in place, things can go rather smoothly, although I do find pull-based processes to be smoother and less disjointed.

But getting scrum in place is an extremely disruptive change. And usually, at least one business group has to be dragged kicking and screaming into the process. Or, scrum is instead installed in one tiny part of the entire production pipeline (development), with the entire process still being one very long (6-12 month) iteration.

I find it more than a little ironic that although the process itself is incremental and iterative, installing scrum in the first place is a big, disruptive change.

In our projects, we’re very often these days confronted with replacing existing solutions with new ones. In these situations, we keep a very close eye on risk, and our initial goal is to get something into actual production use as quickly as possible. Replacing the entire existing system at once is a highly risky affair, and one we try to avoid like the plague.

An iterative improvement approach

An alternate approach would be to instead just take whatever process you have right now, however ill or well-defined, and just start improving that.

One team I talked to said they did 2 week iterations. But in terms of “done”, the end of a sprint didn’t mean a production release. As we mapped more and more steps out, the entire process was more like:

  • Requirements definition (4-6 weeks)
  • Analysis (4-6 weeks)
  • Development (8 weeks)
  • Testing (2 weeks)
  • UAT (2 weeks)
  • Release (~ 1 day)

The development phase was the actual scrum part, so basically 4 two-week sprints occurred there. Handoffs from development to testing to UAT were instantaneous. Release only occurs when the entire UAT phase is done, however. In the initial scrum implementation, it might look like our iteration length is 2 weeks.

If we add up the numbers, actual iteration length from definition to production ranges from 20 to 24 weeks! A far cry from the 2 week sprint that we first assumed we were working under.

One issue we saw were large handoffs, that all of requirements definition had to be done before analysis started. In order to speed the process up, the first suggestion was to simply reduce the size of the work going through the process. The entire 20-24 week process worked off a single (large) document. Reducing the size of that to something manageable would reduce the amount of time development needed to wait before starting work.

This is just an example, but in our case we started with an existing process instead of throwing the whole machine into a lurch with a forced process. Risk-wise, it’s much easier just to map out what’s actually going on and improve that, rather than development trying to impose a process on other business groups.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • jdn

    You’ve nicely hightlighted a couple of reasons why I (naively perhaps) prefer a Kanban approach over launching with Scrum:

    - Kanban basic principles state: “Start with what you have.”  No one’s roles or responsibilities change up front, whereas with Scrum, you start with (potentially) new roles, which can lead to the ‘kicking and screaming’ of which you speak.  Especially in today’s economy, the idea that a new process introduces from the start new roles is easy for individuals to interpret as “This new process is going to end my job.”

    - your description of the entire process looks like a pretty good textual description of a value stream mapping for an organization.  As such, it plays a role in showing why so many ‘developer-oriented’ changes are local optimizations.  “Look at how much faster I can write code when I use Resharper.”  That’s nice, but if the bottlenecks in your process are either up or down stream from the development process, you aren’t really addressing what’s most important.

    Nice post, thanks.

  • I just like the approach you took with this subject. It isn’t every day that you discover something so concise and enlightening.