Share via


Experimenting With Scrum Part 2

   It occurs to me that some of those reading this blog will not be familiar with Scrum.  Before I go into any details about what did and didn't work about my experiments, I'll take some time to give a quick overview of the process.  For more information, check out the book or Ken Schwaber's web page.

   In a nutshell, scrum is a workflow methodology for developing software.  It is most often associated with practices such as eXtreme Programming but could really be used with any set of programming proactices.  The basic premise is that work cannot be scheduled far in advance.  Instead, it must be handled in discrete chunks and corrections to the course made regularly.  The tools for this are threefold:  the product backlog, the sprint, and the scrum meeting.

The list of potential features for a product is kept in ranked order in what is called a "product backlog."  This list could contain new features, modifications to features, bug lists, etc.  Everything that needs to be done goes on thsi list. 

Next is the sprint.  This is a defined period of time (the authors suggest 30 days) for work to be done.  During this time, no course corrections will be made.  If there is a new feature to be added, it will be handled in the next sprint.  At the end of a sprint, the features set aside for it should be complete and shippable.  The idea is that the product is ready at the end of each sprint.  By "ready" it is meant, the features are complete, not that every feature is there.  It might not be ready for cursotmer deployment yet.  There will not, however, be partially-implemented features and things checked in that don't work.

Finally there are the scrum meetings.  These are daily meetings of the team.  They should be short.  Each person in the room should basically give a quick status.  "Here is what I did in the last 24 hours.  Here is what I am doing in the next 24 hours.  Here are the items that are blocking me."  The purpose of this meeting is to provide visibility into the progress toward the sprint.  At this meeting, work items may be reassigned to others but new items are not added.

The idea behind Scrum is that software development is not like manufacturing.  It is more like original research.  We don't know how long something will take.  We don't know what roadblocks will be put in our way.  We don't even really know what the end product needs to look like because requirements change so often.  The response to this, rather than hiring 14 people just to maintain your Gantt charts, is to do away with them.  If the environment is always changing, the best response is not to plan better up front but rather to learn to react to those changes.  Scrum is one methodology to do this.

As a test development team working on disparate projects, this model doesn't fit perfectly.  I started with just the scrum meetings.  How that went will be described in my next posts on this subject.

Part 1

Part 3

Comments

  • Anonymous
    January 03, 2006
    I had my first experience with Scrum a little bit ago as an MCS consultant with a large customer. As you mention, software development is "like original research". This was especially true in this case since my job was to help them with their migration from an AS2K to SSAS.

    Anyway, the folks from this customer told me they were on their third sprint and the next one started immediately afterwards. They seemed like they were becoming quite ragged.

    I had been very interested in Scrum and found the ability to easily have a project evolve by taking it in complete 30-day chunks very appealling.

    However, I think their should be at least a week between sprints to let everyone catch their breath. I'm not talking about a week off, but a week to take care of everything so I can focus during the sprint. I found I was so focused on the deadline that everything else in my life took a back seat. That's OK during crunch time, but I have this feeling serial sprints make things always crunch time.

  • Anonymous
    March 12, 2007
    Our first attempt at using scrum came during what we call a bug smash. That is a time when we focus solely

  • Anonymous
    November 08, 2007
    PingBack from http://blogs.msdn.com/steverowe/archive/2005/12/30/experimenting-with-scrum.aspx