If you are trying agile or scrum, the worst part is the really boring meeting at the beginning of the iteration. This meeting can make or break the use of agile in your environment. The reason it is the tipping point, is because this is place where management really interacts with the development team. I’ve had mixed success implementing agile in typical waterfall situations. The factor that separated the good from the bad seemed to exist in iteration planning.
Estimation is art, be creative
This is the first and most important lesson I had to learn. No one wants to sit in a meeting listening to others discuss things and estimate them on your behalf, or argue with you about how long its gonna take. Make it a game. First turn hours into points. 10 points a day, 10 days an iteration, 100 points. Now give everyone flash cards with denominations on them. Discuss the problem, allow everyone to pick their number, but not show it, and everyone shows at once. If there is varying degree of points, discussion needs to continue, if not, thats the estimate. This system has successfully cut my planning meetings from 3-4 hours to about 1.5 hours and now we go have lunch. So I got 2 things, faster meetings and team building.
Velocity is essential to movement
Sounds like a dumb and obvious statement, so track velocity. If you aren’t tracking your progress against your estimates. Then you have no idea how good your estimates are, and your points game will be all over the place. Whatever you use for ticket tracking, find a way to record the points, and make sure you update it daily. You will need 3 reports to really be able to see whats going on.
- Average points per iteration per person (velocity)
- Points done vs points to do by iteration (iteration burn down)
- Points done vs points to do overall (product burn down)
These reports give you real insight into the progress. By using a tool that has these reports you can really cut time out of your day as the evangelist for this process. Management can go look at the report, no need to ask you questions like, How are we doing? They can see, we are 40% done with this iteration’s tasks, and actually won’t slip any features this iteration. Make sure the tool you choose can drill into tasks, that way you can virtually eliminate your need to answer status questions. However, you can reiterate whats there anytime asked.
Praise Consistency, Not Haste
Fast is good for short distances, but we are running marathons. We aren’t looking for ability to write the system in 2 days. What we are looking for is the ability to estimate effectively and get to a point where you are delivering stable features consistently. Some iterations will show huge progress, especially in the beginning. This will level off, as it should, and you want it to. Some team members are slower, some are faster. Some sleep 8 hours, some sleep 4. Some are married, some not. Why make these problems? By praising haste you are hoping for people with no lives who don’t sleep. By praising consistency you level the playing field for all of the types of people in your organization. Promising the sky doesn’t help anyone. Committing to nothing and delivering the sky, also does me no good. In waterfall, both of these practices are common, and the latter is praised. In agile they are detrimental to the success of the project on the whole.
Hope these points are helpful, they have made all the difference on several projects for me.
