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?
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.
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.
08-03-2007 5:54 PM