Looking for CFD example beyond the normal few columns

10 views
Skip to first unread message

Mark Levison

unread,
Jun 10, 2020, 4:59:25 PM6/10/20
to lonely-coaches-sodality
I have a attendee who clearly has organizational problem with approvals. She needs to illustrate the overwhelming cost - of this wait. I have several terrific descriptions CFDs in general: https://getnave.com/blog/how-to-read-the-cumulative-flow-diagram-infographic/ and http://brodzinski.com/2013/07/cumulative-flow-diagram.html

What examples do you have that illustrate this well?

Cheers
Mark

Doc Norton

unread,
Jun 10, 2020, 5:48:24 PM6/10/20
to lonely-coac...@googlegroups.com
Those look really good to me. I have talks that describe the process and some visuals, but nothing that rivals what you already have. What do you feel is missing from the resources you have?


From: lonely-coac...@googlegroups.com <lonely-coac...@googlegroups.com> on behalf of Mark Levison <ma...@agilepainrelief.com>
Sent: Wednesday, June 10, 2020 4:59:22 PM
To: lonely-coaches-sodality <lonely-coac...@googlegroups.com>
Subject: [LCS] Looking for CFD example beyond the normal few columns
 
--

---
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-xT9iqK1wzrZaPic-fEfzyQg14Nt%3DAk%3D_ROHgAm0LD0A%40mail.gmail.com.

Wouter Lagerweij

unread,
Jun 10, 2020, 5:48:59 PM6/10/20
to lonely-coac...@googlegroups.com
I have the bug project at a current client, where I've used a cfd to show that _fixing_ bugs is quite fast, but _prioritising_ then takes ages...

I can send a picture if you like, tomorrow.

I think the phrase in the discussion about the growing bug backlog was: "it's not the development teams that are the bottleneck..."

They're moving to a solid zero bug policy. Probably.

Wouter

--

Mark Levison

unread,
Jun 10, 2020, 6:25:10 PM6/10/20
to lonely-coac...@googlegroups.com
@Doc - the articles are excellent but for less technical folks Dev and Test are black boxes. In addition most people can't see creating a Kanban wall beyond a standard 3-4 columns. The key insight is that your Kanban wall can measure anything you can observe. To be fair I can still remember when I finally had that insight myself - for at least five minutes I thought I was a genius, then I realized I was late to the party.

@Wouter a picture would be lovely it will illustrate the point perfectly.

Thanks
Mark

Allen Holub

unread,
Jun 10, 2020, 6:28:23 PM6/10/20
to lonely-coac...@googlegroups.com
There’s actually a really nice 9-column Kanban board pictured in the Wikipedia article https://en.wikipedia.org/wiki/Kanban_board

_________________________________________
Allen Holub  ◇  @allenholub   ◇  +1 (510) 859-3620
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.

Glenn Waters

unread,
Jun 10, 2020, 9:28:48 PM6/10/20
to LCS
Some the most compelling case study I've read is the epub downloadable from: https://blackswanfarming.com/experience-report-maersk-line/

There's other good resources on the site.

Glenn

Wouter Lagerweij

unread,
Jun 11, 2020, 4:54:11 AM6/11/20
to lonely-coac...@googlegroups.com
Just meant as an example of using a CFD in some discussions:

