My experience with SCRUM - Agile Project Management

A post after a long long time. There are several topics that i want to write about, but time has been a issue always. I am still struggling to manage time and i see a potential new year resolution since its almost the end of year.

I have always been motivated to look at agile practices. For e.g. TDD, Pair Programming, Continuous Integration etc. That sounds reasonable given the kind of work I am involved with - HMI Tools development and bulk of the development being in .NET. All of these practices are related to Software Delivery, whereas what I m going to share with you is agile Project Management - SCRUM.

My first stint with SCRUM was a 15 mins daily meeting in the morning for one of the projects. We used to call the meeting itself "SCRUM". Not fully correct, but not fully incorrect either. We used to go through the 3 ubiquitous questions -
1. What you did yesterday?
2. What are you doing today?
3. Are there any roadblocks in your way?

It served a good means of tracking the project status daily and immensely helped my Manager. But did it serve the purpose ? I would say, partially as we were not following it in the spirit of Sprints, Product Backlog etc.

My second stint with SCRUM was a full fledged agile project management and interestingly it was not for a software delivery. There was no "working product" which is the soul of any agile practice. We applied SCRUM to deliver Requirements & Conceptual Architecture for a new software product. What made it even more interesting was the Product Owner wanted me to "project manage" the work and was very keen on experimenting with SCRUM. I was made the scape goat and was designated as the SCRUM Master(because i was the only one who had any experience with SCRUM before :-) ) and thus i came to experience the agile way of managing project.

As always, I surfed the web, downloaded presentations, materials etc. to educate myself with SCRUM. I also got an excellent training material from one of my friends by none other than Ken Schwaber himself. Unfortunately I cannot share it as i am not allowed to.

As the work we wanted to accomplish was not a working product, we had to use a unique way of arriving at the Product Backlog. We brainstormed and used mind map to identify the various topics pertaining to "Service Engineering" which was the theme of the product. Once we had the level 3 topics, we worded them as verb phrases and bingo we had the backlog. For e.g. 'Collecting Data about the Machine' was one such level 3 topic. We voted the rank (points) of the product backlog items. The Product Owner set the priority of each item and that's how we went about allocating them to Sprints of 2 weeks duration. Most of this activity was performed as a team within meeting room.

The GOAL was pretty simple. Draft Requirements and Architecture for each product backlog item allocated to the sprint and there was a responsible team member for each item. The sprint tasks then comprised of Interviewing Customers, Interviewing Subject Matter Experts, Observing Users work in a real shop floor and translating those to User stories. This way it was easy to see what was accomplished during the Retrospectives of the Sprints. And yeah, by the way we had the 15 mins Daily SCRUM meeting as well.

The planning & tracking was fairly simple using an excel sheet that tracks the Burndown and there are several examples available on the web. I started with a version that i found on Web and had to customize it to our needs. It was kind of bumpy in the first 2 sprints, but then we settled down nicely and have been consistently able to hit the estimated project velocity based on the BurnDown.

All in all, I must say i enjoyed every bit of SCRUM. Some of the important learnings from my experience of SCRUM are -
1) You do not have to dig past project data to come up with estimates. Just apply your confidence and pick a number. Within a couple of sprints, you will have enough data from the sprint itself to feed into and that is far more reliable than all other data you have as it is for the actual team and actual work.

2) Risks get constant and immediate attention and are always on the top of the stack. Obviously you never defer them as it is at the top. Another advantage is, since the Product owner is involved, the 'Classification of the Risk' is also adequately done. I.e. you do not chase false positives.

3) There is no detailed upfront schedule planning. You could do that, but i found it unnecessary. Within a couple of sprints, with the team velocity, I could project the project end date given no change in backlog. But in reality, you add more backlog items (we did too!) and immediately, based on the team velocity, you will know when you will finish. I.e you can forecast a realistic end date.

4) The project management is very very simple. There is no fooling around with complex numbers. The very fact that I could use a simple Excel sheet to "project manage" the work says it all. In terms of time, I had to spend no more than 2 hrs a week to analyse the numbers etc. for a team of 6 people.

5) Estimation is a on-going process as it is part of Sprint planning at the beginning of every sprint. Moreover every team member gets to estimate his/her task. So if you get it wrong the first time (or first sprint), use that knowledge to correct it in the later sprints. This is perfect as productivity tends to increase with project experience.

6) The focus is on "what the team achieved" rather than on "who failed". There are no finger pointing. Its the team that "accomplishes" and its the team that "fails".

Here is an example burndown sheet that i used for tracking the current sprint. The product backlog itself was contained in another sheet in a format as prescribed in Example of burndown for scrum backlog and sprint


To know about Scrum -
Excellent Wikipedia article
Control Chaos
More Search Links

Useful links for examples of Scrum Burndown Spreadsheets
The most interesting.
Applying SCRUM for an individual
MSDN article showing plugin for Project 2003 usage with SCRUM
Example of burndown for scrum backlog and sprint

If you have any queries or comments or if you simply find this useful, post a comment with your thoughts. I would also be keen on hearing about your experiences with SCRUM if any.

Thanks for reading