It is in our nature as IT professionals to be bound by facts and formulas. Little wonder, then, that we often find ourselves judging the success of a project based on a wide array of metrics and reports. Particularly as project managers, we find ourselves immersed in the data as opposed to watching what is truly occurring. Is it possible that the more importance we place upon reporting, the more we distance ourselves from the true benefits of adopting the Scrum method?
By definition, Agile promotes openness and transparency. At any time within a project, it is possible for the key stakeholder -- the product owner -- to be able to reliably appreciate the state of the project and to make informed decisions on the direction of the project going forward. It is only when we limit the autonomy of the product owner that we see a need to report beyond the defined Scrum roles. It is my experience that the more supervisory we become in Agile, the more likely we are to see a corruption of the process.
Here are a couple of examples (I'm sure you could add more):
Burn-down charts are a tool to be used by the team to assist them in their estimation activities. When used as a measure of progress beyond the team, they become a "stick to administer pain." The more you focus on a given performance metric or report, the more people manage to that measure -- as opposed to the underlying reason for implementing the measure. As a ScrumMaster, I've often been asked by team members what to do when they've spent several hours working on a task, only to find that they've made little progress and now understand that the task will take longer. When I answer that they should increase the task estimate and the "to-do" hours, they typically respond with, "But won't that make the burn-down look bad?" Their tendency is to focus on managing what the burn-down looks like as opposed to accurately reporting on task progress.
I've seen too many project dashboards in my life to take them too seriously. I've seen projects green, when everyone on the team knows the project is in trouble, and too many projects red based on an outsider's interpretation of the project status. I understand the desire for senior management to know, but the Agile method clearly places this responsibility -- and accountability -- in the hands of the product owner. The PO has the vision and the budgetary responsibility for delivering a product release and, as such, is best positioned to report on the project status. Placing this responsibility in someone else's hands often leads to an ill-formed calculation based on original backlog requirements and estimates.
The Scrum method suggests the need for a degree of trust in the key players within a project. We need to be careful that we don't carry forward beliefs derived from more traditional methods that seek to control and administer the project and project participants. If we manage by reporting, rather than by the inherent principles of Scrum, then we risk jeopardizing the very things we seek to protect.