The only thing you need to keep track of in your team

For the last couple of months, I have been diving into the books of Daniel Vacanti. Daniel helped to develop the Kanban Method for knowledge work. In his books, he explains how you need to answer the question ‘When will it be done?’. A question your customers often raise when they want software delivered. In this series, you’ll find some key concepts about predictability and forecasting!

A central theme in the books is probabilistic thinking. I introduced this new way of working at In The Pocket. One of my colleagues stated it would be hard to use this method with clients. According to him, people don’t think in a probabilistic way. Let’s start with a real life example to illustrate the contrary.

Everyone who ever commuted to work already knows how to think probabilistically. Let’s say you have a very important meeting with your CEO the next day. You definitely want to arrive on time. You already have a ‘kind of a notion’ of how long it takes to arrive at work whether you go by public transport, on foot or by car. But this meeting is important and you don’t want to arrive late. What do you do? You add extra time to your commute. How much depends on how confident you want to feel that you’ll arrive on time. If you go by public transport, you might take a train or bus earlier. If you go by car, you may leave half an hour earlier. All this, to make sure you don’t arrive late at that meeting with your CEO. And there you have it. You forecasted something in a probabilistic way. That wasn’t hard, was it?

So let’s extrapolate this to knowledge work. The ‘kind of notion’ I am referring to in the example above requires a definition of `commute`. It is simple. It is the difference between the moment you leave your house and the moment you enter your office. By commuting a lot, you learn to develop that feeling of how long it takes. You keep track of all the moments you ever commuted. Based on that information you can take your chances. Notice how your internal forecast exists out of two parts. First you have a range, in this case a commute time. Then you have a probability. The more time you foresee, the higher the chances you’ll arrive on time. To apply this to software delivery, all you need is a starting point and an endpoint for your work items. With your teams, decide on what these are, and start measuring the time it takes for a single work item to complete. This is what we call Cycle Time.

Soon you’ll have tracked the cycle time of enough items. Trends will emerge and you will be able to start forecasting items in a probabilistic way. You’ll develop the same ‘notion’ you develop when commuting. Based on historical cycle time data, forecasts can be generated. Only this time it won’t be a notion, the data will speak for itself. Stay tuned for more deep dives into the wonderous world of flow metrics. Next you can read all about how scatter plots can drive your team’s predictability.




Inspiration from the digital side

Recommended from Medium

Five Tips to Get You Started in AWS

Bard Bot

Three Advantages of using the Application Programming Interface

The Spring Revolutions 3 — Configuration

What is a mainframe application?- 5 things You Need to Know About Mainframe application.

Basic Crochet Beanie Pattern

Setup KVM virtualization in Linux

Use Advanced MySQL Operations to Analyze Python Web Scraper Data

Use Advanced MySQL Operations to Analyze Python Web Scraper Data

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Thijs Morlion

Thijs Morlion

Team Lead @ In The Pocket, Europe’s Finest Digital Product Studio | Digital Arts and Entertainment Alumnus | Spatial Computing Enthusiast

More from Medium

📅 April 13: Scrum Master & Agile Coach Remuneration 2022

How To Become a Successful SAFe Agile Coach?

3 Warning Signs That Your Agile Transformation Is Failing, and 3 Ideas to Fix It

Agile vs. Lean Software Development: Differences and Similarities