Project Kaizen: "Workstream" Kaizen

Today's topic for the Project Kaizen group blogging effort is kaizen for a “workstream.”

We'll look at making improvements across a subset of a value stream. This often crosses organizational boundaries.

————————
One workstream I've been a part of is the “bug fixing” process within a software company. There are multiple handoffs from:

1. Report bug (consultant or user in field)
2. Lead software engineer or QA team “triages” the bug and assigns it
3. Team gathers to review bugs and receive assignments
4. Software engineer works with reporter to understand bug and conditions in which it occurred
5. Software engineer fixes bug
6. Software engineer submits fix
7. Team reviews status of fix
8. Bug reporters reviews new software to confirm bug has been fixed

As you can see from that general workflow, there are multiple departments and workgroups involved – consultants, QA, and software engineering.

I've seen this process in different companies, actually. One was within a manufacturing company in the late 1990's. This process was managed primarily through one “gatekeeper” who ran the process and tracked information in a single spreadsheet. While this spreadsheet was available on a LAN for the team, all updates and information had to funnel through the single owner of the process. Much of the process was based upon face-to-face team meetings. This communication was inefficient because, for one, it batched up communication and delayed the process until the next meeting would occur. Secondly, an individual person might attend a two-hour meeting where only 10 minutes of the discussion was relevant to them, yet there was pressure to attend the full meeting.

When I saw this process, in a software company, in 2003, the company had some web-based “workflow management” software. It was an open-source (meaning free) application from Mozilla, the people who created the Netscape and Firefox web browsers.

This application helped remove time from the general bug fix process. Instead of waiting for a formal review meeting, communication could flow almost immediately. Certain types of bugs could be automatically routed to a particular software engineer without the delay of waiting for a meeting or process gatekeeper. The software tracked all communication in a single database, instead of relying on people to keep emails that could get lost or be tough to find later on. I'd say, in general, bugs were communicated and fixed much faster using that software. It's not that the 2003 team was more talented or worked harder than the 1999 manufacturing company team. Far from it. But, they had a better system and process that allowed them to work more effectively.

I think this lesson points back to the Toyota Way principle of “Use only reliable, thoroughly tested technology that serves your people and process.” In 2003, we didn't use software for the sake of technology. We used it because it improved our process. Using the open source software meant that there was continuous kaizen – when a user in another company found a bug, it was fixed and the software, because it was web-based, was improved for everybody at the same time. It points to the power of using standard tools that can be improved continuously, rather than creating a “proprietary” tool that might do the same job.

Check out the other group bloggers to see what they have to say on today's topic: Bill Waddell at Evolving Excellence, Chuck Frey at Innovation Weblog, Hal Macomber at Reforming Project Management, Joe Ely at Learning about Lean, Norman Bodek at the Kaikaku Blog ,and Jon Miller at Panta Rei.

What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.

Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation: