In one of our projects we are using Scrum and today we finished the 8th Sprint. The team has 8 elements, 6 of them in full-time. In the beginning, at Sprint 1, we started with 3 developers. No one had experience using Scrum, but we all believed that Scrum could help us manage our project. Our customer also had the receptivity to new ideas and promptly accepted to use Scrum. Since then, it has been a great journey of learning Scrum in the field, where the "battle" happens.
First of all, let me say that this project is quite complex because it consists of developing a platform that must replace an existent one. Due to the dimension of the problem, we couldn't do a Big Bang approach, which means every design decision must coexist with the existent platform. I will make a retrospective in some aspects of Scrum and try to figure out what has been good and bad. Let's begin.
Daily Scrums
In Scrum theory the daily scrum must be the first activity of the day, everyday at the same hour, at the same place. The first change we had to made was to shift the daily scrum to the middle of the day, as opposed to first thing in the morning. Basically, it was impossible to have all the elements of the team at 9:00 AM or 10:00 AM. Currently, the bell rings at 12:00 and we start our stand-up meeting in a small room.
The duration of the meeting must be 15 minutes. We must answer to 3 questions: What did I do yesterday, What I'll do today, and what are my impediments. When the team grew, we had some difficulty not exceeding the 15 minutes. In fact, we exceeded that time in many occasions because there was a great temptation of starting discussions in the daily scrum. We are better now and, if we feel that there is something to discuss, we wait until the end of the meeting and the guys that want to discuss stay in the room.
The daily scrum is something religious for us. We all know the state of the project. We all know what each team member is doing. We all know the problems we are facing. The daily scrum is absolutely essential.
The Sprint Planing Meeting
Every sprint begins with the Sprint Planning Meeting. First, we and the product owner choose the items we want to include in the sprint. Then, we start to plan our sprint identifying the Sprint Backlog Items to be made. In the Scrum theory it's said that the tasks must be estimated to have the granularity of 4-16 hours. We found difficult to do that in some features. To achieve that estimation precision we have to do in-depth analysis, which can't be made in half a day. What we do is estimate the feature in days, and the preliminary tasks in hours. Later, during the sprint, when we have more information, we split the feature in smaller tasks.
Sometimes we wonder the time wasted if in the beginning of the project we elaborate an in-depth planning, with tasks, dependencies, resources, etc. Wow, it certainly seems scary :-)
The Sprint Backlog Items
In my opinion the Sprint Backlog Item is the most important artifact in Scrum. However, this is only true if the Sprint Backlog is up-to-date and reflects the reality. There is some impedance in some guys to update the Sprint Backlog daily. I had to point the finger sometimes, but we are getting better. We're using Visual Studio Team System with the Conchango plugin to manage the work items. My first activity in the day is to watch the Sprint Burndown Chart to evaluate the state of the project. This way is quite simple to spot the guys that aren't updating the sprint Backlog.
By the way, the plug-in from Conchango is certainly useful but it could be better. For instance, I would like to have the global vision per day, and per work item, in one sheet.
Sprint Review
We finish our sprints making a demo to the product owner of the features included in the sprint. In the firsts sprints we didn't use powerpoint. Now, before the demo begins, we present a powerpoint with a few slides to remember all attendees in the room the objectives of the sprint, what we can accomplish and what we can't.
The Retrospective Meeting
We all love this meeting. We are absolutely honest with each other. There are no ceremonies. If I have to say "in this Sprint you were a chicken", I'll say it. Total transparency is our motto.
As a conclusion I must say that I am a big fan of Scrum. However, don't be eluded: there are no perfect methodology. By the way, we are late in the project (which can't be attributed to Scrum use), but I think that there is a big difference in this lateness: everyone knows that we are late, and everyone knows it when the lateness shows, not only when the project is halfway or almost finished. Scrum is transparency!