This is my example of continuous improvement. At least a start. It is far from perfect, but I would like to think it is a step in the right direction.

I currently do on call as part of my job. Every 4 weeks, we spend a week taking the support phone, doing the daily health checks and fixing up any issues that come up. When I do these health checks, most of the time we are fixing symptoms of problems – not the actual root cause of the problems themselves. There just isn’t enough time to investigate the root cause and fix for everything. I think most people are in the same situation in an Enterprise environment You have legacy systems that have lots of problems and sometimes it feels overwhelming to fix everything. During this support period – I try to pick one thing, one problem, one pain point and try to make it go away.

For example, we had another part of the business regularly request data from us (I work on the integration/middleware side) for messages that were sent outside the business (B2B). That part of the business would then modify those messages to correct data and have us resend. I got sick of this, so I wrote an app that allowed the business to do it them-self. It took about 2 weeks to do the first part, allow them to send the messages when they were ready, then another week to allow them to retrieve the data. That’s 2 weeks while doing my normal job as well. I just “stole” an hour here and there to work on this.
The UI is ugly as, but it allowed the area of the business to rapidly turn around issues rather than wait 2 days for us to get around to getting their data. It also alleviated a burden from the team.

Its quite simple, if you have a manual task that you do on a regular basis, script it to do it automatically. If you have an error that occurs regularly, find its root cause and fix it. You don’t have to do everything all at once.  Schedule an hour or two every couple of days – pretend you are going to a meeting if you cannot make your work visible (because it is frowned upon).  Its not ideal, but sometimes you have to “hide” work in a non understanding environment. The best way though is to make the work visible – you never know if another team member is doing the same thing.
We don’t do Sprints – so our support schedule becomes my unofficial cycle time. The preference is to do this more frequently. If you do sprints – pick something – anything per sprint. If you don’t do sprints, start off by doing something once per month (that is per person), then increase to once per fortnight, once per week, then always have something going on in the background that you work on at least once per day. Even for just 15 min minimum. If a piece of work that would take you  few hours actually takes a few days because you have to balance other work – so be it. Think small – you don’t have to spend months, just do what you can do now. Find a small solution to make it just a little better. Look for ways to build small capabilities, then link those capabilities to make giant leaps. Modularise and componentise.
Look at standardizing processes. Start by doing things manually to work out the steps, then automate. Sometime standardisation just means improving your documentation so that other people in the team can read it. Sometimes it is making sure that everyone shares knowledge.

Slowly, over time, things will get better – especially if everyone in the team/company does it.

This is part of Scrum.
This is part of Lean

This is in my opinion one of the foundations of an Agile Mindset. Learning to see where problems are, learning ways to expose problems and then learning to fix those problems.  Not looking at ways to avoid or hide problems. Hiding and avoiding problems just means you are building Technical Debt that will bite you some time in the future. Most likely at the most inconvenient time.

Also, always keep quality at the forefront. Even if quality dips – and it will, don’t just accept it. Look at ways to improve it. Look at ways to keep quality but speed things up through removing unnecessary work, or automation.

There are cycles in the way we work and live, even if you don’t do Agile. Agile just accelerates those cycles trying to make them smaller and smaller. Use those cycles for learning. Use those cycles for improving.