Data Accuracy

We have a tendency to believe that anything we see in a chart is 100% accurate, although that’s often not true. To understand the accuracy of the chart, we have to understand a couple of things:

  1. How accurate the initial data was.
  2. How much of the original data set was used in the chart.
  3. How good the chart is at communicating the right message.

Stalled work

As I talked about in this earlier video on standups, the work on our board can loosely be grouped into three categories. It’s either active, blocked, or stalled. We tend to spend a lot of time talking about the active and blocked work and have a tendency to forget about the rest, which results in stalled work aging unnecessarily. That in turn will make the overall system less effective and less predictable.

Slicing epics

We talk a lot about slicing stories but then when it comes to slicing larger types (epics, features, etc), we tend to wave our hands and say “it’s the same, only bigger”, which while true, is rarely helpful.

Remote work vs in-person: What does the data say?

When the worst effects of COVID had appeared to pass, many companies started implementing return-to-office mandates for their knowledge-workers, which have been controversial at best. The decision to do this was based on gut reactions from managers who, having no actual data, made the best guesses they could with what they knew.

Who should look at what metrics?

When we talk about metrics, there is often an assumption that everyone in the company needs the same data to make decisions and this is dangerously incorrect. Different levels of the organization need different kinds of data to make effective decisions. Yet, all too often we use the wrong data at the wrong point.

Quality vs Testing: Solving the wrong problem

In the agile space, we talk a lot about testing. How will we test things? What should we test? How can we automate our testing? Yet, testing isn’t actually the point. What’s important instead, is quality. If we had amazing quality then it wouldn’t matter if we’d tested or not.

Slicing stories

In an agile environment, we split our work down into what we call “stories”, that are the smallest unit of value passing through a workstream. Unfortunately, we have a tendency to over-complicate story writing, making it unnecessarily hard. Done well, it can be a simple process of taking small steps, repeatedly.

Premature optimization

We have a tendency to think that making any one part of the workflow more efficient will make the overall workflow also more efficient and that’s just not true. Part of that is that not all parts of the workflow are on the critical path and improving something that isn’t currently a bottleneck won’t help the overall flow. But there’s a second reason that’s less obvious - sometimes optimizing for simple cases in the workflow, can make other parts of the workflow much worse.

Improving meetings

When we look for opportunities for improvement, at some point every team will bring up meetings as being an ongoing problem for them. When we dig into what the actual problems are, we find they always fall into one of three categories: