Experimenting With Scrum Part 2

t 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.

http://blogs.msdn.com/b/steverowe/archive/2006/01/03/experimenting-with-scrum-part-2.aspx