Continuous Improvement: A Manager’s Guide of What to Avoid When Repairing Organisational Processes
I. To Improve or Not to Improve
Do you wake up every morning thinking: “What shall I be improving today?” The answer is for most of us: “Probably not”.
A. Sharpening the Saw
As we go about our busy lives, we have less and less time to ponder change, what Stephen Covey calls Sharpening the Saw in his famous book, The 7 Habits of Highly Effective People. The same applies to teams and, to some extent, the wider organisation.
In complex systems, improvement (or adaptation) is the only response to an external stimulus, which can be either a threat or an opportunity. Either way, some things have to be done differently if the system is to survive.
However, this lack of motivation to improve does not mean that improvement is not essential. In complex systems, improvement (or adaptation) is the only response to an external stimulus, which can be either a threat or an opportunity. If it’s a threat, it better be eliminated; if it’s an opportunity, it must be leveraged before the competition.
In some cases, improving (or not improving) today will only show much later. Consider technical debt in software development, for example, where indifference can be detrimental, and the longer you wait, the more difficult it is to reverse the consequences.
Organisations (including software) acknowledged the need for continuous improvement long ago, and various methods have been devised to make change possible at all levels. In addition to scale independence, decentralisation was key, affording employees genuine opportunities for innovation and initiative. Kaizen, a practice invented at Toyota and applied universally today, is probably the most famous of these methods.
B. Challenges of Continuous Improvement
Since organisations acknowledged the need for continuous improvement (which is synonymous with survival) and have already devised the methods (Kaizen, experimentation, retrospectives, etc.) to implement it, what prompts us to dedicate this article to discussing it? The reason is that continuous improvement is easier said than done, as is the case with any complex problem.
To keep the discussion focused, we will narrow it down to continuous improvement in software development teams, where challenges abound, as we shall see in a minute.
II. Continuous Improvement and the Challenge of Complexity
Can you find the motivation to fix a broken pipeline?
A. The DevOps Engineer’s Dilemma
Achilles is a DevOps Engineer at a large software organization. The organization’s demanding client base and fierce competition require uncompromising product quality afforded through cutting-edge technology and ultra-sophisticated development processes. Achilles’ organization created multiple teams and hundreds of developers worldwide to support this complex delivery system.
Although the DevOps model requires developers to be proficient in various aspects of the Software Development Lifecycle (SDLC), including development, testing and operations, the scale of Achilles’ enterprise and the growth imperative mandate specialisation. While Achilles is knowledgeable in most areas of the system, his role and responsibilities are narrowed down to maintaining the deployment pipeline.
Achilles is very resourceful, with plenty of experience in the field. This lets him stay on top of his responsibilities, accumulating praise from his multiple managers (Achilles is part of a matrix organisation). Recently, Achilles noticed an increased failure rate in one particular battery of test cases. While this did not represent an immediate danger to upcoming releases, it did slow down the process considerably. After some troubleshooting, he found that a simple restart would solve the problem whenever a failure occurred. However, this workaround seemed temporary, and Achilles thought something should be done about it.
B. Five Ways to Improve
On his way home, Achilles scribbled down the following notes as he pondered his options:
Raise it in the team’s retrospective.
Rationalisation: While not his team’s responsibility, raising awareness of a potential future problem is always good.
Pros: Once everybody knows about the issue, future responsibility for failure will be shared rather than resting solely on Achilles’ shoulders. Also, the team might devise some creative solution that has not occurred to him yet.
Cons: Achilles’ team might decide that this is not an immediate problem, that they do not have the power to do anything about it, and that further discussions of the problem are a waste of time, thus preventing Achilles from making further investigations or trying remedies.
Take it up with the testing team.
Rationalisation: The testing team owns this part of the application, and it is essential to convey the issue’s potential impact on future releases.
Pros: The testing team might agree that the breaking pipeline is severe enough to warrant investigation soon and attempt to fix it before it becomes an issue.
Cons: The testing team might disagree about the problem’s urgency and label Achilles a troublemaker if he insists on bringing it up.
C. Choosing the Best Option
Whichever option Achilles chooses will have an upside and a downside. There is no objective way to select the best option; choosing is now a matter of opinion. But Achilles is not frustrated. He understood quite a while ago that:
In the next few paragraphs, we will examine the three common methods that Achilles listed in his notebook, focusing mainly on those that can be implemented in his team (retrospectives, fixing, tweaking).
III. Retrospectives and Parkinson’s Law of Triviality
The recommended dose of monthly improvement
A. The Typical Agile Retro
The typical team retrospective goes something like this:
The approach sounds great, at least on paper; issues arise in practice. Not only is 10 minutes not enough to discuss anything of genuine importance, but team members are also reluctant to place serious topics on the agenda.
In fact, people seem to avoid genuine issues when participating in retrospectives for various reasons, the least of which is being accused of unnecessarily rocking the boat and focusing on the negative. Moreover, serious issues cannot be solved before sufficient data is gathered and analyzed and alternative solutions are offered, weighed, and debated. All this requires time and preparation, which are not inherently afforded during short retros.
An issue on which a team agrees is not really an issue but a missing step in some process.
Instead of focusing on genuine pain points, the team spends its retros discussing trivial or non-consequential matters such as the need to hire more resources, undergo more training, acquire an Agile mindset, break down the silos, and foster an organisational culture of so and so, which brings us to Parkinson’s Law of Triviality.
B. Parkinson’s Law of Triviality
Parkinson’s Law of Triviality, also known as the Bike Shed Effect, describes the phenomenon where a committee or team spends a disproportionate amount of time on trivial issues while neglecting more significant and complex ones. Cyril Northcote Parkinson introduced this concept in 1957 as part of his broader work on bureaucratic inefficiencies.
This tendency leads to meetings where less important issues receive undue attention while critical decisions are rushed or inadequately addressed.
IV. Incremental Improvement and Experimentation
What happens when developers are empowered to experiment with small changes, hoping that improvement will accrue over time? This approach also sounds great, at least in specific contexts. Let’s see when this continuous improvement method bears fruit and its limitations.
A. Theory or Practice: Which Comes First?
At school and university, we were taught that thought comes before action, theory before practice, and reflection before transformation. In fact, outside of intellectual exercises, it’s the opposite that is almost always true. Reflexes come before thought, experimentation and tinkering before rigorous and abstract concepts, and change before retrospection. To illustrate these ideas, let’s briefly examine the development of the steam engine and automobiles.
Except in specific cases (such as a narrow space within theoretical physics) where theory preceded practice, experimentation, adaptation, and repurposing of existing technologies were the driving forces behind innovation.
B. The Agile Method of Progress
Agile was created (or, more accurately, synthesized) from existing practices such as Scrum and eXtreme Programming, the latter heavily inspired by the Toyota Production System. It responded to the software development challenges posed at the time by rapidly advancing technology, an expanding market, and ever-larger projects.
The biggest challenge to successful project delivery resulted from the obsolete Waterfall practices, which could be outlined as 1) massive analysis efforts at the early stages, 2) prolonged development periods, and 3) exclusion of the customer from the design and implementation journey (see discussions on Agile and Waterfall for more details).
The first conceptual revolution by Agile practitioners was the explicit acknowledgment of uncertainty and change as enduring and influential factors in software projects. Software applications were to be delivered in smaller and more frequent releases, allowing feedback from the first users to be incorporated into the design.
This cycle—develop, release, monitor, iterate—allowed Agile practices to quell uncertainty and allow software applications to adapt to a constantly moving target. In a sense, the application was iteratively improved as soon as new information was available.
If Agile (and any other experimentation-based approach) works great under conditions of uncertainty, does it mean it will perform equally well under conditions of no uncertainty?
C. Is Agile/Experimentation Context-Independent?
Agile is not a universal answer to software development challenges. It only works in relatively small projects with high customer interactions and requirement volatility. Waterfall is more efficient and desirable if the business requirements can be articulated well in advance and users know exactly what they need.
The incremental improvement afforded by Agile techniques works best when we know our direction but not the exact route and where our ignorance of the exact route stems from the dynamic nature of the landscape in which we are travelling rather than our poor cartographic skills.
In plain words, we use Agile only when Waterfall fails. We experiment when we can’t engineer. We guess when we can’t predict. We use heuristics when we can’t forecast. We run safe-to-fail experiments when we can’t strategize.
V. Performance Plateaus
A. The Photographer’s Conundrum
A photographer travels to a beautiful city nested between mountains. To take the best shots, she climbs one of the surrounding mountains and waits until sunset (the best colours can be observed at sunrise or sunset). While ascending the mountain’s slopes, she imagines the perfect summit spot: a serene place with no crowds and a magnificent view of the city below. Every step upward takes her closer to her objective.
A few hours pass, and the perseverant photographer is finally at the top. To her dismay, there is no summit; the mountain’s top is almost flat and hilly, and multiple spots seem ideal for photos of the city below. Which one should she choose?
First, she picks a small hill on the left, where she sets up her tripod and snaps a few shots. A few minutes later, she looks to her right and spots a high rock formation towards the west, which seems like an ideal viewpoint. She grabs her equipment and races to the rocks before she loses more light.
Before long, the photographer realizes she has spent her entire time jumping from one hilltop to another, from one spot to another, from one ideal location to another, while slowly but surely, the golden sunset light faded away.
Once you are at the top, returns on investments in continuous improvement, no matter their size, will converge to zero.
B. Tinkering around Local Minima
Let’s continue with the photographer’s story to explore the similarities between mountaintops, local minima, and incremental improvements.
The rugged terrain and scattered hillocks at the mountaintop afford no further opportunities to improve a photographer’s viewpoint in absolute terms. For example, hillock A can be quiet but with a suboptimal view of the city, whereas hillock B boasts a gorgeous view but is perilously challenging to access.
At the top, moving from one position to another always entails a tradeoff between two or more equally desirable attributes.
The same phenomenon can be observed in machine learning, where a cost function is plotted against the model parameters. Varying the parameters produces a different cost, allowing a (smart) algorithm (such as gradient descent) to locate the combination of parameters providing the least value. In most real-world cases, there is no single minimum but several minima. The suboptimal minima are called local (compared to the global) minima.
If the cost function is complex enough, it will have many local minima, and locating the global minimum might become impractical as the algorithm continuously bounces back and forth between several local minima. The key is to recognize when to stop, i.e. when you have found a position that is good enough for all practical reasons. One way to do this is to detect stagnation, i.e. when the cost function hovers around a very low value but never goes below it.
C. Incremental Improvement in Mature Processes
Mature organizational processes, where the latest and most reliable practices, technologies, and concepts have been incorporated, are similar to our rugged mountaintop.
Every manager’s key challenge is recognising when incremental improvements cease to improve overall performance and where every process change becomes a tradeoff between productivity, quality, cost, or customer or employee satisfaction.
When performance plateaus, a radical change is needed for improvement, and changes of such magnitude require genuine motivation (mainly as a response to external pressure) to implement them.
VI. A Note on Continuous Improvement and Scale
Continuous improvement takes on a different nature depending on the scale at which it is applied. Therefore, we must be precise in the terms we use to describe it.
VII. Continuous Improvement Mistakes to Avoid
If retrospectives are ineffective, tinkering is highly dependent on the context, and performance plateaus are bound to be hit, what options do developers and managers have for continuous improvement?
We will approach this question slightly differently. In such cases, it is often easier to list what not to do than what to do, which we do next.
A. Avoid Saving on Peanuts
Consider the (fictional) story of an airline CEO who saves millions of dollars on his yearly budget by removing a single peanut from every passenger’s meal. The idea is that passengers won’t notice the missing peanut, but the small savings, accrued over thousands of passengers and hundreds of flights, would be substantial.
If this sounds like a smart idea, consider for a moment the millions saved versus the hundreds of millions spent on every other expense. Also, you can only remove the peanut once. If you keep removing items from the meal, you will have no meal, only dissatisfied customers. The peanuts will run out at some point.
Focusing your time and energy on improvements you can only pull off once signals a lack of ideas and resolve.
I say “resolve bankruptcy” because the hard problems are where sustainable, long-term, and ongoing savings can be made, but you need to have the resolution to tackle them.
B. Continuously Improve by Removing
Legend has it that Pheidippides, the Greek messenger participating in the battle of Marathon between the Persians and the Greeks (490 BC), witnessed a Persian vessel changing its course towards Athens as the battle was near a victorious end for the Greek army. Believing the Persians were rushing to Athens to claim a false victory, Pheidippides ran the entire distance to Athens without a break, discarding his weapons and (eventually) clothes to lose as much weight as possible.
Every time you add a step to your process or involve an additional stakeholder, you pick up more weight, eventually slowing you down by creating additional overhead and bottlenecks.
A great continuous improvement exercise involves identifying and reinforcing the value-generating steps while discarding non-value-generating activities. In manufacturing, the latter produces “waste.” Senior managers at Toyota consider waste elimination a key activity to achieving Operational Excellence.
C. Quantification of Continuous Improvement Efforts
We sometimes (erroneously) believe that monitoring activities closely by implementing performance metrics is enough to drive employees to improve their methods and find creative solutions for their problems. While that will work on those 20% who generate the most value, the rest will find creative ways to game the metrics.
Focus on distance to objectives rather than metrics in measuring improvement progress.
Metrics can be useful if they are set up so that gaming them is impractical or extremely difficult. Either way, ensure the team understands its mission and primary goals first and foremost. Every action or decision in the continuous improvement effort must be directed towards achieving those goals rather than enhancing a statistic on a dashboard. Interestingly, artificially hitting your KPIs is almost always detrimental to your goals.
D. Forget about Prepackaged Recipes
Prepackaged recipes imported from other organisations, cultures, or times will need tweaking (at a minimum) before they can be applied to your specific context. They can definitely be given a chance (if they make sense), but keeping them wastes time and opportunity if no demonstrable results are shown despite genuine efforts.
Ideally, you want a continuous improvement framework that emerges from your processes, practices, context, and organizational culture. What has worked for someone else will not necessarily work for you.
Equally important is the path you wish to take to implement a new working method. For example, moving from Agile to DevOps is probably a lot easier than moving from Waterfall to Agile as the distance between the former pair (in terms of philosophy, cultural gap, process maturity, tools used, and skills needed) is significantly shorter.
When you want to apply a new idea, you must first reflect on how radically different it is from what you currently do. This will give you an idea of the challenges and duration of the improvement exercise.
E. Obtain First-Hand Information
This recommendation sounds obvious at first. Why wouldn’t you use firsthand information to assess a situation? Well, firsthand information is hard to come by; it has to be collected by the managers themselves and requires extensive investment in time and effort.
Diagnosing a problem is hard if you are unsure of the facts. It is better to delegate the problem and its solution to those who know best, in which case accountability can be held.
Toyota managers were required to observe employees on the shop floor for extended periods of time, gathering firsthand information with their trained eyes. This practice was invented by Taiichi Ohno and is called Genchi Genbutsu. It allowed managers to gain a deep understanding of the work processes and identify opportunities for improvement, contributing to the continuous refinement of production methods and the overall quality of the vehicles.
F. Identify Windows of Opportunity
When you contemplate major changes for your team, consider your stakeholders (all of them) and their positions. Stakeholder attitudes towards a specific problem are similar to dynamic gravitational sources simultaneously shaping tidal strength. The resulting tidal waves will be strong if the sources are in sync. If they are not in sync, the tidal wave’s strength withers away due to interference.
Look for windows of opportunity where maximal support from your stakeholders can be expected before implementing changes.
G. Avoid Waiting for a Consensus
In the previous section, we discussed stakeholder management, a critical factor in successfully implementing any change. However, we can argue that, in the limit, anybody who works with you can be considered a stakeholder. Does that mean you must reach a consensus every time before any idea can be ripe for implementation? Ideally, yes, but in practice, this never happens. As mentioned earlier, any decision on which all agree is not really a decision but a missing step in a process. Only difficult decisions produce genuine change.
If you are thoroughly convinced that an idea is worth trying, it might be enough to have a small (but vocal and persistent) minority support it, provided that the remaining stakeholders are not entirely hostile to it.
Some of your stakeholders will care deeply about the intended change, especially when it directly impacts their work and projects. Other stakeholders might be lightly impacted, and while they might need to be informed, they do not necessarily need to be involved.
H. Continuous Improvement and Systems Thinking
Until managers take into account the systemic nature of their organisations, most of their efforts to improve their performance are doomed to failure.
— Russell Akoff
The best way to explain systems thinking and continuous improvement is through the following example. Let’s say you want to design the best application. Your architect of choice will start with a high-level design, get it approved by the stakeholders, and ensure that it satisfies all business requirements before proceeding with the details. The architect would never compromise the integrity of the architecture to fit within his design a great module, framework or library. Instead, he might be quite happy with a suboptimal component, provided that its inclusion will make the whole better.
Individually, you can form a collection of all the superstar components on the market. Integrating them together into one performing whole is another story.
An improvement in a local component does not necessarily lead to an overall improvement of the system. In fact, it might even be the opposite.
VIII. Summary and Conclusion
We hope that we have convinced the reader that, while continuous improvement is not impossible, it is hard to successfully implement without avoiding the (very common) mistakes often associated with it.
For the sake of space and the reader’s interest, we have also omitted discussing obvious matters, such as incorporating new technology and automating repetitive tasks. That does not mean that continuous improvement can progress without them. They are, however, obvious, and what we miss is often more influential than what we include.
IX. References
- The Toyota Way – 14 Management Principles From the World’s Greatest Manufacturer, by Jeffrey Liker, 2004
- The 7 Habits of Highly Effective People, by Stephen Covey, 2004
- Antifragile – Things That Gain from Disorder, by Nassim Taleb, 2012
- Skin in the Game, by Nassim Taleb, 2018