Kaizen Schmaizen - The Kaizen methodology at Aliz

More secrets behind the application with five million users

Our brand new blogpost is about the well-known Kaizen methodology and what we use in our business!

When I was interviewing for this job at Aliz, I was asked if I had any questions. I went with: “So, do you guys do CI/CD?” All the other companies I interviewed with had replied with an enthusiastic yes, sure, absolutely; they had the best CI/CD ever. At Aliz, my interviewers laughed, somewhat self-consciously: “Well, we have a Jenkins,” Gábor replied. “It works, yeah, but it’s got some problems. It’s not in very good shape.” I asked some more questions, and invariably they laughed and told me how the process or tool I’d asked about was there, sure, but it had some problems they’d be quite eager to fix, but hadn’t gotten around to it yet.

This was charming. The honesty of it, maybe. The professionalism of admitting that things weren’t perfect appealed to me. I signed with Aliz.

I’m Hungarian. Our traditional way of handling problems, difficulties, and suboptimal processes is that we sit down, complain, and do nothing about them. In fairness, it’s not just the Hungarian way. It’s pretty much a human trait that we tend to just live with whatever’s bad, because that’s the easiest thing to do: to change nothing and complain. Someone once told me there are three ways you can go about a situation you hate: accept it, step out of it, or change it. But anything is better than sitting around complaining. Still, sitting around complaining is the easiest option, isn’t it?

At the workplace, organizational inertia works against the desire for change. Even if we have a process that clearly doesn’t work anymore, we continue to practice it because it’s always been done that way. And we sit around and complain. Blame it on the management or something. And that’s toxic, man! I also believed that changing things for the better would take a lot of guts and determination. Heroism even.

Recently, I’ve realized it doesn’t have to be like that.

I signed with Aliz, and I met the ailing Jenkins. It did have problems. Instances would get stuck while building the project; you had to manually kill the instance and restart the build. I accepted it as it was. Occasionally I complained. But I did nothing about it. It’s always been like this.

Then one day someone with the expertise got around to fixing it. The team was happy, sure, but there was no great celebration as I’d have expected.

Slowly but surely I realized that fixing things and making things better is at the core of our team’s culture.

We’re pretty much doing kaizen, except it’s so deeply ingrained by now that we aren’t even aware of it. Kaizen? Well, look it up. I can’t explain it to you; I can only tell you what we’re doing.

• We ditch or change ceremonies if they aren’t working. One day, Gábor called me up and asked me about the value of a ceremony we’d had. I told him my opinion (that it was quite worthless as it was), and he said, nonchalantly: “I think so, too. Let’s stop doing it.” And I was all “Hold on, we can just do that?” Just like that? It was liberating and exhilarating.
• We step out of processes when needed. It may generally be a pretty good process, but there may come a moment when it becomes a burden. Take code review. It works, but I remember a set of urgent hotfix issues, when there was just no time for a review. We let it go, and reverted to a mob programming of three, which satisfied the four-eyes principle required by regulations and common sense, but also got the code shipped way faster.
• We implement new processes on demand, and in small increments. While there’s a vision of what direction we’d like the team to go, we generally prefer working toward it in small increments, as the need arises.
• Everybody can propose change, and change is accepted by consensus. Okay, change does tend to come from the more senior team members, the architects. Their arguments often carry more weight during discussions. But hey, they’re architects exactly because they have the experience and the vision.
• We encourage fixing minor, only tangentially related problems as part of a business issue. When writing new code, we spruce up files we touch even if it’s not needed for the core issue, modernizing little bits (like replacing an old anonymous object with a lambda), doing minor refactoring, or adding documentation. We also like to add new, generally useful testing and utility methods. It’s nice to leave the place tidier than when you entered, and it helps hugely to pay off that technical debt.
• We don’t accept industry best practices blindly. Okay, this is sort of controversial. We reject industry best practices so eagerly it freaks me out. But it’s because we seek proof of the worth of these practices. We do have team members to advocate for the best practices, though, curbing our worst excesses.
• We encourage experimentation when writing code, and we accept failure in experimentation. Experimentation is costly, even if it’s successful. Its benefits are not immediate and often difficult to measure. Keeping it incremental helps, as does being transparent about it. As I experiment with new things, I like to communicate what I’m doing for continuous feedback.

Okay, maybe it’s not kaizen, not really. Maybe it’s just that we’re actually agile, in the classical sense. But what’s in a name? We’re striving to continuously improve, and we respond to change rather well. That’s all there is to it.

As you can see, this way of thinking appears on many levels: in everyday coding and in architectural and organizational thinking as well. And I’m convinced that the AODocs project is as successful as it is because of this mindset. I mean, our team is working on AODocs, a huge system with a ten-year-old codebase, but that codebase doesn’t look or feel ten years old, because we all keep modernizing and renewing it, innovating constantly.

We’re also pretty good at organically creating a unified coding style by consensus. We have a team that pretty much drives itself, even if it loses a central figure to vacation or sickness. It all sort of works by itself, and it’s magnificent to see that.

That’s not to say we’re the perfect team. We’re still trying to work out how to effectively mentor our juniors.We still don’t have the planning phase for issues down: we often have to rework the code after code review, and that’s hardly optimal. I’m also concerned about our “not-invented-here” tendencies. And our release process could use some work.

CI/CD? Well… We have a Jenkins, of course. And it’s in much better shape than it was.