For years I have relied on different reports, pie-charts and graphs for tracking my team’s progress, as well as my own. I had filters for the tasks which were in progress, for the ones overdue, and for the ones assigned to myself. I had pie-charts rendering the bug count for each of the guys in my team, and also for each product component (architecture-wise). I used a graph that was telling me how many issues were created, in contrast to how many were resolved over a period of time.
But why…
Well, I guess we were driven to this kind of management by the way we used to work.
Our teams were built around the omniscient Team Lead figure, the one who had all the answers to any question, from anyone – “above” or “below”; the one who was reporting, and was being reported to. Each developer was focused on his or her components, not “needing” too much knowledge of others’, so the lead was playing a key role in keeping things together and working. Testing was perceived as a somewhat external job, as there was a completely separate team for that, with their own schedule, and their own way of doing things. The developers pretty much thought their job done as soon as the product of their work was delivered to the testers.
You have probably figured out by now, that the team leads had all the reasons in the world to make sure that they were aware of the detailed status, problems, and interdependencies with other teams, while still struggling to avoid doing micromanagement. Tough job.
This is exactly why we had to change something.
And we did. After countless attempts to correctly understand and adopt the Agile practices and principles, after reading many books, attending some conferences and trainings, and after having failed so many times, we have now finally come to a point where we’re doing things much different than before.
The all-knowing team leads turned into trusting scrum masters, relying on their people, who now need to work closely together to get the job done. The teams are now composed of both developers and testers, so everybody finally got on the same page. We don’t develop anything that can’t be tested right away, developers receive useful input from the testers just from the analysis and design phase, basically everyone works together from the start ’till the end. This doesn’t only happen inside a team, but to some extent, throughout the entire “big” team.
I still have my reports and pie charts, but I don’t recall when I’ve last checked any of them. Instead, we all use a continuously updated Burndown Chart. Not only it tells us how much work we have done, but most importantly, it tells how much we have left to do until we’re done. This also means that we can use it to tell whether we are able to finish everything we’ve planned, and also, what we are going to get done by the end of the sprint. Combined with the task board, containing cards for what’s to do, in progress and what is done, we’ve got all the information we need.
If anybody asks about progress, problems or status, anyone in the team can answer, because we’re all together in this. We are all estimating, planning, reestimating when needed, together, so we all know and care about what’s happening anytime.
And it’s all in one single chart.
