By December 7, 2005 3 Comments Read More →

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.

Please check out my main blog page at www.leanblog.org

The RSS feed content you are reading is copyrighted by the author, Mark Graban.

, , , on the author’s copyright.


Thanks for reading! I’d love to hear your thoughts. Please scroll down to post a comment. Click here to receive posts via email.


Now Available – The updated, expanded, and revised 3rd Edition of Mark Graban’s Shingo Research Award-Winning Book Lean Hospitals: Improving Quality, Patient Safety, and Employee Engagement. You can buy the book today, including signed copies from the author.

Related Posts Plugin for WordPress, Blogger...
Please consider leaving a comment or sharing this post via social media.

Mark Graban's passion is creating a better, safer, more cost effective healthcare system for patients and better workplaces for all. Mark is a consultant, author, and speaker in the "Lean healthcare" methodology. He is author of the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, as well as The Executive Guide to Healthcare Kaizen. His most recent project is an eBook titled Practicing Lean that benefits the Louise H. Batz Patient Safety Foundation, where Mark is a board member. Mark is also the VP of Improvement & Innovation Services for the technology company KaiNexus.

Posted in: Blog

3 Comments on "Project Kaizen: "Workstream" Kaizen"

Trackback | Comments RSS Feed

  1. Nick says:

    hi, your atom feed fails validation checks, as such I’m unable to read it in newzcrawler.
    Check it on http://feedvalidator.org/check?url=http://kanban.blogspot.com/atom.xml

  2. Joe says:

    Very useful, Mark.

    This speaks to the extreme importance of handoffs in the workstream.

    In the first instance, the gatekeeper controlled them. And, by inference, slowed them.

    By choosing some standard way to share the bugs, your 2003 system smoothed the handoffs. And more throughput.

    Great illustration.

Post a Comment

CommentLuv badge