I think of the Savings vs. Investing argument when I think of why Continuous Improvement is a necessity and not a "nice-to-have." If you sock away $500 in a savings account, there is zero risk of loss, but, in reality, inflation is causing you to lose money. Your savings need to grow at a certain rate to be able to keep up with inflation. The same analogy could be applied to your technology organization. It needs to constantly innovate, research and implement new tools and streamline processes to keep up with the demands of the company as well as improve visibility to stakeholders.
Sometimes, the returns on investing in a new tool or changing a certain IT process are not readily visible or may not translate into immediate business value. However, recognizing the need to continuously improve and creating a business case is an important first step in the journey. Getting started and establishing processes to constantly evaluate and improve your technology will require upfront costs and time depending on the maturity of an organization’s processes and tools. Over time, this practice reduces technology debt and positions your technology to be scalable and secure to meet the ever changing demands of the business.
How does a team get started with Continuous Improvement?
Analytics: Gathering the right data can allow teams to strategically target areas that can provide significant impact. Tracking outages, performing a root-cause analysis and figuring out Mean Time to Repair (MTTR) for application outages is a great way to get started. Capturing those baselines and creating a plan to improve them is a key component on your continuous improvement journey. Reporting key data that are of interest to senior leadership should be part of this process. It’s a great way to continually get buy-in on further funding if you can prove that improving those metrics contributes to the company’s bottom line through reduced downtime, higher scalability etc.
Team improvement: If your team follows a relatively short sprint cycle, performing a retrospective at the end of each sprint can help improve team processes, morale and project management. Simply keeping track of what worked, what didn’t and what can be improved is sufficient to get started. Analytics can play an important role here as well. Collectively improving on key metrics gets the team committed to building great software and increases engagement.
Closing the loop: Taking steps to make sure there is an easily traceable path ensures all stakeholders are notified of any issues.
If an application does not perform well in production, the load testing strategy needs to be altered in a lower environment to replicate the same scenario and address the bottlenecks.
For every defect found in production, it not only needs to be fixed and tested, but also needs a root-cause analysis on whether there was sufficient test coverage for that functionality.
If incompatible versions of a particular package or changes to an environment configuration caused an issue, those configuration changes should be addressed in all environments (This is always easier if your infrastructure is code).
Everything in moderation: Remember, not everything needs to be improved. Some processes may need to be overhauled or even eliminated. Only the necessary data needs to be tracked. And lastly, Continuous Improvement is not a ‘one size fits all’ model.
Culture: All the above closely ties to culture. Fostering a culture where teams collaborate and work together to solve issues (instead of working in silos), allows them to develop a sense of shared responsibility and ownership. Everyone should be encouraged to constantly evaluate their applications lifecycle and look for ways to automate and reduce waste. Continuous Improvement, much like DevOps, is not a definable goal but a constantly evolving and “improving” practice.