3 Reasons to Combine Processes

If you made it through (read: suffered through) the post I wrote about the Value of Value Stream Mapping, you saw the before and after Value Stream Maps where we reduced the number of steps to produce our product from 15 to 6. If you've got a "current state" Value Stream Map, what can you do with it? (If you don't have a VSM, what are you waiting for?) At Tanner Tees, one of the first ways we used our "current state" was to figure out which steps could be combined or even removed.

Batch and Queue Much?

When working on tasks, most people (myself included) have a tendency to "batch-and-queue" our tasks and processes. Another way of putting it: when we have multiple things that require multiple steps, we tend to do step 1 to all of the items, then move on to step 2, etc. This is a natural tendency, but combining or removing processes can have drastic impacts on speed and quality.

This may be an overly simplified example, but I caught myself doing that exact thing the other night when dicing 3 onions. I cut the ends off all the onions, then cut all onions down the middle, took the outer layers off all of them, and finally diced each half.

The book Lean Thinking by Womack and Jones, uses an example to illustrate the deception of batch-and-queue. This example has been cited so many times as to almost be cliché. But, if you haven't heard of it...one of the authors had to mail newsletters (yes, this was a long, long time ago when people mailed pieces of paper to other people) and asked his daughters to help. His daughters' natural inclination was to batch-and-queue every step of the process: fold all the newsletters (set to the side), stuff each one into an envelope (stack in a pile), seal all the envelopes (put in a box), affix stamps to each envelope, then attach the mailing labels.

A Better Way? Flow.

During the envelope story from above, the author made a suggestion to stop the batch-and-queue and to process each newsletter all the way through - without putting it down until it was completely ready to mail. The new process consisted of picking up one newsletter, folding it, putting it in the envelope, sealing the envelope, stamping it, attaching the mailing label, and putting it in the completed pile. Wash, rinse, repeat. Each completed newsletter went through the same exact steps as the batch and queue system.

If you haven't seen it or experienced it for yourself, can you guess which one is faster? The second way (flow) seems counter-intuitive and less efficient, right? You'll have to try it or watch one of the many YouTube videos that mimic this experiment to see that "flowing" the newsletter all the way through is much more efficient than batching it. At a high-level, this streamlined approach is referred to as "continuous flow", "one piece flow", or "single piece flow".

I get it. Hardly anyone mails newsletters. If they do, they're likely on a government watchlist. So, how's this applicable to me? There are a lot of tools and techniques to help achieve better process flow, but one of the more straight-forward techniques is to use your Value Stream Map to stop the batch-and-queue.

Combining Processes - A Manufacturing Example

At my current company, we build a subassembly before it can be used in the final product. When I first started working here, building that subassemtly required two separate steps. We would grab the primary part from a bin, add a part to it, and put it into bin #2 as a partially prepared subassembly. Once bin #2 was full, we would pick up each subassembly (again) and add three more small pieces to it. Then, we put it in a third bin for use in final assembly.

After we mapped out our value stream, we could see that these steps could easily be combined. So, that's what we did. We combined those discreet steps, which only eliminated a single pick-up/put-down cycle per part. That simple change:

• enabled one quality check on two parts of the subassembly at the same time
• increased the final speed to build the subassembly by 17%!
• nearly eliminated rejects of that part at the next process

Speed went up. Quality went up. If there was a bad batch of parts used to build the subassembly, we would catch it on the very first one instead of realizing it after we were done processing a couple hundred of them. Is that truly one piece flow? No. But baby-stepping into that concept paid dividends in time and quality.

Removing Processes - A Software Development Example

Some processes can be combined, while others that don't add real value can be dropped completely. One of my clients had four different software environments: Development, Testing, Staging, and Production. Developers would work on a user story in the Development environment, check in the code and, after passing code review, it was deployed to the Testing environment. Quality Assurance would test the code and, assuming everything passed, the code would be queued for deployment to the Staging environment. Planning the final deployments to production required careful coordination and testing in Staging. Once everything passed quality tests (again) in the Staging environment, the code was finally deployed to Production (and tested again). Exhausting. But, at the time, that was the process because it was "safe" and the accepted practice.

A new hire to the DevOps team took a look at the process and lobbied to completely remove the Staging environment. (Side note: we did. After it was decommissioned, the team celebrated with cake to commemorate its "passing" - complete with a frosting "RIP" tombstone). There is a whole other series of posts to talk about feature toggles and process discipline when removing a Staging environment to ensure high quality code in Production. (I may also get some, "hey! What about CI/CD?!!" Again...that's a series of separate posts). But the overall outcome of removing the Staging environment was:

• an increase in speed to deliver value to the users (fewer active user stories waiting for deployment and quicker deployment cycles)
• elimination of testing a user story multiple times before final deployment
• thousands of dollars in savings due to removing a database server, its licensing, web server, hosting fees, etc.

Reasons to Combine - and if possible - Drop Processes

1. Increase speed
2. Catch quality issues sooner
3. Reduce work in process (WIP)
   • Manufacturing = less floor space & more efficient material use
   • Software development = fewer active user stories on the boards, quicker value to the customer/user

There's a lot more involved in achieving one piece flow than simply combining or removing processes. Using your Value Stream Map helps you examine processes creatively so you can see if there are any that can be combined or dropped. It's a great first step that produces quick wins and gets the ball rolling for larger changes and improvements.

Main photo by NEW DATA SERVICES on Unsplash