Myron Tribus said:
"Managing a company by means of a monthly report is like trying to drive a car by watching the yellow line in the rearview mirror."Periodic progress reports are a symptom of hierarchical thinking. They make everybody 'look up' at managers rather than 'out' to users.
Progress reports don't tell you what's going on. They tell you what people want to tell you. And decisions based on such incomplete information are risky and likely to be poor. Producing reports is waste; it’s not adding value.
As John Seddon
says "
reports are substitutions for action ". To really know
what's going on you must go see the real thing for yourself. And do
it regularly. Talk face-to-face with the people doing the work and
observe the actual process at the actual place to obtain actual
data. Learn from each visit and make your decisions on the facts
you have gathered yourself.
9 Comments
Maybe for some companies, but when you're talking about online, especially something like eCommerce reports and solid analytics are your life blood.
I'd add...
ANY observation is realtime at best (e.g. face-to-face, or phone conversation); any indirect observation (report or otherwise) is already starting to decay as far as information validity.
Making decisions with perfect information is not to impossible; what you have to assess is whether the value of more complete, but perhaps older information is more valuable than less, but more current, information. In some cases, the quantity (or extra value from getting details) is more valuable and worth it. But of course, this is not what comes ot you ina distilled montly report...
Paul
I haven't yet seen a manager who makes decisions based solely on periodic reports. Reports are just one of several tools or dimensions of evaluating performance and issues. They are usually useful.
So are you saying that there should be no reports whatsoever?
Try running some 100000 person company without any reports. They are definitely not the only way to keep track of things but metrics and summaries are necessary.
Unfortunately I've had the pleasure one more than one occasion of having to produce and subsequently explain summarized and aggregated departmental reports. I've seen such reports elicit "doing ok"/"everybody panic" responses at management meetings that lead to arbitrary target setting. The key issue with these typical tabular report formats (%target, YTD etc.) as I see it is that the data is presented out of context and can lead to superstitious and kneejerk reaction.
It's essential to have the right measurements in place (Plan Do Check Act!) so that processes can be understood and subsequently improved. Right now though the "industry standard" reporting that I see doesn't meet that need.
I didn't say metrics or measurements weren't necessary but they should be owned by the people doing the work and not management. I'll blog more about this soon.
I have found that reporting on the progress of the release is more valuable and productive than reporting on last iteration. But the former can be harder, particularly if your release content is changing, which is a big reason we do agile anyway, right?
The quotes from Myron and John need to be understood in the wider context of what they both have to say. Both advocate the use of Statistical Process Control (aka Process Behaviour Charts - Wheeler) to gather and analyse data. In addition to providing insights into the process, they provide predictions for the future (hence Myron's "rearview" comment).
Reports have to be useful, appropriate and 'just enough' like every other documentation for an Agile programme.
I do not know any CEO or Director that manages by report alone as the 'yellow line' analogy suggests. However, when they then have to communicate key messages to investment boards, shareholders etc they are useful. The same is true from the other multiple levels within organisations: projects to programmes, programmes to business, etc. I know this because I have created processes and reports that senior stakeholders find useful and valuable and that the dev teams do not find onerous to create.
I am sure that you did not really mean that "Reports are waste" (even though I have seen many wasteful reports) rather that you were hinting at the age-old Agile adage of "collaboration over documentation", which I certainly agree with whole-heartedly.