Project status reports in an agile world.

Last week I posted an update on LinkedIn about how weekly status reporting via documentation (traditionally project status reports) goes against the agile principle of “Individuals and interactions over processes and tools”. Especially when neither side of the project boundary have questioned the value of creating it.

Over the weekend I’ve had a few further thoughts on the subject and thought it might be worth elaborating in an article.

1. Individuals and interactions over processes and tools. As examined in the initial article this type of documentation by default is certainly emphasizing the process and tools over the individuals and interactions. Especially if those individuals are already updating an information radiator (such as a physical or virtual board), have open and transparent stand-up sessions (or daily scrums, for those purists). If the team is open and transparent on their risks and issues, sort their own dependencies out as they happen then what real purpose does a document detailing this have?
2. It encourages individuals to value documentation and the process over working software/product in the hands of the customer. When the measure of success is delivered product, the reporting of status could be viewed as waste? This is especially true when stopping a team working to discover their status, risks, issues, delays, which can create a narrative that tracking is more important than doing.
3. Distract the team, needing to stop work and provide updates for reports creates several wastes. Now you could say that a savvy project manager could just attend the daily stand-up and get access to the information radiator. This would be a fair charge, they could. However, the information radiator and the stand-up are focussed on the delivery of value. At the stand-up, delivery of the iteration's goal is the focus. The information radiator usually shows a mixture of information however it’s all aligned with the delivery of value. You will find impediments on there, but you will not often see a breakdown into risks, issues, dependencies etc. Why? Because the empowered and autonomous team manage these things themselves. These team distractions, in turn, increase the likelihood of delays and quality issues. The interrupted members of the team are hit with context switching as their flow is interrupted. This in turn leads to cognitive delays getting back into the flow and will likely lead to quality issues.
4. Decreases the building of collaborative relationships. Communicating via documentation de-personalises the relationship and removes the context from the subject matter. Worse if you then have to talk over these documents with the client then the activity of crafting the document was a waste. It could just have been a conversation. If it is just a conversation the perhaps the conversation could have been had directly with the team. Perhaps at a sprint review or whatever event, your framework or model uses to connect the customer and the delivery team. This direct communication humanises the work that is being done, creating empathy for the customers need. Inversely it creates customer empathy for the trials and tribulations of the team producing the work.
5. Makes the use of any kind of information radiator a little more limited. One of the concepts of open transparency is that any information worth sharing is openly available for all to view at a time and place that suits them. If there is crucial information that is not on there then it would surely be a better practice to update it than create a separate document to cover that information.
6. Finally, it suggests that the team and their delivery need to be managed. It suggests that they can not solve their risks and dependencies, overcome their issues and connect and collaborate with the people they need to to get the job done. This disempowers the team, it encourages them to think that someone else will or should do this for them. This then leads to waste and often blame. If the team are accountable for their own progress, including its various hurdles then they will tackle the most important things at the point that they need to.

What can be done:

1. Have a chat with the consumers of this information and see what they need and how they use it. Find out if that information is already available in some other form.
2. Have a chat with the teams doing the work. Find out what value they see in the activity as well as if the required information is already available. If it’s not, then see how it can get added to existing events or artefacts in a way that doesn’t interrupt the team.
3. If you have to produce these things then measure the value they generate. Does it get read? If so do decisions get made off the back of it? If you are really on the ball find out the average read time and multiple that by the readership. Even with a conservative hypothetical cost of these people’s time, you will find that over the course of a project a massive amount of money is going into this effort.
4. Investigate events such as the Sprint Review or some other mechanism for getting decision-makers in a room with the people doing the work. It will pay dividends and cost less than the reporting (unless the reports never get read).

In conclusion:

In an agile environment, these kinds of reports can create the problems above. In a more traditional command and control structure where decisions are made away from the team, they may well provide some value.

Any report should provide an opportunity for decision making. If you spend the entire length of a project creating reports and not one decision is made off the back of them then it’s been a waste. As above it’s probably prolonged the delivery and therefore cost your organisation more money. If decisions are important enough to be made then they should be made by the people who can do something about them. Often these people are the delivery team. Every other bit of important information should be available all the time so that people can come and view it and then made decisions off the back of it, hopefully with a valuable conversation in-between.

Caveat: I am not a project manager, although was once. My understanding of the role is that it should take work away from the team and make their lives easier. There is possibly some huge oversight in the assumptions I’ve made here and if so I’d love to hear about them from those more invested and knowledgable about project management.

About the author:

Chris Davey works at understanding people and how they interact with one another. This has caused him to explore life coaching, CBT, NLP and in a very large part himself. He spends his days helping people work together, often with-in the software industry. In his spare time, he likes to create, playing and writing about games (http://awaitingmaturity.blogspot.com/), snowboard, travel and now and again just sit and think. You can keep up with the adventures on www.steelcurve.com, Medium @chrisjsdavey, LinkedIn https://www.linkedin.com/in/chrisjsdavey/ , Twitter @Kemlock and www.steelcurve.com. If you are really determined you can catch me on most PC gaming platforms as “Chemlock” or “AwaitingMaturity”.