Frequent Status Updates–What They Really Mean
Are you (as a developer) inundated with frequent status updates? Requests like: “How far are you?” “What did you do today?” “Where are we?” Or are you a project manager that requests frequent status updates? Then this post is for you.
Let’s start by defining frequent – I think this is going to be different for different teams, and will vary with the Application Lifecycle Management (ALM) maturity within the team. I would go so far as to say that one status update request a week is too frequent. Certainly one a day is far too frequent.
Frequent Status Updates reveal some symptoms of poor process:
- Measuring the Wrong Things
- Large Batch Size
- Lack of Transparency
- Lack of Trust
- Unpredictable Meeting Times
Measuring the Wrong Things
In his book The Principles of Product Development Flow, Donald Reinersten frequently discusses the impact of measuring “proxy variables”. Proxy variables are quantified measures that are substitutes for real economic measures. For example, most developers measure and try really hard to reduce cycle time, but if you ask them how much it would cost to delay a release by a week, they would have no idea. Instead of measuring the economic impact of decisions (the real variable), they’re measuring cycle time (a proxy variable).
Similarly, frequent status updates are attempts to measure productivity or value-added. However, “being busy” is simply a proxy variable for delivering value. The Observer Effect shows us that the very act of measuring a system alters the system. Status updates usually require a fair amount of effort (especially if you don’t have a proper work management tool) so every time you ask for status updates, you slow the team.
This gets even worse when the time to gather the status report is long – this can mean that by the time you get the report, the report is out of date. That’s not helpful or valuable to anyone.
Another problem that the frequent updates could indicate is measuring success by conformance to the plan. Again this is just a proxy to did the team deliver value. Product Development is volatile and unpredictable at times – trying to manage that by eliminating change is usually a bad idea. Responding rapidly to and managing change is far more valuable. If a project manager is always checking on the team to make sure they’re conforming to a plan, then perhaps that indicates that the plan is incorrect?
Large Batch Size
If you get “value” at the end of a batch, then it stands to reason that the larger your batch is, the longer you’ll wait to get value. This can cause a knee-jerk reaction: treatment of a symptom (long spaces between feedback), rather than treatment of a cause (too large batch sizes). In other words, if you have to request feedback to see where you are, then perhaps you should shrink your batch size so that you get “feedback” (delivery of value) quicker. Shorter batches negate the need to status updates since they end quickly.
There are a myriad of other benefits to smaller batch sizes (including improving cycle times) that I won’t go into here. However, smaller batch sizes allow the end of the batch to provide the feedback, rather than having to ask for status mid-batch. This removes the “cost” of gathering the status report during the execution of a batch.
Lack of Transparency
Frequent status updates can highlight the fact that there’s very little transparency into what work is in the pipeline. If you don’t have an effective tool to manage work that anyone can query or report from, then you’ll see a lot of “how far are you” requests. I’d even go so far as to say if you don’t have a tool to visualize your pipeline, you’re still going to get a lot of status update requests.
Lack of Trust
Often this is an extension of Lack of Transparency. If there is a lack of trust between the project manager and the team, then often a symptom of this lack of trust is frequent status updates. The project manager doesn’t trust the team to deliver value, so they continually “police” the team to make sure that the team is working according to the plan. In high-trust environments, there is a lack of these frequent “how far are you” requests.
Unpredictable Meeting Times
This may seem basic, but it’s surprisingly common. If you have a status update meeting “when some milestone is reached”, and there is some slippage, then you need to re-organise the meeting again. If, however, you have a fixed status meeting date and time (like a daily stand-up, perhaps?) then you never have to re-organise meetings. You know exactly when the status is going to be communicated.
How to Counter Frequent Status Updates
Measure the Right Things
A busy developer is not necessarily a productive developer. Conversely, having spare capacity does not mean that work won’t be done on time. We need to move beyond the archaic and out-dated models of Product Development Management and embrace new paradigms. This means that we need to start measuring the right things – such as cycle times, batch sizes and value delivered. In The Principles of Product Development Flow, Reinersten starts off by bringing us back to basics: economics. If you can’t express your measurement in financial terms, then it’s probably not worth measuring. To refer back to the cycle time argument, you can only focus on reducing cycle time if you actually know how much the cost of delay is. Start measuring the right things, and you’ll see your “how far are you?” requests dry up (much to everyone’s relief).
Reduce Batch Size
Working smaller queues has many benefits – one of these is that if the queue is short enough, it finishes before you need an update. This eliminates the need for a status update altogether.
Surface (and Visualize) Work In Progress
Having a way to visualize your work in progress is critical – whether you use a whiteboard with stickys or have some sort of electronic system, make sure you can visualize your work in progress, especially your queues. This will not only allow anyone to see what’s going on, but to start making decisions without having to call everyone together.
Improve Trust
Trust is earned, and that’s certainly the case in Product Development. But remember, it’s a two-way street – business needs to earn ITs trust, and the other way around too. This is a “soft-skill”, and while it’s the hardest to get right, in my opinion it’s the one with the highest reward level. High trust environments foster creativity, productivity and sustainability, so work on making your environment one of high trust.
Schedule Predictable Meetings
Just do it – make a regular, time-boxed meeting (like a daily stand-up). You’ll never have to guess if the meeting is on or not, you always know it’s on. Time-box it to keep it snappy and meaningful so that people value them. You’ll start finding that this meeting gives you pretty much everything you need to know, so you won’t need to ask people where they are.
Conclusion
If you’re a victim (or perpetrator!) of frequent status updates, you may want to assess your ALM process to do a health check. Frequent status updates indicate bad health and you should change your processes accordingly.
