Surviving Agile Without a Status Report—An Introduction

Living without a status report is possible

Agile deprioritizes the status report in favor of promoting the self-organizing team. This strikes fear in managers who have utilized status reporting for years and rely on it to understand where a team stands against the baseline project scope, time, and cost. There are entire project management organizations whose primary purpose is to obtain and roll up the status of all initiatives to all interested parties.

The fifth Agile Principle from the Agile Manifesto¹ states:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

There are two aspects to this principle worth highlighting, pertaining to the loss of the status report.

First, when you build projects around motivated individuals that you trust to get the job done, you significantly reduce the need for a status report. The team is self-managing. They understand their progress better than anyone. As such, the team is the best equipped to know how to adjust to handle the terrain on the ground when it does not match the plan.

Second, the principle asks the manager to give the team the environment and support it needs. This begs a question. Without the one thing a manager has relied on in the past—the status report—how will the manager provide the team the support they need? This series focuses on answering this question.

What’s Wrong With Status Reporting?

Status reports are too clean, don’t highlight team struggles, provide diluted information, and promote a lack of connection between managers and the teams.

Sanitizes Information

One of the biggest problems with status reporting is the cleansing that occurs to the information it presents. With the command and control, hierarchical structure, and fear of non-conformance present in most organizations, it is difficult to get a status report that presents the actual status. Status report authors cleanse the messaging in the status report of any mention of problems. Having a “Yellow” or “Red” project brings extreme scrutiny, criticism, and often blame. As a result, most software status reporting suffers from the watermelon syndrome—“Green” on the outside and “Red” on the inside.

Minimizes Focus on Impediments

Second, status reports show progress a team is making against a plan but do not adequately reveal the struggles of the team and where they need support. The report does not focus on the work as it is more concerned with the completion of tasks rather than the delivery of feature value. Additionally, the report does not adequately highlight leading indicators of risk. As a result, the picture presented in the report is often one of calm, steady progress toward successful delivery against the baseline. There is often little to no mention of waste that is impeding their flow.

Provides Indirect, Diluted Information

Third, the information in the status report becomes far removed from the team and the reality on the ground. The team provides status to the project manager who may or may not work with the team daily. Then, the program manager rolls up the status along with other projects into a program status report. Next, the enterprise program manager rolls up the program status report into an enterprise status report. To further the information dilution, the project management team scrubs and sanitizes the report at every stage to show positive progress against the plan.

Encourages Management from Afar

Finally, status reports encourage physical disconnection from the team. Managers can all too easily read the report from the comfort of their office or on a web-based meeting. This status review can happen without ever meeting the team or experiencing the reality of their delivery effort. The status report is typically a digital document that is not readily available to consume; it is not visual and does not radiate information or encourage discussion with the team.

How can managers support the team when they have likely never met the team and the information in the status report is sanitized, diluted, and far removed from the reality of delivery?

Conclusion

In prior posts, we have discussed the complex, uncertain, custom, and creative aspects of software development. There has to be a mechanism for understanding the uncertainties and complexities a team faces while delivering value. As managers, this information is critical if we are to support the team. Status reports have failed at providing this information.

Status reports have run their course. Modern, Agile organizations need better mechanisms that support and serve the team’s needs as they self-organize around the work.

The upcoming posts in the series will focus on two critical actions managers can take in the absence of status reports to support and serve the team:

• Engage With the Team: Learn how to properly engage with the team without making them feel you don’t trust them to get the job done
• Promote Visualization of the Work: Learn Lean techniques for visualizing the work in a way status reports and tracking tools cannot

---

Other Posts in the Series

• Surviving Agile Without a Status Report—Engaging With the Team
• Surviving Agile Without a Status Report—Visualize the Work

---

References

1. Agile Manifesto