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:

Per-story estimates

Per-story estimates were an interesting experiment that failed and it’s time to move on. Today, we have better ways so it’s time to stop putting individual estimates on stories. This is equally true for Scrum and Kanban teams.

What is a Service Level Expectation?

A service level expectation is a probabilistic forecast of how long it will take a single item to pass through the system. For example: “85% chance of completing in four days or less”.

Kanban: Simple, but not always obvious

We meet a lot of teams who say they’re doing Kanban and yet are only scratching the surface and not getting the benefit from Kanban that they could. They’re moving some cards across a board and think that’s all they have to do. Because it appears so simple, it doesn’t occur to them to reach out for assistance. Why would I need training or coaching to move some tickets around?

Keeping people busy

The Kanban Guide talks about optimizing the workflow for three different attributes: effectiveness, efficiency, and predictability. It talks about the fact that any optimizations we perform will be a balance across these three and that over-optimizing on one may make the others worse.

Steps to improving predictability

If you have a need to know when the work will be done or how much you can do in a certain period of time then predictability will be important to you. We have great tools like monte carlo for probabilistic forecasting but the truth is that the forecast we generate is only as good as the data we give it. Garbage in yields garbage out. So how do we improve our data to make it inherently more predictable?

Optimizing collaboration

A manager at a past client of mine once had a new request come in. The new request would impact multiple different teams, that would all have to make changes to their individual pieces and then integrated. Because it was potentially a large change, he asked all the teams involved to come up with an estimate and they came back with a total estimate of ten to twelve weeks.

Technical Debt

The term “technical debt” is widely used in the industry even if there isn’t a clear definition of it and almost nobody uses the term in the way Ward Cunningham meant when he first coined it. It’s most commonly used to describe things in our environment, usually but not always code, that slow us down. These are things that are working - not bugs - but that are implemented in a poor way that makes them more difficult to understand or modify.

Multiple boards for a single team

Many teams assume that they have to fit all their work on to one board and that’s not true. Kanban boards are there to help you visualize and manage the system. If one board can do that well then one board is fine. If it would be easier or better to visualize and manage across multiple boards then that’s what you should do.