There is a  lot of of literature on application of  Lean and TPS to software industry. The Kanban Method takes the majority share of discussion around this. However, there are some key takeaways from Lean thinking that need to be understood/appreciate but haven’t got adequate focus in the software community. This article puts into perspective some of these learnings from TPS and what it means for us in the industry.

The Production Pyramid:

Production Pyramid is basic of a Toyota Production System. There are many variations of it in the public domain. However, one of the versions that I was introduced is this:

Production pyramid has some key insights for us.

Lesson I: Getting the foundation right!

The foundation of any improvement starts with 5S activities. As we get better, we focus on existing wastes (the 3MUs) and supplement them with Visual Management methods to improve our process.

Lesson II: Be patient to get the foundation right!

There is no direct co-relation between the final objective of Profit and these foundation activities. Yet, without putting into place a strong foundation, any expectation of sustained profit is misplaced.

Corollary: When organizations focus on short term profits (monthly or quarterly), they will often drive themselves to ignore these foundation activities, causing them long term negative impact.

Understanding 5S Better:

One can refer to Wikipedia for a more detailed elaboration of 5S. However, for the purpose of this article, I will summarize the same:

1. Seiri (Sorting): Sort articles into necessary/unnecessary categories; remove those that are not needed
2. Seiton (Orderliness): Necessary articles at necessary time; you should be able to take out any article at any time.
3. Seiso (Cleaning): Inspection to find abnormalities, keeping ergonomics in mind
4. Seiketsu: Maintain a clean state (that you have got from the above 3S)
5. Shitsuke: Develop the habit of abiding by what is laid down.

Lesson III: 3S vs 2S

It is important to recognize that while the Top 3S help to get better using Kaizen, the Bottom 2S help us to sustain the gains from the Top 3!

Continuous practice of these activities should be a part of the team habit/culture; not an afterthought from some corrective action or a senior person pushing the team to move in this direction.

While there are a lot of areas of application of Seiri, Seiton and Seiso in the manufacturing sector, there are some impacts areas for us in the software industry, though exactly not in the same buckets. Some of these, but not limited to, are:

• Technical Debt: there are many things that contribute to technical debt and one needs to focus on all of the same
• Workplace hygiene: once again, there are many things that fall into this bucket and team should focus on them
• Standards/guidelines for design, development, etc. The importance of this extends to naming conventions, folder structure, etc.
• Information sharing across teams using notice boards, portals, team meetings, etc.
• Right infrastructure for the team/job profile, including hardware/software/other resources
• Clear role/responsibility definition with person identification
• Inspection to find work product abnormalities, be it for code/test cases/design documents, etc.

Many of these would also get repeated when we focus on removing Muda. There is already a lot of literature on the same in the public domain that I am not repeating.

Lesson IV: Three stages of Seiso

There are 3 stages of the Seiso process that can be well adapted to the software development:

• Start off with the actual fixing work (defect fixing, design fixing, test case fixing, infra fixing, etc.). In other words, focus on “resolution”.
• Kaizen the process of fixing – how can this be improved itself?
• What can we do so that this “fixing” can be eliminated? In other words, focus on “prevention”.

Software professionals from the CMMI background are well familiar with Corrective Action and the DAR process area. It isn’t hard to recognize the similarity between the two.

This 3 stage process can help teams go much beyond just the “fix”. In most development teams, the urgency to “fix” things prevents the team from getting deeper into the next 2 activities. Its counter-productive in the long term!

Lesson V: Keeping a “clean” state

Seiketsu is about how to keep a “clean” state! Its analogous to keep a level of code quality once it has been achieved. Traditionally, project teams have been weak in this. We have a large Testing phase to clean the code only to see the code quality go bad in the next Development phase; then, we again hit the Testing phase.

Agile thinking, with its associates engineering practices (TDD and CI) focus on this specific aspect. One cannot really be Lean or Agile without these engineering practices.

Lesson VI: Using Visual Management when abnormality is detected

The other aspect of Seiketsu is to use Visual Management methods to alert teams when abnormality is detected. This is analogous to a build failure that gets notified to the team participants immediately for attention and resolution! There may be many other points of failure that the team would like to focus on visually. Kanban Boards have 2 such examples: a) Lanes on a Kanban Board getting highlighted in RED when WIP limits are exceeded is one such example b) A card that is not able to flow forward getting highlighted using Blockers. A project teams should identify such points of failure/abnormality and define visual methods to highlight the same.

Lesson VII: Implementing Shitsuke

Implementing Shitsuke is done in the following 3 stages:

1. Decide what needs to be defined; make others aware of it
2. Follow the procedures; make everyone follow it
3. Confirm if the procedures are being followed; appreciate the people who are following it and guide the people who aren’t.

Lesson VIII: Improvement initiatives are harder to sustain

It is also well acknowledged that while one time improvement initiatives are doable and achievable, it is lot harder to sustain these initiatives and get them absorbed in the team DNA. In other words, of the 5S, the latter 2S is much harder than the former 3S. If not sustained with persistent effort and management focus, the benefits gains from the first 3S fades away over time.

Lesson IX: Keep broadcasting your success

Once your succeed in reaching a milestone of process improvement, share it with others and talk about it. Obviously, it motivates the team and helps them gain recognition for the good work they have put in.

What isn’t obvious is the phenomenon that happens when you continue to display the results! If the results do come down for some reason, the team is strongly motivated to set it right. Its embarrassing to fail on something that you have just been acknowledged for!

Lesson X: Kaizen vs Sustenance

This brings us to the most important learning – while Continuous Improvement is important, the team needs time to sustain and internalize the improvements from the earlier Kaizen cycles. My experience is that this is where many teams fail!

The importance of this alternate cycle between Sustenance and Kaizen is understated in current Agile/Lean literature in IT (to the extent that I have read). We keep reiterating the importance of Continuous Improvement. It is assumed that once a good practice is identified, it will be adhered to over time. In reality, it is much harder.

In the Kanban Method, we talk about the importance of Defining Policies. While that definitely moves in that direction, there is more focus needed to sustain.

Maintenance/Sustenance means setting standards and carrying out activities as per the standards. One typically undertakes a SDCA (Standardize, Do, Check, Act) cycle in this phase. A team needs to develop Standards/SOPs/Checklists to help the team follow the same and stabilize current practices and methods.

Kaizen means to set targets higher compared to current standards and then carry our activities to make it happen. One typically carries out the commonly understood cycle of PDCA for this.

A team needs to move in alternate cycles of Kaizen and Sustenance. Without this, any gain is temporary and it fizzles over time.

Kaizen leads to newer practices and methods that need to be standardized and internalized by the team BEFORE the next cycle of kaizen improvements are brought to the team.

So, don’t just focus on improvement… keep stabilizing and improving!

I want to end this blog by acknowledging Norio Suzuki for his inputs and helping with my deeper understanding of Lean and TPS.