Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Scrumming for the first time

We finished our second sprint today.  In fact, I just left the Sprint Retrospective Meeting (which was actually quite brief).

We've been very lucky to have a client that insisted on using Scrum to manage the project.  Before this I only had a cursory knowledge of Scrum. We are a small shop, and while we've been influenced significantly by Extreme Programming (XP), we haven't had the mass to implement all the practices we'd like.

What is Scrum?

I discovered quickly that I had a misconception about Scrum.  I had assumed that it was just a different flavor of the same thing as XP. But there's a difference of scale, Scrum is about managing a project, or multiple projects.  Within Scrum you might have multiple teams, and each of those teams is responsible for Self Organizing.  XP is one way for a team to self-organize.  In this way, XP fits nicely inside of Scrum. 

I began reading Ken Schwaber's book just before this project started.  I highly recommend it.  It is a set of case studies discussing how Scrum works, and it comes across as honest and realistic.

The significant parts of Scrum, as adapted from Ken's book, are:

  • Scrum Master - The individual responsible for managing the Scrum process.  The Scrum Master's job is to facilitate the project. On our current project, this role is filled by our client's IT Director.
  • Product Owner - The representative of the stakeholders.  An individual responsible for making the final decisions about what needs to get done.  On our current project, this role is filled by an employee who was a Power User of the legacy system we are replacing.
  • The Team - The people responsible for doing the work.  In this case, it's my company.
  • Sprint - Typically, a sprint is a 30 day span of time, during which the team is working toward a specific goal.  On our current project, sprints are just two weeks (some XP influence here).  I think 30 days is preferable though.
  • Product Backlog - this is the list of requirements.  It can always be added to.  In our case, it is a list of User Stories.  Each sprint begins with a meeting to decide which stories from the Product Backlog will be worked on in the upcoming sprint.  The stories that the team commits to are then moved the Sprint Backlog.
  • Daily Scrum - A daily, but brief meeting, where the Scrum Master has the the team answer three questions: What did you do yesterday? What are you doing today? And what is getting in your way?

First Impressions

I will first acknowledge my basis: I believe in Agile methodology and the concepts underlying Scrum resonate with me. 

But how does it shake out in practice?

I think that Scrum is a great way to manage software projects.  Possibly, the best that I have attempted. However, based on my limited experience here are few things to consider.

It is hard to write good user stories.  I've struggled with this for several years now, and I hate to admit it. The problem mostly lies with my tendency toward optimism. We'll write some initial stories, they'll sound great to the stakeholders.  We commit to delivering them by such and such a date, then we begin to realize that we left out a number of prerequisites.  I always pad my numbers, so it has always worked out, but it feels too much like guess work to me.  (I have Mike Cohn's User Stories Applied on my desk, but I have to finish finding out what happens to Harry first.)

The mechanics of tracking are awkward. We've been using TargetProcess to keep track of the Product Backlog, monitor burn down, etc.  I had used version 1.x and I liked it, however 2.x is a little overkill I think.  I believe that it's likely a great tool, but I lack the patience to overcome the learning curve, at least at the moment. 4 x6 note cards are becoming  more and more attractive to me.  (I also like white boards!)

Ok, so neither of these caveats is the fault of Scrum.  However, they both fall in a region that Scrum leaves undefined.

Finally

I think it is hard to sell Scrum to a client.  We are a consulting company.  Our clients come to us and they want to know exactly how much they will spend to get custom software. We all know that it is inherently impossible to predict the cost of developing custom software.  Scrum (and agile practices in general) acknowledge this and provide a solution.  However, clients still want a commitment to deliver X for Y amount of money in Z amount of time.  It is hard to convince a client to work with something "open-ended" like Scrum.  (I think that this is not a problem for in house projects). Again, we've been very been very blessed to have a client who understands custom software development and asked for this.

kick it on DotNetKicks.com
Posted 08-03-2007 5:54 PM by Christopher Bennage
Filed under: , ,

[Advertisement]

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)