Kingman's Formula and its applicability to development teams?

[Mark Levison]

I suspect we've all seen a variant of this graph:

..possibly in the Poppendieck's - Lean Software Development Toolkit. It wasn't until a few days ago, I realized that this called Kingman's Formula. Kingman's demonstrates that lead time gets worse as a function of both: utilization and variability (both in processing and arrival times for new items. Meaning it really looks like this:

(Images from: https://www.allaboutlean.com/kingman-formula/)

Given the variability in the size of a development team's work, this would seem to emphasize the importance of reducing utilization by a large amount in response. I could derive Story Slicing, Limiting WIP and others just from this one equation/picture.

Long lead up short question. Since this is so compelling (for me at least), what is it that I'm missing about its applicability to development work? Before this week I'm thinking I had never previously heard of it and for a pack rat like myself this feels odd.

Help me see what I've missed

Mark

[Allen Holub]

Mark,

I usually frame it in terms of slack time. Reinertsen (in Principles of Product Development Flow) is even more pessimistic about the curve when there's high variation in task size. He recommends up to 50% slack time in high-variation settings, and 30% the rest of the time. Usually, the best I can squeeze out of an org is 20%, which seems to work okay. I explain it using a fire-fighter analogy—If the firehouse is 100% utiilized, the fire fighters are always putting out somebody else's fire, so you won't be particularly happy when you need their services. In the firehouse case, you want something more like 99% slack time. Practically speaking, this all translates to allocating time specifically for not "working" on features. Google does that by giving people one day a week for personal projects, and adds additional slack time with learning (in-house university lectures, for example). When I'm coaching, this jibes nicely with the Agile-is-a-learning-culture message. It's also a good way to talk about reducing story size down to a consistent day or two per story, and putting a hard boundary around the team that prevents the organization from injecting the latest hair-on-fire emergency into the workflow.

-Allen

_______________________

Allen @ Holub .com
@allenholub
+1 (510) 859-3620  (Skype: allenholub)
http://holub.com
http://linkedin.com/in/allenholub

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CA%2BUdPQ_W78GZt7ogjuktOwMBsTAZ8i_Lj0mzRJ7KpwZpcvMb4A%40mail.gmail.com.

[Allen Holub]

Also, while I'm thinking about it, it's also a good way to start the discussion on the inefficiencies of context swaps (which people usually think is an okay way to fill the wait time). Weinberg has a graph that's pretty good for that one:

_______________________

Allen @ Holub .com
@allenholub
+1 (510) 859-3620  (Skype: allenholub)
http://holub.com
http://linkedin.com/in/allenholub

On Mon, Feb 3, 2020 at 7:15 AM Mark Levison <ma...@agilepainrelief.com> wrote:

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CA%2BUdPQ_W78GZt7ogjuktOwMBsTAZ8i_Lj0mzRJ7KpwZpcvMb4A%40mail.gmail.com.

[Marcus Williams]

Troy Magennis had an awesome observablehq notebook showing how utilisation impacts lead time of work which used Kingman's formula - https://observablehq.com/@troymagennis/how-does-utilization-impact-lead-time-of-work - this and one of his others on the economic impact of high utilitsation might be worth a poke around.

Marcus

--

[Mark Levison]

@Allen thanks for taking the time to reply. I like the analogy of the firefighter, I also appreciate relating slack time to google personal project time and in house learning. On the subject of the multi-tasking graph I've been using it for years to help organizations see why want to dedicate people to one and only one team.

Finally I think I've ever mentioned that I appreciated your work at Dr Dobbs, when magazines were still printed on paper. (If not Dr Dobbs elsewhere in print).

@Marcus - thanks for pointing me to another of Troy's notebooks. The irony, it was one of his notebooks that sent me down this rabbit whole in the first place.

Cheers 

Mark

[Yves Hanoulle]

20 odd years ago I followed a training from the late Stephan Covey, he talked about the Eisenhouwer quadrant and how a certain fire brigade (I think Houston) was working on spending most of their time on Quadrant one tasks (aka putting out fires) to more quadrant two tasks, aka preventing fires.

https://luxafor.com/wp-content/uploads/2018/10/The-Eisenhower-Decision-Matrix-png.png

so even firemen who want to be free as possible, try to spend the time buys, trying to prevent emergencies...

next to the firefighter, ask them about the utilisation % of their servers.

People with a background in hardware, would never allow servers to be 80% utilized all the time...

why do they allow their teams to be utilized that high?

the book slack opens with a nice metaphor 

there is a puzzle, I think it's called a jigsaw puzzle with 9 boxes, of which only  are fillled, and the empty space can be used to move the other boxes

now this puzzle, is not uptimized, wouldn't it be better if all 9 boxes where used?

of course, anyone who used such a puzzle, know it would be insane to use all 9 boxes, as then the puzzle would be immutable...

I postponed reading that book for a long time as i thought, I understand the idea of slack, It was worth reading when I did 

yves

Op ma 3 feb. 2020 om 17:35 schreef Allen Holub <al...@holub.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CAHDWMgDEjH4%2BTp5tVxbDnAZN39ZnPGGDfZw0ChNsw0BDuA94VQ%40mail.gmail.com.

--

--

Yves Hanoulle - 0476 43 38 32
www.hanoulle.be

• Events I co-organize
• CoderDojo Ghent: http://gent.coderdojobelgium.be/
• Community events that need your help:

• CoachRetreat in your country >> mail me
• CoderDojo's all around the world looking for coaches. This is the Belgium subscription page https://www.coderdojobelgium.be/nl/vrijwilliger-worden
• www.agileconferenc.es all agile conferences worldwide, maintained by the community
  
  
• books:
• PO as a service: https://leanpub.com/POAsAService
• Create your own manifesto: https://leanpub.com/createyourownmanifesto
• Arduino with Geike paperback:https://www.amazon.com/Arduino-Geike-Learn-arduino-exercises/dp/9082826291
  
• Arduino with Geike E-book: https://leanpub.com/ArduinoWithGeike
  
• Tips from the agile trenches: https://leanpub.com/TipsFromTheTrenches
  
• The ScaledBallGame: www.ScaledBallGame.org
  
• PairProgramming workshop: http://leanpub.com/pairprogrammingworkshop 
• Leadership Game: https://leanpub.com/TheLeadershipGame 
• All my books: https://www.hanoulle.be/books/

[Ron Jeffries]

ISTM that Reinertsen isn't talking about slack in the same sense as "an afternoon off for learning". Reinertsen's slack is there to take up variability. 

Too often teams use their learning time to take up variability. This is really not OK. Learning time (IMO) should be dedicated, and variability dealt with in some other way.

On Feb 3, 2020, at 11:34 AM, Allen Holub <al...@holub.com> wrote:

I usually frame it in terms of slack time. Reinertsen (in Principles of Product Development Flow) is even more pessimistic about the curve when there's high variation in task size. He recommends up to 50% slack time in high-variation settings, and 30% the rest of the time. Usually, the best I can squeeze out of an org is 20%, which seems to work okay. I explain it using a fire-fighter analogy—If the firehouse is 100% utiilized, the fire fighters are always putting out somebody else's fire, so you won't be particularly happy when you need their services. In the firehouse case, you want something more like 99% slack time. Practically speaking, this all translates to allocating time specifically for not "working" on features. Google does that by giving people one day a week for personal projects, and adds additional slack time with learning (in-house university lectures, for example). When I'm coaching, this jibes nicely with the Agile-is-a-learning-culture message. It's also a good way to talk about reducing story size down to a consistent day or two per story, and putting a hard boundary around the team that prevents the organization from injecting the latest hair-on-fire emergency into the workflow.

Ron Jeffries

ronjeffries.com

If not now, when? -- Rabbi Hillel

[James Grenning]

This applies to the TDD level as well. An aspect of TDD with a fast edit/build test cycle is the ability to stay on task, focussed.

James

To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/CAHDWMgC%3DVM-ghSiXN2b7KSsxmVP6iT5rui_C_m3SptFwDZJBMQ%40mail.gmail.com.

[Dave Rooney]

On Tue, 4 Feb 2020 at 08:10, Ron Jeffries <ronje...@acm.org> wrote:

ISTM that Reinertsen isn't talking about slack in the same sense as "an afternoon off for learning". Reinertsen's slack is there to take up variability.

Yes, he's very "big" on variability, for lack of a better term. He has asserted on a number of occasions that I've witnessed that without some variability you can't have innovation. I recall at least one Twitter conversation in which he was dead set against splitting stories until they're all pretty much the same size because that would stifle innovation. I remember thinking that he seemed to miss the "pretty much" preceding "the same size". :)

Dave...

 

--

---
You received this message because you are subscribed to the Google Groups "Lonely Coaches Sodality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lonely-coaches-so...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lonely-coaches-sodality/B6D55DAC-49D4-427D-9F6D-685E292F0463%40acm.org.

[mheusser]

On Tuesday, February 4, 2020 at 8:10:38 AM UTC-5, Ron Jeffries wrote:

> ISTM that Reinertsen isn't talking about slack in the same sense as "an afternoon off for learning". 

>Reinertsen's slack is there to take up variability. 

>Too often teams use their learning time to take up variability. This is really not OK. Learning time 

>(IMO) should be dedicated, and variability dealt with in some other way.

>

Interesting thought, Ron.

I have literally heard a SAFe fellow say that the purpose of the innovation & planning sprint co-mingles, or is integrated with, the idea of slack. I believe the way the persons said it was something like "Of course if you are running late you can take slack from the PI sprint, so it has two purposes."

--heusser

[mheusser]

To be more clear:

If you were to imply subtext into my message, it would be that Ron "gets it" and the SAFe folks ...  have a different position ... subtext here.

--heusser

[Mark Levison]

Thanks to all for the stimulating thoughts on this one. As I was making my summary notes, I realized that Kingman used standard deviation, which implies a normal distribution for both arrival times and processing times. I can't say what distribution arrival times have, I would think that processing times have a long tail that skews heavily to the right. Were to run a simulation to test waiting times, I suspect that skew makes things much worse. 

Conclusion - this increases the importance of slicing all stories/features to approx the same size.

Another minor discovery I've often recommended buffer time for support: https://agilepainrelief.com/notesfromatooluser/2019/06/scrum-production-support.html - but I've always thought the goal should be to eliminate the buffer. I wonder if Mr Kingman has taught me this is inevitable.

Cheers

Mark