The meaning of Continuous Improvement
Continuous Improvement, CI for short, is of course something that most people who want to make a career strive for. Even people who don't have a promotion in mind see continuous improvement as something worth striving for, because after all, improvement can make work easier, more efficient, and thus lead to a more satisfying day at work. But who hangs the bar where and how high, and what can a manager even do in terms of further development in the agile world? We summarize below an article by Gerri Poling on this topic.
Further development on many levels
So what does Continuous Improvement mean in the context of development for leaders? Gerri Poling explored the question. Until some time ago, everyone was talking about raising the bar. "Raising the bar" was on everyone's lips. Hardly any business buzzword was so readily misunderstood. "Raising the bar" did not actually mean that the bar is constantly being raised from outside just on principle, but that there is someone who has the knowledge and experience to question common methods and can actually make the processes better. In doing so, he not only raises the bar, but also gives the entire team a boost. No one is left out and can no longer reach the bar. Everyone pulls together and improves.
What the "cool" do
Continuous Improvement should be viewed entirely in terms of the higher ups. No one within a company should simply settle for current performance and sit back. When Gerri Poling started at his last employer a few years ago, he was abruptly thrown into a world focused on business literature. Not only was literature encouraged, but it was fully relied upon, whether in organizing and planning or in running the business. There were efforts to adopt the Google SRE model and no-ops culture. All the utopias of modern IT were stated goals, because ultimately they wanted to do what the "cool" ones in the market were doing. Major investments were triggered and training for agile methods was conducted. Soon everyone had their DevOps titles, but something was still missing.
Standstill with DevOps?
DevOps methods make all teams accountable for their own work, including the quality of their products as well as delivery dates. Thanks to DevOps, no one is needed to check a team's work anymore, at least no one from outside the team. The same is true for security and compliance. But if quality and security, as well as accessibility, resilience, user-friendliness and other aspects, are not externally controlled and scrutinized, what else can drive a team to ever-higher performance? Gerri Poling's answer to this is: someone who raises the bar a little higher.
Let's put the question another way: Who doesn't want continuous improvement when it comes to safety? Who is still satisfied with "safe enough"? At least no one who wants to hold their own in the market. And of course, everyone wants continuous improvement in availability, quality and user-friendliness. Hardly anyone still works according to Google's concept of error budgets. Yes-or-no parameters were still useful when we could conclusively define requirements in advance. But in an agile world, where continuous improvement is part of everyday business, we need different approaches. We should always strive for improvement.
Minimize and improve at the same time
At the same time, we strive to avoid having to do as much work as possible. The architecture we use should be as simple as possible and only the strict minimum of features should be developed. Just as much as is needed. Developers are encouraged to stop working while the automated tests are running, although they often make some simplifications to the code after this point. Google's concept of error budgets should also be seen against this background. But how can the principle of minimizing steps be reconciled with Continuous Improvement?
A future that is full of improvements
Gerri Poling believed that the principle of the bar raiser, the one who hangs the scale higher, can be the answer here. He wonders what it would be like if independent quality assurance worked with quality bar raisers, but who were not also gatekeepers? Of course, it must not be, "Your quality is not adequate." It must be "We still see the possibility of improvement, of raising the bar, in this or any aspect, and we also have some ideas on how you might get more out of your project." Such an approach is also conceivable in the case of safety. So the result could be, "Yes, you meet the safety standards. But perhaps we should take a closer look together and possibly bring about a significant improvement with a few simple, quick actions."
Poling emphasizes at the end of his article that raising standards and benchmarks often comes at a cost, but often it doesn't. He believes that bar raisers are just the next step in the digital world to provide countless improvements in a very unobtrusive and gentle way.
Author: IAPM internal
Keywords: Continuous Improvement, Project Management, Agile Project Management, Tip