Show all posts
7 years ago

Faster. Faster. Faster.

I've been thinking about  the influences that might affect the team's velocity recently. Every single product owner wants to have features delivered as soon as possible. It may seem that this race for a better velocity is the wrong goal and can lead to the ugly "Work faster, basterds!" solution. But that's not the case in a good and healthy environment .

Here is the diagram I've sketched in half an hour to generate some ideas. Bubbles are activities, practices and other entities that can make an impact on the development speed. They can have either positive or negative effect. For example, it seems that only two things improve velocity directly: fast feedback and experienced developers. While there are many other things that slow us down, such us unplanned work, interruptions, multi-tasking, rework, high coupling and technical debt.

Velocity diagram. What influences velocity?

The cool thing about this diagram is that it asks very specific questions:

  • How to deal with customer requests and reduce unplanned work?
  • What to do with urgent bugs?
  • How to do more training?
  • How to have smaller batches?
  • What to do about noise and interruptions?

When you ask such questions on a retrospective meeting, you can expect quite many good ideas. If you just ask:  "How can we work faster?",  the answer would be silence and confusion.