Campfire Talks with Herbie (#26) and Clarke ‘The Bottleneck Guy’ Ching talking about Agile and TOC – The TameFlow Approach

Here is today’s episode of the “Campfire Talks with Herbie”.

Clarke Ching - Oddsocks Consulting.

This is a companion discussion topic for the original entry at
1 Like

@clarkeching1 and @tendon:
Thank you for a very interesting dialogue on this Campfire Talk.

@clarkeching1: You made a statement that developers should be the bottleneck (when doing software development). That is an interesting statement to me - in the sense that stated like this it sounds like this is the optimal place to deliberately put a bottleneck in the software development process. I am not sure whether you meant “a bottleneck” or “the constraint” in the workflow? Also could you elaborate on your statement? If we consider the system an organization that has an innovation process from “business idea” over “software development” and resulting in “working software that satisfies customer needs so they will be happy to pay” - then why should the “constraint to be exploited” be (software) developers? Maybe I misunderstood your statement :slight_smile:

1 Like

Let me ask you some questions, Mark!

What happens when people upstream of the developers don’t have enough capacity to feed the developers fast enough?
What happens when testers don’t have enough capacity to provide fast feedback to developers?
What happens when developers don’t have enough work to do?

Your answers will help you figure out what I’m talking about.

1 Like

What would happen if you used BDD where the product, developers and testers ‘Three Amigos’ work together to understand what to code and the the testers and develpers code it together (reading ‘BDD in Action’ by John Ferguson Smart, you also say something similar in your book ‘Rolling Rocks Downhill’). So you have automated business rules being tested prior to coding with collaboration and you have your code tested prior to writing the code ‘TTD’.

Where would you want the bottleneck to be strategically when you pair people to work together. My guess is you would treat those two people as one ‘resource’, is that right? and therefore ensure the testers/developers are never starved of work…

1 Like

I was asking - and instead of answers you pose questions. Thank you for the coaching and opportunity to reflect :).

I do not think that I can answer in more than a hypothetical manor - since there is no context. So at most this is a mental exercise.

My hypothetical and simplistic answers are…

What happens when people upstream of the developers don’t have enough capacity to feed the developers fast enough?

  • Assumption: We are talking about innovation that includes “software development” - and the “developers” are “software developers” (e.g. full stack software developers).
  • Assumption: The “people upstream” are somehow working with answering questions such as “if we develop / build this - will our customers / users engage with and pay for the services / products that we have developed - partially supported by IT”.

In this case the developers have “spare capacity”.

  • Some developers might enjoy this and relax. Spend their spare capacity on something they consider meaningful.
  • Some developers might come up with ideas for possible “improvements” and start developing other stuff which is not aligned with “the people upstream”.
  • Some developers might experience this as stressful due to a fear that “some managers” will come and ask them why they are not busy. After all they are getting paid (mental model of resource utilization over optimizing for flow first).
  • Using bottleneck lingo - in this case work might build up in front of the people up stream (they will be a bottleneck restraining flow).

I could answer the other two questions - but will refrain from doing so.

The simplistic answer is that we will like experience bottlenecks - which are naturally not good if we want flow of value to our customers.

So my question still remains: Do you think that it is optimal in all cases (regardless of context) to deliberately ensure there is a bottleneck (enough work) in front of the developers. If so - why?