kaizen, agile, scrum
I started my career as an IT Project Manager at GE Aviation (called Aircraft Engines at the time) in Cincinnati, Ohio. I was thrilled to land such a great job straight out of college, and started in one of their famous leadership programs. Despite this sounding obvious now, GE did an exceptional job at preparing me for my career ahead in ways I’ve only recently come to really appreciate.
A key part of my job at GE was to be a technology partner to various business organizations in the company. I spent time with Sales & Marketing, Services, Engineering, and the Technology Services Group—what I liked to call IT for IT. Our business partners walked us through their incredibly complicated jobs, and we would work with them to identify and implement improvements to the way they worked. It wasn’t always quite problem-first—I didn’t know!—but it was startlingly similar to product management nonetheless.
Learning from the greats
Kaizen
Over the years, well before I arrived, GE spent a lot of time studying Toyota’s methods of operating. If you’ve never heard about Toyota’s famed Kaizen method, you should really spend some time and read up on it. Literally, just google “Toyota kaizen” and a veritable shit-ton of information will pop up. Kaizen simply means continuous improvement.
GE (and, specifically, one-time CEO Jack Welch) saw the incredible benefits Toyota reaped from Kaizen, and folded its concepts inextricably into GE’s cultural fabric. You cannot work at GE without hearing about Kaizen and Lean, just as you cannot work in tech without hearing about disruption. (Oddly, one concept is much more valuable than the other.)
Seeing is believing
I was lucky enough to have an opportunity to tour a Toyota manufacturing floor in Kentucky not once, but twice with other GE employees. It was absolutely fascinating—I loved being on the floor and seeing both the results of Kaizen, and the actual in-process practice of Kaizen. Factory employees are empowered to identify things that are making their job more difficult and be a part of their solutions. I distinctly remember watching a literal robot that carried tools to workers, using a magnet to follow a metal line etched through the floor. That started with the workers. That was Kaizen.
Lean before digitize
While its applications to a manufacturing floor are fairly obvious, I did not work on the floor next to the enormous jet engines. But GE had figured out how to weave the concept into its technology organizations as well.
Lean before digitize
As technology partners, we were often engaged to take a complicated, manual process and build (or buy) a tool to enforce and track that process. As any IT employee knows, we were often challenged to do more with less every year with every new budget. It was therefore our job to eliminate as much waste as possible from our projects. The number one way to eliminate waste? Remove waste from a manual process before building a digital tool to codify it.
Tame that process
I watched a lot of leaders, Six Sigma Blackbelts, and Master Blackbelts facilitate process mapping sessions. They asked critical questions, like… is this approval step necessary? What’s the goal of step x? If we’re gathering that data, what are we doing with it? And, over time, I got pretty good at doing the same. I’d be met with a process, and I’d tear it apart and rebuild it to be the leanest form of itself that still met the business needs.
Get to the point, Erin
I digress. This is not about my ability to tear apart and rebuild a process anew (although I find that stupidly fun). Rather, it’s about learning from old concepts and integrating them into the way we work in this age of technology.
Agile, Scrum, and Kaizen
We, the people of Tech, are enamored with buzzwords like Agile and Scrum. And yet, we fail to see the direct parallels to industries who have been using Kaizen and Lean for decades. Agile is to continuous delivery what Kaizen is to continuous improvement. And Scrum is the join table that binds them together.
Ehh? ehh? I mean… it made sense to me…
Scrum has been widely adopted in software engineering organizations as the process for building products, though ironically it’s often used alongside waterfall methods of product delivery, rather than Agile. Often, though, I walk into organizations that know little about Scrum beyond stand ups, or are worried about adding “too much” process.
Process is not the enemy
But process itself is not the enemy. Stagnant processes—processes that aren’t continuously improving over time—are. Scrum does not prescribe a specific process, rather it gives you the scaffolding of a starting template and the tools to tailor it to your organization.
Just as Toyota empowers its people to call out inefficiencies and solve them, we should be empowering our product engineering teams to do the exact same thing. Are we having a meeting weekly that adds no value? Speak up! Let’s figure out what the original purpose was, and then determine whether it’s still needed. Scrum is just as much about reducing process as it is about adding it.
Designing a process
Let’s say you get it, and your team is ready to embrace process! Where to begin? Well, luckily, process improvement is remarkably similar to product management. Start with some basic questions:
What problem is this process (or step) trying to solve?
Who is the audience?
What’s the current user experience?
What are the unintended consequences of the current process / step?
What are our constraints?
What are possible solutions to the problem this process / step is trying to solve?
Which is the best solution for the problem and user experience?
We’re constantly improving our products, and we should be constantly improving our processes. We have the skills, our people have the drive—they just need the freedom.
Unleash continuous improvement. Embrace Kaizen.
