The Importance of Being Earnest

The Pitfalls of Management Reporting

24 July 2013

Warren Jones

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.

Article Rating

Current rating: 4.7 (3 ratings)


Glen Wang, CSM, 7/24/2013 9:41:21 PM
Value if the final mesurement. Like while we are driving, we care the dashboard. But after we get to the destination, forget the dashboard.
Bhoodev Singh, CSP,CSM,CSPO, 7/25/2013 3:27:54 AM
Let's not forget that odometer still records the mileage even we've reached the final destination. Good example. Thank you!
Warren Jones, CSM, 7/25/2013 6:02:20 AM
Thanks for the comments Glen and Bhoodev.

To play with the analogy a little more. An odometer does not make the car go any faster. It simply provides a measurement of speed to the driver, so that he may make decisions on an appropriate to speed to drive at. In Scrum, the driver is the PO, SM and team. I see a problem when "others" decide to use the odometer reading to determine whether the speed of the vehicle is appropriate, or not. This can lead the driver to focus more on the odometer reading, than watching the road.
Eric King, CSP,CSM,CSPO, 7/25/2013 8:13:02 AM
Hello Warren,

Another excellent read! I couldn't agree with you more on the importance of the PO being continually involved at the team level. I have personal experience where the PO was not engaged and team became very metric and report focused as management began demanding more "status updates" from the team. The end result was a very demoralized team that felt as if their true contribution to the program was only represented in the "status update". Their true creativity was stifled as they focused on the hours instead of the value. I agree with what a team member of mine said once:

1. The Product Owner wants to build the right thing
2. The team wants to build it the right way
3. The Scrum Master wants to continually improve and represent the learnings

Nice article once again! Cheers.

You must Login or Signup to comment.