This week we talked about metrics, making time thieves visible, and the operations review.
Your Metrics or Your Money
- The idea of using a probabilistic approach instead of a hard estimate is something Geoff had seen in Waltzing with Bears: Managing Risks on Software Projects.
- More often stakeholders will hold you to the earlier end of an estimate range; they want stuff sooner.
- Being predictable is what counts.
- Dependencies can set the due date for you, for example a product go-live date.
- Arbitrary due dates set the wrong expectation.
- Estimates != deadlines. You can’t get away from deadlines; it’s a culture issue about how estimates are respected.
- Unanticipated obstacles prevent things from staying on schedule. Recall the discussion on exposing dependencies where all things have to be on time for the whole thing to be on time.
- You need data about estimates so you can make decisions based on data, not opinions.
- The Scrum burndown chart shows accountability about whether work is getting done. Use what helps your team.
- Typical estimation… Add up all the parts to build the whole, then add a buffer. “Humans are predictably horrible at estimation.” The issue is that every one of those parts also has uncertainties, which compounds when assembled together.
- Flow time: amount of time between “task started” and “task completed”. The book says to include holidays and weekends as well, which Jameson disagreed with, as it implies you should be available to labor on a task at all times.
- Operating at 100% capacity doesn’t work per Kingman’s formula in queuing theory. Once you get above 80% capacity, the queue length grows exponentially.
- Flow efficiency: how much time something spends in a wait state compared with its flow time.
- “Old school management assumptions about economy of scale do not apply to knowledge work problems such as software development.”
- Small batch sizes are key.
- Realize it’s okay to be wrong at first about metrics, WIP limits, capacity, etc. Inspect and adapt.
The Time Thief O’Gram
- We couldn’t figure out what the y-axis was in this diagram.
- Most work item management tools (e.g., Jira, Azure DevOps) let you tag work items. You could query how many items within a given time frame are tagged with “unplanned work”. If you have the time, you could also list in the description/history of said work item why or for how long the time thief was involved.
- The advantage of such a chart is it puts the data in front of people that can do something about the problem.
Operations Review
- We talked about how to read a cumulative flow diagram (CFD). Is it about what the levels are at a given x value (time) or about the thickness of the layers?
- The operations review is about sharing information about organizational health and continuous improvement.
- Metrics
- Throughput (cumulative flow)
- Flow time
- Issues and blocked work
- Time thief-o-gram
- The book suggested that everyone (including individual contributors) should attend. Maybe list them as optional? Should we be concerned why they don’t want to attend?