According to Wikipedia, kaizen is defined like so:

Japanese for “improvement” or “change for the best”, refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, business management or any process.

Generally speaking, this is used to talk about the continuous improvement of a product. It’s also a core idea of lean manufacturing that has also been adapted into lean software development.

Anyway, the idea isn’t anything new and I honestly think now, more than ever, more people are familiar with the idea (even if it isn’t practiced) than ever before especially because some applications use the word in the release notes for their application.

Kaizen in Paper By FiftyThree

Paper By FiftyThree mentions it with nearly every release.

As far as building products is concerned, this is something that I think many designers and developers want to do (if they aren’t already doing it, of course), but it are sometimes hindered by the nature of their environment.

By that, I mean that can we do continuous improvement – that is, can we practice kaizen – on projects that aren’t deployed on any type of particular schedule?

Kaizen and WordPress Product Development

To clarify, kaizen – at least in many lean software development shops – is often used in conjunction with the idea of continuous deployments or continuous integration.

This means that from the developer’s desk all the way to the deployment tooling, changes are being committed into source control, tested, and deployed to a staging environment as well as the production environment on a set schedule.

As such, designers and developers know that the code on which they’re working will be released at a certain time, should have a certain degree of quality, and shouldn’t be used/activated/deployed until the feature is fully complete.

But if we’re working with WordPress and we’re building plugins, themes, and other types of applications, how can we practice kaizen with our work when the idea of continuous deployment is not part of our normal process?


If your approach to kaizen also goes hand-in-hand with continuous integration, then plugins are actually a little bit easier than themes because the nature of their deployments is very similar to that of, well, continuous integration.

That is, if you’re using the WordPress Plugin Repository or the GitHub Updater, then you can work on updates, push them to their source code repository, and user’s will have them available as soon as WordPress performs its routine check for updates.

But there’s a problem with this: Prompting users to frequently update plugins does not yield a pleasant user experience. Even for those of us who are familiar with how the process works, it’s somewhat aggravating (and maybe even a bit concerning) when a plugin that we’re using releases numerous updates every other day or so.

I mean, it kind of screams bug patches or faulty releases even if that’s not the case, right?

So providing some type of continuous integration regarding plugins – even though WordPress supports it, to some degree – is not an ideal situation.


Themes are a different beast all together because there are a number of different ways users can use WordPress, and there are a number of different ways in which users can obtain their themes.

For example:

  • Users may use as their platform of choice, and thus theme rollouts are invisible to them. This also supports a form of continuous integration, but it’s not on a definitive schedule.
  • Users may have a self-hosted installation in which they have downloaded a theme from the free theme repository or purchased it from a third-party. If it’s the latter case, then they may not get updates in their dashboard (unless you company has built that functionality into their work), or the company may opt to no longer support or improve the theme thus leaving it to age.

Granted, this is just a very, very high-level survey of some of the options in the WordPress space, but it still lays out many of the typical options, but the question still remains.

Think of the App Store

To bring the conversation full circle, look at how applications do it in various app stores: They still practice kaizen by improving their product, but release versions of the application when they are ready.

This goes to show that the relationship between kaizen and continuous integration is complementary, not dependent. We can practice kaizen on our products without constantly deploying minor improvements to our customers.

But, for some, this still may raise the question of how we can do that?

My Approach

Personally, the best way that I’ve found to do this is to make sure that I’m doing a good job of setting milestones, creating issues, and creating tickets for my projects. I then allocate time to work on said project and try to complete however many tickets I can in that set amount of time.

This way, I’m continually improving the project, I’m making progress on it, and I’ll eventually clear a milestone and be ready to release the next version.

I mention this because, oftentimes, I think developers think that they need to allocate time to sit down and clear a certain number of tickets. The problem is that the list of tickets grows and the amount of available time doesn’t change, so it becomes a near-impossible situation to begin improving our work.

So rather than try to allocate time to solve as many tickets as possible, aim for one or two, and do this throughout a week. We’re still continually improving our work, and just like the apps in the various app stores, we’ll be able to release them as soon as they’re ready.

And, ideally, it’ll be quicker than if we waited until we had hours to plow through however many tickets are sitting in our queue.