Treacherous bottlenecks can nullify all your hard work, no matter how industrious you are.
So, have you ever wondered where “bottleneck” term comes from? Let’s try to understand it a bit better.
Imagine you have a bottle of water and your goal is to empty it as quick as possible.
Scenario 1: You overturn it, the water runs out by itself, and it’s done.
However, you realise that the bottle neck (literally the narrower part of the bottle) limits the flow speed of the water.
It makes you wonder…
Scenario 2: So you decide to get another bottle of water. Identical. You overturn it, but this time you give the bottle a few turns to generate a vortex. The waters run out almost two times faster than the previous bottle.
Why? Because, in the second scenario, you created a vortex which allows the air in so the water can run out through a circling motion. You let the water and the air have their own separate paths to achieve an uninterrupted and continuous flow. A better flow.
What is going on here? You are basically improving the flow of the constraint (the bottleneck). You are emptying the bottle with a better lead time by optimising the whole.
Takeaway: If you want to improve the whole system, first, you need to identify and improve the systemic constraints (any limiting factors) that stand in the way of achieving your goal. Otherwise, any improvement initiative will result in a local optimisation that does not provide significant benefits.
In software development context, it doesn’t work differently.
Although it can be argued that figuring out the systemic constraints is not that straightforward, it actually works in a similar way in software development context.
Imagine you have a team that works on a specific feature. Their technical excellence is top-notch, they use the most advanced tools, they have a great team identity. They are capable to build DONE increment in short cycles. However, the organisation has a policy that allows the team release their increment only after a painful process that is governed by external approvers and only as a part of a monolith code base in sync with other teams, on a specific date.
Do they get any benefit from having a high performing team, as long as there’s a constraint in the process that prevents them from getting an early feedback from the users/stakeholders?
Does the organisation use the potential of this team?
What does this delayed releasing do to team morale?
Does that process help anyone or does it just sub-optimise the whole?
Let’s make it clear, it does not necessarily mean the team would not consult anyone outside of the team to deploy their code to the target environment. There might be intentional ‘organisational conventions’ to comply with some legal requirements, or due to nature of the business.
Basically, there may be a context behind this scenario. That’s more about being able to ask: “Is this process leading to a systemic constraint? Can we improve it?”.
Now, there are two dimensions.
- Do you think the culture of the organisation allows people to ask these questions without feeling uncomfortable?
- Are the employees professional and courageous enough to speak truth to power?
My two cents, it’s never only one of these, both are important. Top-down and bottom-up.
5 frequently encountered systemic constraints.
In the last 10 years, I worked in different industries including e-commerce, fintech, advertising and real-estate. Regardless of the field, I observed a pattern around the frequently encountered systemic constraints.
Although these constraints are mostly fluid and interconnected, I can mention 5 categories and some powerful questions under each to initiate useful conversations.
Constraint 1: Heroic Management & Leadership Approach
- Are the people with politic influence (leaders, managers, or whatever you want to call them) acknowledged as heroic experts or as servant leaders who encourage survivable experiments?
- Is the manager role defined by the head-counts reporting to them or by their capability to create space for the growth of their people and teams?
- What kind of policies are in place to incentivise servant leadership?
- Do the managers do Gemba Walk? Or are they astronaut managers who operate outside the atmosphere and can’t see what’s really happening on the ground ?
About Gemba Walk:
‘Don’t look with your eyes, look with your feet… people who only look at the numbers are the worst of all.’
Taiichi Ohno — The father of the Toyota Production System
Constraint 2: Fortune-telling Driven Development & Budgeting
- Do the people know the difference between ‘forecast’ and ‘commitment’?
- Who decides ‘how much can be done’ in a specific time-line? Is it the people who do the work or someone else?
- Do you operate with long-term budgets? Does it create a pressure to trade off talent quality with speed in hiring to make you look scale quick?
- Does your Product Owner/Manager know how much a release costs?
Constraint 3: Ambiguous Product Definition & Measuring What Doesn’t Matter
- Are you a project or product company? Do you define success inside-out or outside-in?
The Professional Product Owner By Don McGreal and Ralph Jocham
Even if you are a B2B company, delivering on time, budget, scope does not necessarily mean you deliver something that will make your client happy. These are circumstantial metrics and you will find more value in identifying better indicators that address outcomes rather than outputs.
- Have you defined ‘what value means’ in your context? Have you determined what your leading & lagging indicators are, in conjunction with the people who set the direction and the people delivering the value?
Some resources I’ve found helpful for perspectives in different levels and needs: The 2019 Accelerate State of DevOps, Evidence Based Management , Actionable Agile Metrics for Predictability
- If you hand out a pen and a paper to random people in your company, can they write the same thing about what your product (or service) is and why your customers use it? Not only business people. Everyone.
- How broad do you define your product? How do you create the right balance between cognitive capacity overload and broader learning opportunities?
- Do you have someone ultimately accountable to maximise the value of the product? If multiple teams are working on one product, do you have THE product backlog that is ordered by this person?
Constraint 4: Lack of Shared Understanding around DoD
- When you mark something as DONE, can you immediately release it or is there a delta?
https://less.works/less/framework/definition-of-done.html#UndoneWork-RiskandDelay
- How does this UNDONE work impact the teams in terms of planning capability and context switching? Do they often complain about allocating capacity for the bugs coming from an environment beyond their Definition of Done?
- Do you do anything to shift left and close this gap?
Constraint 5: Teams Structure (managing dependencies over eliminating dependencies)
- Is the current structure allowing the teams to own end-to-end flow of the feature/service/stream they are responsible for?
- Do the teams complain about spending too much time to manage the dependencies they have with other teams?
- Does the team have enough space to focus more on quality, innovation and to improve technical excellence?
Team Topologies introduces “Enabling Team” concept to close the aforementioned gap and support stream-aligned teams through technical consultancy.
These “enabling teams” actively avoid becoming “ivory towers” of knowledge that dictate technical choices for other teams to follow. They operate with servant leadership approach.
Conclusion
All in all, any progress other than in the bottleneck is an illusion. It is vital to discover and be aware of your systematic constraints that impede the flow.
There is no silver bullet. There is no one size fits all. Nonetheless, In my experience, if you can achieve an organisational mind-shift as below, you will improve the 5 aforementioned constraints.
- Servant Leadership over Heroic Leadership
- More Adaptive Planning over Big Budget Up-Front
- Product Mindset over Project Mindset (Outcomes over Outputs)
- Delivering a Small DONE Increment Earlier over Delivering Everything Later
- Eliminating Team Dependencies over Teams Managing Dependencies
As a final point, one should not forget that the organisational structure can also have an influence both on the company culture and the design of the software created (Demystifying Conway’s Law).
Thanks for reading. If you want to share your own perspective and experience, please do not hesitate to leave a comment. You can also contact me via sahin@vaxmo.co.uk. I always fancy a chat over a virtual coffee!
Special thanks to Maarten Dalmijn & David Pereira for their contribution to this article.