The term "continuous improvement" (CI) has become something of a catchphrase in the software industry. Pretty much every organization says it practices CI, but in reality, very few companies take full advantage of it.
The concept of continuous improvement (or “kaizen”) was developed in the mid-twentieth century in Japan, where it was largely responsible for the miraculous Japanese industrial and economic post-war boom.
Some of the tenets of kaizen are:
If there’s a problem, fix it before it festers. If anyone in the organization notices a manufacturing defect, they immediately pull the “rip cord,” which stops the assembly line. Everyone immediately gathers, figures out the problem, and fixes it before the line starts up again.
Root cause analysis. When there is a problem, try asking “the five whys” in order to get to the root cause.
Great ideas can come from anyone. Employees at all levels should feel free to speak their minds. If they don’t feel comfortable speaking up in front of senior management, then consider breaking into small groups.
The general idea of continuous improvement is that you can always find ways to make your products, processes, and people better. It's about constantly learning from feedback, data, and experiments, and making small but impactful changes that add up over time. It’s about empowering people at all levels of the organization. Most importantly, it’s about listening to your customers and other stakeholders.
Software development is a complex and dynamic process with many unknowns and hurdles. Requirements change, technologies evolve, markets shift, and customers demand more. Software companies must be nimble and adaptable in order to survive and prosper in this climate.
Continuous improvement assists software firms in accomplishing this by allowing them to:
Deliver better products that meet customer needs and expectations
Reduce waste and inefficiencies in their processes and workflows
Increase productivity and quality of their teams and individuals
Foster a culture of learning and collaboration among their employees
Gain a competitive edge and grow their business
We like to think that we do. About 5 years ago, we launched a product called Ella Learning, a new kind of Learning Management System (like Canvas, Schoology, and Google Classroom) designed to help students develop better study habits to achieve more in school and in life. This is a passion project for us. It's what we want to be known for and remembered for after we’re gone. It's our opportunity to take all the skills we’ve learned over the years and apply them towards doing something good for the world.
However, it has been far from straightforward. We’ve had an almost perfect storm of challenges, including COVID, internal personnel changes, and financial constraints. Furthermore, the first version of the software we released proved too challenging for teachers and students. We made some overly ambitious assumptions about our customers that turned out to be incorrect.
Fortunately, we used that time to develop a culture of Continuous Improvement. For example:
We tightened our Agile-based development process and incorporated the voice of the customer. This seems like common sense, but, in fact, it’s a subtle difference from what we were doing before. Originally, we asked customers what they wanted in focus groups and surveys, and then we built our product based on what we thought they had asked for. However, we discovered that this feedback loop was too slow. In response, we moved to a truly Agile approach in which we release new features every 2-3 weeks and ask for customer feedback at the end of each development sprint.
We embrace lean principles for our product development process. We followed the build-measure-learn cycle, which helped us validate our assumptions, test our hypotheses, and learn from our experiments. This helps us clearly define what features our customers and users really want. Instead of "copying" existing features from similar software, we focus on developing features that are genuinely useful to users. We are willing to remove or hide features that are not really useful. As a result, we save significant time and costs in software development, and our products become leaner and easier to use.
To do the above and maintain it for the future, we established a culture of open feedback and constructive criticism at all levels of the company. Everyone is encouraged to share their ideas, opinions, and suggestions. We look for this personality trait when hiring, and we nurture it in our everyday work. It is considered an honor when someone at the “worker bee” level can talk our executives, or even the client, out of a bad idea.
We also create opportunities for learning and growth, such as training sessions, workshops, and retrospectives. Since our product is education-based, we bring in former educators and ed-tech professionals to speak to the entire team, educating them about how secondary education works and the challenges it faces.
Perhaps most importantly, we set measurable goals and make sure everyone on the team knows what the goals are and keeps them in mind when making decisions. For example, Ella’s goal, for now, is to increase the homework turn-in rate. Customer research shows that improving this area attracts teachers, parents, and administrators to license our product. When prioritizing features or efforts, we focus on what's most likely to enhance our measurable goal.
As I mentioned before, I’m sure this seems like common sense to most readers. Every organization probably thinks it does most, if not all, of the Continuous Improvement activities I just mentioned. I can assure you, however, that this is not the case. I’ve worked for and with several major corporations in my career, and in the vast majority of cases, the company culture actually discourages CI. How many Fortune 500 companies do you think would encourage an entry-level engineer to try to talk the CEO out of making a bad decision?
Please understand that we're not trying to boast or self-promote with this article. We are far from perfect and have faced our share of challenges. It took us more than three years to develop a product that ideally could have been completed in half that time. Our aim here is solely to share the lessons we've learned from tackling these obstacles, with the hope that it can provide you with a competitive edge and a smoother journey.
Embracing continuous improvement has been a game-changer for us. I encourage other business owners and leaders to adopt this mindset and see how it positively impacts their results.
Let's commit to never settling for "good enough" and strive for excellence in all we do!
In a no-risk discovery we look at how your work moves between your systems today and show what one connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
How to Build Sales Workflow Automation with Zoho CRM Workflow Rules (article)
Zoho CRM Web to Lead vs API: Which Lead Capture Should You Build? (article)
Progressive Web Apps vs Native: An Honest Build Decision (article)
Begin with a regular retrospective that produces one or two concrete changes each time, with an owner and a date. Track whether those changes happened. Make it safe to raise problems by responding to the issue rather than the person who raised it. Small, kept commitments build the habit faster than a large program, and the team sees improvement without waiting for a mandate.
Shortening the deployment process after a painful release, adding an automated test for every bug that reaches production, rewriting the onboarding guide after a new hire struggles, and changing how customer feedback is gathered when a feature misses the mark. Each is small, driven by a real problem, and measured by whether the problem recurs in the following months.
Continuous integration and continuous delivery are engineering practices for merging and releasing code frequently. Continuous improvement is a cultural practice of regularly examining how the team works and changing it. The engineering practices are often outcomes of improvement work, but a team can run a fast pipeline and still never reflect on process, and the reverse is also true.
A root cause method where you state a problem and ask why it happened, then ask why again of each answer, usually about five times, until you reach a cause that can actually be changed. It stops teams from fixing symptoms. A missed deadline might trace back through late requirements to the absence of a review step, which is the thing worth fixing.
Count improvements proposed and completed per month, measure the time it takes a raised problem to be addressed, and track whether known issues recur. Pair those with outcome measures such as defect rate, cycle time and customer satisfaction. A healthy culture shows a steady stream of small changes and a shrinking list of repeated problems over the year.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
