Info

Stories Connecting Dots with Markus Andrezak

Stories Connecting Dots by Markus Andrezak tries to discover the many different ways businesses navigate in an environment of change. Stories Connecting Dots versucht die unterschiedlichsten Wege zu entdecken, auf denen Unternehmen erfolgreich mit drastischem Wandel umgehen..
RSS Feed Subscribe in Apple Podcasts
Stories Connecting Dots with Markus Andrezak
2019
March
January


2018
December
October
May
March
January


2017
December
October
July
June
May
April
March
February
January


2016
December


Categories

All Episodes
Archives
Categories
Now displaying: March, 2019
Mar 4, 2019

Dan Vacanti - Rightsizing

I met Dan years and years ago in my active time in the Kanban community. Dan was part of the very beginning of Kanban in 2007! Since then he’s been deep into Lean and Agile. Dan authored two books, "Actionable Agile Metrics for Predictability“ and "When will it be done?“. He is also the founder of Actionable Agile. Dan always had his independent thought. Most of all, he is a builder of bridges. He worked hard with Scrum.org on integrating the good ideas of Scrum and Kanban. Also, he organises the conference LeanAgile US which just happened from 25 -27 Feb 2019 in Ft. Lauderdale, Florida. Possibly most noteworthy, Dan's twitter Avatar is not the usual egg provided by twitter, but a self made picture of an egg. 

Here excerpts of our conversation as a loose transcript. don't take it word by word, please!

Show Notes: 

The underlying idea for all of us is to maximise customer value.

Cost of Delay is a tool suggested as basis for ranking, prioritising and sequencing on a more objective base rather than gut feel. Hopefully based on basic economic fundamentals. 

An extension of that is WSJF (Weighted Shortest Job First), which is defined by CD3= CoD / Duration. This is meant to give a shortcut to give an answer to which number does this item have in the sequence of things to be done. 

But here's the caveat: It is critical enough to get the number for duration right (how long does this take to be done? - The Estimate!). But the even more critical question is: "how do we even get the number for the value of the thing we are building?" 

This is where my research started, but "Let me be honest with you, and this is just me talking, nothing I found was practical or applicable in my world.“

"More importantly, I felt there we’re a whole bunch of assumptions going into this CoD number that didn’t reflect reality.“ 

"Let’s focus this discussion on the area of complex product development work. And we try to get that number even before start working on something. Which, by definition, is when we have the highest amount of uncertainty. And this is what struck me: How can this CoD number give us the right answer? And that’s were I started my investigation.“ 

Customers will always be able to ask things from us faster than we will be able to deliver them. 

There are fundamental assumptions in CoD to be in place for that to make sense. 

When there is uncertainty involved, we need a probabilistic approach. That means, we have to work with ranges. That means we have to think about CoD as a distribution across that range. The same is true for the duration. 

Those two assumptions are not fatal. There are mathematical tools like Monte Carlo simulation that help us to come up with an answer. 

BUT: If you are in a world, where you no the numbers, then CoD/D = CD3 gives you the right number. If you do not know these numbers, once you deliver the thing, these numbers could be completely different. 

So now CoD can change and as well duration can change. When you now run a Monte Carlo simulation, you will realise that this is not the best tool once uncertainty sets in. 

The best answer in this world is to do things by random sequencing. What matters is: right sizing items. What that means is, we need to break things up to a size where they reasonable flow through our system. So, CoD doesn’t make a difference. Duration doesn’t make a difference. What makes a difference is right sizing your items. 

This flies in the face of what’s lately been said in agile, where there is a lot of talk about outcomes over output. And what we found out is that it’s actually the other way around: It’s output over outcomes. It’s the output that generates the outcome. A metaphor here is gambling, where you would place as many small bets as possible to generate outcome. 

„We’re coming back to a fundamental principle of Lean, which is that value is defined by the customer.“ What is the smallest thing that we could feedback on from the customer? 

Links:

Books:

 

1