I’m currently learning about the Scaled Agile Framework (SAFe) so that I can comment on it from a position of knowledge.
This path of learning came about after I spent 12 months as a Test Manager on a SAFe implementation.
I was new to the organisation & I was new to SAFe. It was a steep & treacherous learning curve which I was (thankfully) eventually removed from.
I’m now on the more sedate learning path, where identifying gaps in knowledge & filling them is actively promoted.
This post continues to consolidate my learning by making me think critically about what I’ve studied (trying to inform others is a great way finding out what you don’t know!)
In my previous posts it transpired I don’t know enough about Systems Thinking in order to comment on it in the context of SAFe.
My first goal was to read “Thinking in Systems: A Primer” by Donnella H. Meadows.
This is the first post from that book attempting to share my current understanding of Systems Thinking applied to software development.
In the book, the author uses the model of a bathtub to describe a system:
This simple theorem is easily visualized by imagining a bathtub: water enters the tub via the faucet and it exits through the drain, through leaks, or by overflowing the sides. These two flows of water–the inflow and the outflow–together determine the water level and stability of the bathtub. To maintain a constant level, the inflow must equal the outflow.
http://donellameadows.org
My Bathtub Theorem Software Analogy
I thought this would be a good place to start modelling a software development programme through the lens of systems thinking. Here’s my current thinking:
| Bathtub Theorem | My SW development analogy |
| Bathtub | Product / Programme organisation |
| Stock (water in the bath) | Software |
| Temperature of the water | Value to customers (they expect a certain temperature) |
| Inflow (hot & cold taps) | Change requests from stakeholders (impacting value to customers) |
| Outflow (plug removed) | Anything that reduces value (e.g. bugs, changes in customer need) |
How is this playing out in my head…?
| Bathtub Theorem | My SW development analogy |
| Stakeholders turn on the hot & cold taps & start to fill the bath | We (the product team) take change requests (new features, bugs, infrastructure changes…) from stakeholders & build software. Team members skills also fit in here. |
| The hot & cold taps either increase or decrease the water temperature | The change requests either increase or decrease the value to stakeholders |
| We can only get into the bath when it is a certain temperature | Stakeholders have values |
| Different people like different temperature water | Different stakeholders have different values |
| Too much hot or cold water will change the temperature so that it is not suitable for certain people (e.g. too much hot is not good for babies) | Changes get incorrectly prioritised, opportunities missed making the software less valuable for certain stakeholders |
| We can change the water temperature by adding more water & we can let water out by pulling the plug | We can change the value by adding more new change requests & rewriting existing software (which wasn’t correct the first time). Team members leaving also fits in here for me (losing domain knowledge). |
OK - I’ll stop with the analogy for now. I’m hoping it’s resonating - I’d love to hear where it doesn’t!
That’s a wrap
To save duplication in this next section, this wrap up is all my own thoughts & opinions…
To conclude then, the programme I was on did not have the correct balance of inflow to satisfy the stakeholders values.
This is because as a programme we didn’t fully understand all the different stakeholders needs.
What was valuable for one stakeholder was not valuable for another (think builders vs managers mindsets).
This discrepancy didn’t surface until after a stakeholder had raised their red flag, at which point corrections to inflow were made to satisfy that particular stakeholder at the expense of another stakeholder.
To paraphrase Gilb - every project fails because a stakeholders needs have not been met. (I’m using needs & values interchangeably here)
WRT outflow, we had bugs, rework to previously delivered software & people leaving the programme, taking with them their valuable domain knowledge.
I’m thinking my next post should dig a little deeper into the interactions between stakeholders & their expectations using the “System Zoo” modelling example.
Thanks,
Duncs