Last year, with the growth in both users and development team, there were big issues just picking up an incoming bug report, and reproducing it (the 'Reported/Investigation' band). This was improved (clearer process and priorities) and is now doing a lot better. The bands 'In Progress' and 'In Testing' are almost invisible: most bugs are fixed very quickly, and this has been stable over time. The 'Confirmed' (waiting for a PO to prioritise) and 'Prioritised' have grown over time, initially the same as the 'Investigation' band, but though the growth has stopped, they never managed to make up for all  the bugs that are still in there.
Screenshot 2020-06-11 at 10.37.47.png
Based on that (and, maybe, my suggestion/threat that we start celebrating each bug's birthday...), there's a couple of changes they will be trying:
- Clear, mostly automatic, rules on what the priority of a bug should be based on the input from the person investigating it, and 'No Bug Left Behind' rules on when we work on what priority (NOW!, now, next sprint, never)
- Throw all the old bugs away, unless someone actively is attached to one. (only after the first change is in place)

This sort of thing feels scary, and some POs might feel they are losing control, but seems like it might be accepted...

Wouter






--

---
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.


--

Pierre Neis

unread,
Jun 11, 2020, 5:24:22 AM6/11/20
to lonely-coac...@googlegroups.com
Hi Wouter


Does it help?


Pierre NEIS, CAC 
agile² GmbH
Co-founder of #play14
Enterprise Agile Coach & Consultant
Gaisbergstrasse 41 | D-69115 Heidelberg

✉︎: pierr...@agilesqr.com
☎︎: +49 160 998 724 49

Online Booking:: https://neis.youcanbook.me


On 11. Jun 2020, at 10:53, Wouter Lagerweij <wou...@lagerweij.com> wrote:

Just meant as an example of using a CFD in some discussions:

Last year, with the growth in both users and development team, there were big issues just picking up an incoming bug report, and reproducing it (the 'Reported/Investigation' band). This was improved (clearer process and priorities) and is now doing a lot better. The bands 'In Progress' and 'In Testing' are almost invisible: most bugs are fixed very quickly, and this has been stable over time. The 'Confirmed' (waiting for a PO to prioritise) and 'Prioritised' have grown over time, initially the same as the 'Investigation' band, but though the growth has stopped, they never managed to make up for all  the bugs that are still in there.
<Screenshot 2020-06-11 at 10.37.47.png>
Based on that (and, maybe, my suggestion/threat that we start celebrating each bug's birthday...), there's a couple of changes they will be trying:
- Clear, mostly automatic, rules on what the priority of a bug should be based on the input from the person investigating it, and 'No Bug Left Behind' rules on when we work on what priority (NOW!, now, next sprint, never)
- Throw all the old bugs away, unless someone actively is attached to one. (only after the first change is in place)

This sort of thing feels scary, and some POs might feel they are losing control, but seems like it might be accepted...

Wouter






On Thu, Jun 11, 2020 at 12:25 AM Mark Levison <ma...@agilepainrelief.com> wrote:
@Doc - the articles are excellent but for less technical folks Dev and Test are black boxes. In addition most people can't see creating a Kanban wall beyond a standard 3-4 columns. The key insight is that your Kanban wall can measure anything you can observe. To be fair I can still remember when I finally had that insight myself - for at least five minutes I thought I was a genius, then I realized I was late to the party.

@Wouter a picture would be lovely it will illustrate the point perfectly.

Thanks
Mark


--

---
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-qgSUUwBZMRTJM8NbxQYHyptfL05Xq1-nMA32tP-93_g%40mail.gmail.com.


--

--

---
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.

Mark Levison

unread,
Jun 11, 2020, 3:21:37 PM6/11/20
to lonely-coac...@googlegroups.com
@Allen - Wikipedia rocks - who knew that it had a great Kanban board example.

@Glenn - funny I had to jump on a mailing list when I could just of hopped on my bike and ride over :-) The Maersk story is compelling and illustrates the problem nicely.

@Wouter as always you rock, I assume I have permission to share this privately with the group

@Pierre Hakan's post does an excellent job of explaining the mechanics. What was missing in this case is a story about the data. Lucky for me both Glenn and Wouter gave me the extra stuff.

Thanks to all  - time to write my post class followup email.
Mark

Wouter Lagerweij

unread,
Jun 11, 2020, 3:24:16 PM6/11/20
to lonely-coac...@googlegroups.com


On Thu, Jun 11, 2020, 21:21 Mark Levison <ma...@agilepainrelief.com> wrote:

@Wouter as always you rock, I assume I have permission to share this privately with the group

Sure, I left out all identifying information.

Wouter

Chet Hendrickson

unread,
Jun 12, 2020, 1:42:19 PM6/12/20
to lonely-coac...@googlegroups.com
I keep thinking computational fluid dynamics.

--

---
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.

Jon Kern

unread,
Jun 13, 2020, 4:50:44 PM6/13/20
to lonely-coac...@googlegroups.com
Hi Mark,

I have plenty of data I can share…

But I thought you said your client who “clearly” has issues with “approvals?”

Is this a workflow step?

My colleagues and I have started to play around with sucking in the Jira data and doing some interesting analyses to back up “gut feel” on problems in delivery of value…

And we can also start to look at timings… how long in a status...

It is early stage and it requires trying to filter out weird crap that might happen if issues are accidentally transitioned…

But hopefully you see the idea we’re working toward. Starting to use this on engagements to help see if we can match perception and anecdotal spot-checking of the team’s value stream...
  • The total flow of value (story points) through each of studied workflows for each of the two last quarters (i.e. October to December 2019 & January to March 2020) was roughly equal (439 in / 385 out & 319 in / 344 out)
  • The total flow each month shows some large discrepancies that indicate the flow of value is not smooth 
  • Process time for a story to move through the workflow is 53 days
  • Even if we ignore Triage & To-do, which reduces the process time by 33 days, process time is still a chunky 20 days
  • The routes the stories take through the workflow involve a lot of loops back to earlier stages — bad data, or what? 
  • Content Forums Development total process time is 21 days

As I said… very early work. But I like the Google-Analytics-like flow diagram.


--

---
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.

Mark Levison

unread,
Jun 14, 2020, 6:30:34 PM6/14/20
to lonely-coac...@googlegroups.com
@Jon - that is freaking brilliant. Approval(s) - there are sometimes as many as 9, are stages in the workflow. My unscientific hunch is that with 9 approvals that will be the bottleneck in the system. My simple test - if I have pixie dust and could double the throughput of your team, would they deliver value twice as quickly. Since the answer was clearly no, we know where the problem lies.

May I share the picture with my client.

Cheers
Mark

Jon Kern

unread,
Jun 14, 2020, 8:46:36 PM6/14/20
to lonely-coac...@googlegroups.com
Sure thing, Mark.

Like I said that was a very first stab — without trying to clean up and see some of the “oddities” it revealed. Depending on their system we might be able to analyze their data as well...

(For example, if you do not implement a “reject” status, then an issue going from “Todo” to “Done” is about the only option — but it looks bad ;-) )

To truly get the dead time (waiting for approvals), I think you would have to get the “edge” transitions captured — ready for peer review, peer review completed; ready for accessibility approval, accessibility approval completed. 

  • Issue created
  • “Selected for Development”
  • In Process
  • Ready for Peer Review
  • Code APPROVED
  • Start QA
  • QA Complete
  • Ready for Performance NFR
  • Performance Approved
  • Ready for Senior Review
  • Senior Review APPROVED
  • Ready for Release
  • Release APPROVED
  • Deploy to Production
  • etc.


Nonetheless, you could manually inspect some issues to see when they were moved through the various statuses. It will still show the cost of delay for the approvals.

On one project I was working on, I randomly picked what looked like a simple issue for “ship to address” stuff. The issue took two years. Lots of “It’s a long story” explanations when I asked WTF happened… LOL

Another very simple issue was 28 days with maybe a dozen or more people touching it…

Somehow, folks overcomplicate the shit out of everything. And then make it so nobody can really do very much of the overall process. And therefore, many people are content to not give a shit if their work ever sees the light of (customer) day. Because it is so long from when they worked on the code… sigh.
--

---
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.
Reply all
Reply to author
Forward
0 new messages