Lean 6 Sigma in the context of software development
Is Lean 6 Sigma the training my team needs to take next?
There are many frameworks and publications relating to efficiency and process improvement, how do you know which one is right for you or your team? I recently did Lean 6 Sigma training, so I thought I’d share my thoughts on it’s usefulness in the context of a SaaS businesses for those who are pondering if Lean 6 Sigma is the best choice for their organization or department.
Lean 6 Sigma is a combination of Lean practices and 6 Sigma practices, inspired by Toyota and Motorola’s process improvement methodologies respectively. These methodologies have been iterated in a manufacturing industry context over the past several decades, so while they focus very much on the manufacturing “production line”, the ideas still have applicability to other industries, as evidenced by the proliferation of Lean-Agile.
Specifically for software development, I think the tenets of lean may apply more than 6 sigma. Lean teaches how to align activities to customer value, frame problems, and overlaps really well with agile. So if you’re passionate about lean-agile then a deep dive into lean and progressing through the Lean 6 Sigma belt structure may be of value.
6 Sigma focuses very much on measuring variation from the mean for repeatable processes where the inputs and outputs are expected to be the same each time. In the context of software development and SaaS operations, 6 sigma’s methodologies are too precise and mathematical for most use cases. Software and systems engineering is primarily knowledge work with many unknowns. It isn’t repeatable enough outside of provisioning servers, deploying software, or other common repeatable tasks. Each feature or system enhancement is a unique undertaking with it’s own requirements and nuances. The variability is just too great for measurement of variation to be applicable or useful. Producing control charts and measuring variation of system level responses could be useful, however this falls more under the engineering realms and system optimization, not process efficiency.
Also, most processes or systems don’t warrant the precision of being “6 sigma capable” outside of manufacturing. The sigma of a process represents the level of deviation it produces, so 3 or 4 sigma (3 sigma meaning 99.7% of outputs meet customer specification, where 6 means 99.9997%) are fit for purpose and cost in the context of application development and technology systems. Deviations are cheaper to catch and fix in flight as compared to the context of manufacturing industries. There may be specific processes in your company that warrant the investment of six sigma monitoring, analysis and control. As someone with an eye for process improvement, I’d be careful how many processes to add overhead of 6 sigma analysis to, it could become very expensive quickly. That said, 6 sigma practices could be valuable for steady state request fulfillment, if this is something you’re looking to enhance your team’s capabilities around don’t skip over this. They may complement other methodologies like ITIL service request management well.
Lean, however, is a great way to think about process improvement and can give structure to larger improvement initiatives. Smaller scale, localized improvements can be achieved in operations with good incident post-mortem culture, good RCAs, and good inter-departmental communications and attitudes. When more systemic or thematic organizational change is required, a formal Kaizen or project charter with the DMAIC structure is a very valuable tool. These are standard methods and terminologies to clearly scope the problem, frame current state, be data driven in hypothesizing solutions, and measure whether improvements are making an impact. If your focus is to empower teams to drive continual improvement, Lean may be the unified lexicon your organization needs to prevent miscommunication, drive cohesion, and get the right cultures in place.
Another aspect of lean which could be very valuable is it articulates waste categories to a very granular specificity. This capability can enhance an empowered team’s thought process, as well as how they articulate waste (value stream mapping is great tool for this).
To better articulate what I mean, below are Lean 6 Sigma’s waste categories. I found they were a bit too manufacturing focused, so I took the liberty of adding my commentary on how they would be applicable in the context of developing and operating software at scale.
Waiting
In manufacturing, this waste category is used to identify raw materials or other types of resources which are sitting in a queue somewhere. From a lean/agile perspective this is very useful, and if you’re familiar with the DORA metrics you’ll see the inspiration behind “lead time for changes” being identified as a key DevOps capability. Any time a person has to wait for another person or system for an approval or assistance, this is waste. Anything that adds lead time should be viewed with a critical eye to ensure it is providing value to the customer. If it does provide value to the customer every effort should be made to remove dependencies or streamline resources.
Overproduction/Overprocessing
In the context of manufacturing this refers to the overproduction of materials or product, usually inspired by trying to keep machines and people working. While well intentioned, it generally results in production of product which is not immediately needed by customers, or is the wrong product but adjusting production lines is deemed to disruptive. Either way it sits in a warehouse for a very long time. In software development this manifests in the forms of over engineering. Systems or features can be over-engineered to the point where they are too expensive for purpose or are features the customer wouldn’t use. This can show up as a system over-architected and ergo has exorbitant infrastructure costs, or a feature built for customers that they didn’t want.
Rework
Rework in the context of manufacturing means the product did not meet specifications and have to be re-processed through the line, or other corrections needed to be made.
This same context applies in software, and can be quite expensive. The later in the software development lifecycle a defect or feedback loop occurs, the more expensive it can be to fix. This is why we say we want to “shift left” in the SDLC. The closer to the beginning of the cycle (architecture, design) we can find a flaw, the less expensive it is to fix.
Inventory
Inventory refers to have too much materials or product, as this is specifically wasteful in manufacturing. This means something else could have been ordered or produced, and signifies erroneous investment of capital or resources.
In the context of software, this has applicability to teams producing the wrong features. This is why Lean-Agile focuses teams on an MVP (minimum viable product) so we can test assumptions quickly on what product the customer wants. Much of software is a guessing game. Whichever company can test assumptions quickest and be data driven in proving/disproving their hypotheses will most likely come out on top in the long run.
Transportation/Motion
In manufacturing, motion refers to humans having to physically move within a location, and transportation being physically shipping products between locations via freight.
In software development categories like transportation and motion aren’t so applicable due to the virtual nature of most of the work. Software has been delivered digitally for some time now. You could make a commentary on co-location of teams to prevent transportation time and costs relating to individuals, but I think that is outside the spirit of the original intention of these waste categories.
As you can see, there are a lot of good learnings which can be applied in a software context. Japanese manufacturing improvment methodologies were quite revolutionary in the 80s, so other frameworks and bodies of knowledge have already incorporated some of the learnings.
As a leader or individual choosing which training is right for you and your teams, it’s really up to you how deep of a dive you’d like to take. It may be prudent to consider the level your teams are currently at, if they have foundations in other frameworks which could be more valuable to beginners, or if this specialized process improvement view is what they need to take that next step.