5 Whys in practice

 

For want of a nail, the shoe was lost,
For want of a shoe, the horse was lost,
For want of a horse, the rider was lost,
For want of a rider, the message was lost,
For want of a message, the battle was lost,
For want of a battle, the war was lost,
For want of a war, the kingdom was lost,
For want of a nail, the world was lost
‘The Want of a Nail”

– T. Rundgren
Warner Chappell N.A., Ltd., 1989

We all must have read the above poem or heard about the proverb “For want of a Nail the kingdom was lost” at some point in our lives. Both the poem and the proverb illustrate anecdotally how disasters happen seemingly due to innocuous causes. It is fascinating how something seemingly unimportant could have caused great failures. It is also a subject of lots of research across the world for the past hundred years or so. Research to find solutions which prevent these tiny errors that cause cascading yet seemingly minor effects in a complex system that eventually cause it to fail.

Many effective solutions, methodologies and frameworks have come out from that research. 5 Whys is one of those frameworks. The definition of 5 Whys is as simple as it sounds, it is just a process of asking the question why 5 times. In practice it is a lot subtler than that, as you will see further in this blog.

It is, simply put, an iterative way to discover root causes, hidden or otherwise.

A more formal definition can be found on Wikipedia.

5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each answer forms the basis of the next question.

This blog goes into detail about how to effectively use 5 Whys in practice.

This technique was developed in the 1930s by Sakichi Toyoda one of the early pioneers of the Japanese industrial revolution.  He was an inventor, industrialist and was the founder of Toyota which uses this technique to solve problems to this day. Infact the 5 Whys technique was so effective that another Toyota pioneer Taiichi Ohno in his book Toyota Production System: Beyond Large-Scale Production,  says that it is “the basis of Toyota’s scientific approach”

The picture below is an illustration of the 5 why’s in action.

3768260_f1024

That is all there is to it. The key is in asking why something happened till we find a reasonable root cause, which itself is usually caused by something beyond our control

Now what if we had not asked why enough times in the previous case. We probably would have done one of the following.

  • ‘Un-tripped’ the machine from overload: The machine would have run fine till the next time it tripped because of overload. In the long term we would have damaged the machine by over using it in spite of it being overloaded.
  • Change the oil pump drive: Doing this would have solved the problem for some time until the new oil pump drive ‘wears out’

Here in both the cases we took some action which would solve the problem only temporarily and the problem comes back sometimes in a more severe form or accompanied by one or more new problems. This could have been avoided if we would have spent time analysing why the problem itself is happening in the first place instead of directly jumping to fix the visible symptom.

We need to temporarily suspend our thinking of  “How to fix the problem ?” and start thinking “Why is the problem occurring ?” and when we get an answer we start over again by suspending the “How to fix it” thought to think about “Why is it occurring”. Then repeat until we find the real root cause of the problem.

Before I conclude, here are a few points that one needs to keep in mind while using the 5 Why technique.

  • The number 5 is not set in stone:

While the technique recommends asking why 5 times it may so happen, that you found your root cause before the fifth why was asked. It is also possible that it took more than 5 whys for your root cause to be found. This is subjective and depends on your core problem.

You are the best judge of what your reasonable root cause is. A rule of thumb is whether you can do anything about your root cause. For example, lets assume that you have down time because of spare-parts not being available in your warehouse because of a labour strike in the country where the factory which produces your spare parts is located. You probably cant do anything about a strike in a foreign country. Then an exercise on finding the whys behind the strike happening in that country would probably be futile. Then your reasonable root cause is the lack of reserve spare parts. Also if you find that a root cause is something you can fix, there is no harm in asking a 6th or a 7th why till you reach one that is beyond your control.

Although one thing to remember is if too many of your 5 Whys sessions are ending in 1 or 2 whys or you are ending up with root causes that are way out of your control, then you may not be doing 5 Whys correctly.

  • The root cause is not the only thing that needs fixing:

If A is caused by B which is caused by C which in turn is caused by D and you find that D is your reasonable root cause, then the first obvious step is to fix D. Also in many cases it might be prudent to make sure that If D happens, then that shouldn’t lead to C happening which in turn should not cause B and B shouldn’t cause A.

In summary, while the purpose of the 5 Whys exercise is to establish causality, your resultant action should be counter measures that not only prevent the root cause but also break as many links as possible in the chain of causality from the root cause to your problem. Many people fix the root cause and neglect breaking the chains of causality.

  • Multiple Applications:

Because of its simplicity, 5 Whys can be used in a lot of places. It can be used for personal improvement,  sprint retrospectives and fact finding enquiries both corporate or otherwise. The only thing to remember is to keep finding causes till we find the root cause.

  • Not only for retrospecting failures:

Although it is predominantly used for finding root causes to problems or failures, it need not be the only place we use it. It can be used even to study successes. A 5 Whys inquiry is about finding a chain of causes and arriving at a root cause, no one says that the root cause should only lead to a failure.

It can be used to find reasons behind an unexpected success so that the ingredients of that success can be replicated. It can also be used – for example – to compare,  contrast and find out the real hidden differences between two systems that seem to give different outputs when inputs and preconditions seem to be same.

 

References

  • The picture above illustrating 5 Whys is taken from this awesome blog post on the same topic.
  • You can read more about the proverb ‘For want of a nail’ here.
  • The Wikipedia definition of 5 Whys is taken from… well wikipedia.

 

Advertisements

Agile Faux-Pas: Lack of a Product Owner

Agile Software development has taken the world by storm and its adoption is at unprecedented levels these days. Almost everyone these days talks about Agile software development and agility as a discipline. So you would expect that everyone learns and practices Agile Software development the right way at the right pace. Sadly that is not the case. There are countless examples where Agile Software development is not practised correctly.

That is the point of this new series of blogs, the Agile Faux-Pas series. While none of these will kill your software development (or may do in extreme cases), they definitely make you less Agile and often defeat the purpose of going Agile.

One very common ‘faux-pas’ is the lack of a proper Product Owner.

It usually manifests itself in the following ways.

  • Many teams and companies assume they don’t need a Product Owner(PO) or they have someone take over this role part time.
  • Others go the waterfall way and use a requirements document as a product owner.
  • Still some others improvise and have neither a requirements document or a PO. They just get the senior most team member or someone from management to act as a PO when needed.

This is a clear departure from Agile Principles. One of the main reasons for this is a wrong understanding of the PO’s purpose. Or even a total lack of understanding. Let me elaborate on that a bit and also throw light on how the PO is essential to the success of Scrum. For that let us first see what are his roles and responsibilities (in no particular order) and why they are important.

  • Demos and Constant Feedback: For the dev team’s point of view, the PO is the customer. In every Sprint review, the team gives the PO a demo of an incremental version of the product that has more value (features, bug fixes, enhancements) than the last one. This demo gives the PO an opportunity to look at the product and answer queries about whether the stories taken up for that sprint were done right. The PO should already have talked to the real customer or their representatives to get detailed product specs and the priority of each spec. Armed with that info, the PO should be able to answer any product specification related question the developer might ask. Also, the PO should be available to answer requirements related queries at any time during the sprint. Overall this provides much better feedback than a document, even a constantly updated one. The point to note is that while the PO maintains requirements in the Sprint and Product backlogs, they are not alternatives for him being personally available to look at the product, give feedback and clarify queries. It is this face to face communication that allows the dev team to constantly build the right features in the right order. Without that, there would be a great deal of wasted effort and rework.
  • Backlogs and their grooming:
    • Product and Sprint Backlogs are the most important artefacts maintained by the PO for each product under development. The Product backlog contains stories that need to be go into the product while the Sprint backlog has stories that need to be completed in a particular Sprint. In both backlogs, items are arranged according to Priority and this Priority is sacrosanct. At all times only the highest priority items should be taken for processing. These backlogs and their priorities are the PO’s responsibility and they are arrived at by constantly talking to the customer or their representatives.
    • Also before a sprint begins, the PO along with the scrum master works on making user stories for that Sprint “Sprint Ready” which essentially means the following.
      • Latest requirements: Requirements can and will change while the product is being built. The PO makes sure that before each sprint begins, each backlog item contains the latest specs.
      • Clear and well defined stories: The PO makes sure that there is no lack of clarity about what each story means. This can be achieved by mentioning the specs clearly with the stories in the backlog and also by being personally available to resolve queries face to face.
      • Acceptance criteria: The PO defines what constitutes successful delivery of each story before the sprint begins, allowing the team to demonstrate success (or not) for each feature developed.
  • Business inputs for the product: For any product, business inputs are key development drivers. As I mentioned earlier, the PO is a virtual customer for the dev team (including QA). The PO has all data about how the product is supposed to run in the field and is the single point of contact for the dev team to be able to get these insights. And since the PO has all the data, he usually is the best judge of the correct expected behaviour of the product in the field. The availability or lack of these insights could make or break a product.

As you have seen, the PO overall brings clarity to the developers, a clarity that probably cannot be matched by other substitutes. It is this very clarity and constant availability for face to face clarifications that make the PO’s an indispensable role for a truly Agile team.

There however are many reasons why teams are not able to have a proper Product Owner, I will look into some of those reasons in another blog and hopefully be able to provide solutions for that. I will also be looking into some best practices and anti patterns with respect to a PO in that blog.

Also, please share your feedback in the comments. I would love to hear your opinions and questions. Do subscribe if you feel that this blog is useful for you.

References

  • Implications of your PO being missing in action here.
  • What happens when you don’t have a PO at all. Read a thoughtful perspective here.
  • And here, why you need a dedicated product owner.

 

Tackling hurdles to Agililty

Agile methodologies, in some or the other form, have been around for close to three decades now. They have been immensely popular for software development across the world for a better part of a decade now. But there still are people who do not want this change. There still are pockets of resistance towards Agile and Agile Principles. There seem to be so many reasons why somehow Agile does not seem to be ‘right’ for them. Some are valid, others not so much.

Over the years, I have seen a lot of misconceptions people had about agile people which prevented them from transitioning to agile. In this post I wanted to dispel some of them. This may not be an exhaustive list but here are some of the most prominent ones. I will probably write a sequel to this post as and when I am able to find more ‘hurdles’ to Agile and how to tackle them.

So without much ado let us see how to tackle the first few ‘hurdles’.

‘I don’t want to restrict a well performing team with unnecessary ‘process’.’

No one likes unnecessary and heavyweight ceremonious process that exist only because someone mandated it. And none of the Agile processes are exceptions. Agile only expects a few specific conditions to be met.

  • Each iteration should finish with added value for the customer.
  • Software gets continuously validated.
  • Stakeholders should be actively involved.
  • Self organising teams.
  • Continuous improvement.

Agile doesn’t mandate how you achieve this, nor advocate a standard. If you are able to achieve these then you are agile. So there is no extensive and unnecessary ‘process’, there is no bureaucracy and no process that no one understands. Teams only work on those ‘process-things’ that satisfy the above 5 conditions.  Everything else is extra.

‘A daily status meeting: Oh! Its too stressful’

If you or your company see it as a status meeting, then you are doing Agile wrong. The point of this meeting is that everyone in your team knows what everyone else is doing, with the specific intent of making sure that the goals for that iteration (Sprint if you follow Scrum) is complete. It can serve as a status meeting for management, but if that is all that is happening then it is wrong. The point of a daily short meet is to ensure that everyone in the team knows the progress, can ask help or be of help if possible and to make course corrections if it seems they wont meet the goals for that iterations. And most importantly convey it as early as possible if it seems that the goals for the sprint will be missed.

All Agile methodologies accept failures so long as we learn from them. In fact the Agile way is to fail fast, fail early when too much effort, time and money hasn’t yet been committed to the project. So if you look at it as a status meeting, then you are doing it wrong. For a developer it is a forum where developers tell what they did, what they plan to do and most important try to predict impediments so that the scrum master can work on clearing them as soon as possible.  Also management need not be present in that meeting. If they are, then they need to be only listeners and provide input when asked for. The scrum master can brief the management in another meeting.

‘Agile gives license to throw away all discipline’

This misconception hurts both ways. It scares away people who want a disciplined execution of the project and it attracts those who think discipline is a chore.

The truth is that agile expects a lot of discipline from developers. It just doesn’t expect the processes and ceremonies to be imposed by the management above. On the contrary, it expects the team to be adults and evolve a process that works for them and also helps them meet all agile and project goals. Discipline is not stressed but it is implicit, and without discipline you can’t hope to succeed. The only difference is that the team follows rules and processes that make sense to them and not some company diktat that they comply with without understanding its purpose.

‘Agile is for short-term projects’

It is easy to see why there could be a misconception like this. The dev team usually focuses only on the goals for that particular iteration. So an outside observer might see a very short-termist outlook. And hence the view that this probably wont work for long term projects. And unfortunately many teams do work in this way, hacking up the code just so that the demo at the end of the iteration can be done. If a team works that way, then they are not agile.

Agile does say that you concentrate on just enough architecture and design to make sure that your sprint goals get met. But nothing stops you from having architectural issues and bugs in your sprint backlog. Usually if your architecture and design are not up to the mark, there definitely will be bugs. Nothing stops you from revisiting design once a feature is done. In fact you cant be truly agile without being constant, ongoing, small doses of refactoring. When the product owner is pushing features to the sprint backlog, the team also should be able to push architecture and bugs to the sprint backlog and then prune the backlog to make sure that only those many items that can be finished in the iteration remain. This way you can be truly agile and work on a long term project.

There are many more hurdles to Agile, that I will discuss in subsequent posts. For now I am leaving you with these. Do share your feedback in the comments. And don’t forget to subscribe to BeingNimble to get the latest posts right in your inbox.

References

  • A bit of an explanation about the conditions for agility here.

Install Oracle Java8 on Ubuntu

This is a summary of the steps I did to install Oracle Java8 on my laptop running Ubuntu 16.10 (Yakkety Yak). I used the PPA repositories provided by Wepupd8 and specifically referred to this very detailed post.

Please note that most Linux distros recommend openjdk as the default Java platform.  However, there are some products that specifically recommend Oracle’s JDK for their products.  I had one such product to install for my work and had to install Oracle’s JDK.

So here we go. Here are the main steps with the commands further below…

  1. Add webupd8’s PPA repositories for oracle java.
  2. Install Oracle Java.
  3. Set Oracle Java as the default.
  4. Verify that Oracle java is set as the default JVM.

 

Add webupd8’s PPA repositories for oracle java.

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update

Install Oracle Java. Do note that you will have to accept the binary license during the install, so stay there.

$ sudo apt-get install -y oracle-java8-installer

Set Oracle Java as the default.

$ sudo apt-get install -y oracle-java8-set-default

Verify that Oracle java is set as the default JVM.

$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) Server VM (build 25.111-b14, mixed mode)

If you see the HotSpot server VM being output then you are good. Finally, cleanup the unneeded stuff

$ sudo apt autoremove

Additionally, you may want to set the JAVA_HOME environment variable. Some products need this environment variable. To do this, enter the following line as the last line in ~/.bashrc file. Of course, this assumes you are using BASH as your shell. If you use some other shell, like fish or zsh, then check appropriately how to set JAVA_HOME permanently.

$ file `which java`
/usr/bin/java: symbolic link to /etc/alternatives/java
$ file /etc/alternatives/java
/etc/alternatives/java: symbolic link to /usr/lib/jvm/java-8-oracle/jre/bin/java
$ echo "export JAVA_HOME=/usr/lib/jvm/java-8-oracle/jre" >> ~/.bashrc

So that’s that. You should be all set now.

SBT, Scala, and “Hello, World!”

I am learning to program in Scala these days and plan to put up some random posts about it here.  Here I want to put up the instructions about how I installed Scala, through the Scala Build Tool (SBT), and how I got the hello world program working.  I used CentOS as the operating system.  So you might want to check parallel instructions for your specific operating system.

Installing SBT

I used the RPM packages to install SBT.  Briefly, the steps were as below.

$ curl https://bintray.com/sbt/rpm/rpm | sudo tee /etc/yum.repos.d/bintray-sbt-rpm.repo
$ sudo yum install sbt

If it went well SBT should be installed at /usr/bin/sbt.  You can check the version of SBT installed using sbt about.

$ curl which sbt
/usr/bin/sbt
$ sbt about
[info] Set current project to hariharan (in build file:/home/hariharan/)
[info] This is sbt 0.13.12
[info] The current project is {file:/home/hariharan/}hariharan 0.1-SNAPSHOT
[info] The current project is built against Scala 2.10.6
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.6

The Hello, World Program in Scala

Let us create a quick and simple “Hello, World” program here.  A more formal program with the recommended directory structure comes in the next section.

$ mkdir hello
$ cd hello
$ vi HelloWorld.scala 

Write the hello world code in this file.

object HelloWorld {
  def main(args: Array[String]) = println("Hello, World!!")
}
~
~

The command sbt compile will compile the code and sbt run will run it.

$ sbt compile
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Updating {file:/home/hariharan/work/training/scala/hello/}hello...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Compiling 1 Scala source to /home/hariharan/work/training/scala/hello/target/scala-2.10/classes...
[success] Total time: 132 s, completed 15 Oct, 2016 10:51:30 AM

The command sbt run will execute the hello world program.

$ sbt run
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Running HelloWorld 
Hello, World!!
[success] Total time: 1 s, completed 15 Oct, 2016 10:51:55 AM

Restructuring into the Correct Scala Directory Structure

In real-world Scala projects, the source code would be arranged in a more structured format than placing all files in a single folder.  If not other folder structure is defined, SBT assumes the conventional folder structure as recommended by Maven.  Let us now re-arrange the earlier hwllo-world code into the conventional form expected by SBT.  This should look as below:

hello
|-- build.sbt                      # Build definition for the project
|-- src                            # all source files go here
|   |-- main                       # production source files and resources go under this folder
|   |   |-- resources
|   |   `-- scala                  # Scala source files go here
|   |       `-- HelloWorld.scala
|   `-- test                       # test source files and resources go under this folder
|       |-- resources
|       `-- scala                  # Scala test files go here
|-- target                         # all compiled and downloaded binaries go here

Now build and run again

$ sbt compile
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Compiling 1 Scala source to /home/hariharan/work/training/scala/hello/target/scala-2.11/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.8. Compiling...
[info]   Compilation completed in 18.884 s
[success] Total time: 150 s, completed 15 Oct, 2016 11:43:38 AM
$ sbt run
[info] Set current project to hello (in build file:/home/hariharan/work/training/scala/hello/)
[info] Running HelloWorld 
Hello, World!!
[success] Total time: 1 s, completed 15 Oct, 2016 11:44:05 AM

Set up Version Control

We have the basic Hello world program working in the right folder structure.  Let us commit this into a Git repository now.

First, move to the root folder of the project.  Then create a .gitignore file so that git does not track the target/ folder tree.  Finally initialize a git repo and commit all files.

$ echo 'target/' > .gitignore
$ git init
Initialized empty Git repository in /home/hariharan/work/training/scala/hello/.git/
$ git add .
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#    new file:   .gitignore
#    new file:   build.sbt
#    new file:   src/main/scala/HelloWorld.scala
#
$ git commit -m "First commit of the hello world project in Scala"
[master (root-commit) ed1500f] First commit of the hello world project in Scala
3 files changed, 11 insertions(+)
create mode 100644 .gitignore
create mode 100644 build.sbt
create mode 100644 src/main/scala/HelloWorld.scala

 

Origins of Lean Software Development

The intention of this post is to briefly touch upon the development up to the Lean Software Development movement starting from the very origins in Toyoda. This post may touch upon many words, concepts, and principles but provide no detailed explanations. The intention is to produce many other posts that will explore the details of Lean Software Development.

The Beginings

Sakichi Toyoda, the founder of Toyota, owned the Toyoda Loom Works that manufactured fully automatic machines for the textile industry. His machines had one of the earliest implementation of what would later become the concept of Jidoka (a.k.a stop-the-line or Autonomation in Lean manufacturing). When the machine encountered any little problem it would stop and signal for the weaver to fix the problem.

The origins of Just-in-time (JIT) Production

Sakichi Toyoda was joined by his son Kiichiro Toyoda and they together grew the loom business profitably. Kiichiro Toyoda later diversified into automobile manufacturing by founding the Toyota Motor Corporation in 1937. The new company soon hit into manufacturing restrictions placed on passenger cars during the second world war. After the war the restrictions were lifted but the American automobile industry (Ford and GM, specifically) had surged way ahead through their huge factories and mass production models. There was little Toyota could work conventionally match such competing economies of scale due to the following factors:

  • Lack of land and finances in post-war Japan prevented building of huge factories
  • Lack of natural minerals and other natural resources
  • High unemployment

These compulsions led Sakichi Toyoda to vision a “Just-in-time production system” that was based on Jidoka,  understanding the whole, respect for people and Kaizen (continuous improvement). He set a vision and challenged employees in his company to implement this and catch up with the American competition.

The Toyota Production System (TPS)

Taiichi Ohno, an employee of Toyota Motor company and the Toyoda Loom Works before that, responded to the challenge. He was a shop floor supervisor in the engine manufacturing shop. He studied the US automobile industry, especially Ford, and used the experience from Toyoda Looms to perfect a production system that incorporated Sakichi Toyoda’s vision of JIT, Jidoka, and Kaizen. This he called the Toyota Production System which he defined as a system to absolutely eliminate all waste from Toyota’s automobile manufacturing process. He defined 7 types of Muda (waste) for this purpose that ought to be eliminated:

The 7 types of wastes in a production system

Delay, waiting or time spent in a queue with no value being added Unnecessary movement or motion
Producing more than you need Inventory
Over processing or undertaking non-value added activity Production of Defects
Transportation

The basic principles of the TPS system are listed here:

1. Kaizen

Challenge and understand the whole, Genshi Genbutsu (go to the floor and observe to understand the problem first hand)

4. The right process will produce the right results

Kanban (Visualize a pull based workflow), Heijunka (level the workload), JIT, Jidoka, standardize, transparency

2. Respect

respect for people, teamwork

5. Add value to the organization by developing your people and partners

Develop exceptional and committed people, grow leadership at every level, respect partners and suppliers

3. Long term philosophy

Management must have a long-term view while making decisions

6. Continuously solve root problems to drive organizational learning

Genshi Genbutsu, Nemawashi (make decisions slowly but implement rapidly), Hansei (become a learning organization) and Kaizen

 

The Spread of TPS

Shigeo Shingo was a consultant specializing in factory management. He worked closely with Taiichi Ohno to deploy the TPS in Toyota. He later took the TPS and implemented it in various Japanese companies. Some of his books, especially the English translation Study of the Toyota Production System (a.k.a The Green Book) of his Japanese book, brought the TPS to the shores of America. He added the concept of quick assembly/re-assembly of machines (also called SMED) to produce various parts in the speed demanded by a JIT production system. His other notable concepts, added to Taiichi Ohno’s definition of TPS, was about Poka-Yoke (mistake-proofing the system by designing it to eliminate root cause of defects and making mistakes impossible to occur) and zero quality control (no need to examine results).

In the US, several researchers who studied the TPS expanded the 6 principles to 14 as listed below:

1. Establish customer-defined value to separate value-added from waste 8. Fully integrate suppliers into the product development system
2. Front-load the product development process to explore thoroughly alternative solutions while there is maximum design space. 9. Build in learning and continuous improvement
3. Create a level product development process flow 10. Build a culture to support excellence and relentless improvement
4. Utilize rigorous standardization to reduce variation, and create flexibility and predictable outcomes 11. Adapt technologies to fit your people and process
5. Develop a chief engineer system to integrate development from start to finish 12. Align your organization through simple visual communication
6. Organize to balance functional expertise and cross-functional integration 13. Use powerful tools for standardization and organizational learning
7. Develop towering competence in all engineers.

The Lean Production System and it’s Spread

During the 1990s, the TPS became famously known as the Lean Production System largely due to the book The machine that changed the world. Within Toyota, The Lean Production system also acquired other counter parts over time – The Lean Supply Chain (to extend Lean to suppliers and partners also), and The Lean Product Development System (to extend Lean to the product development process also).

Lean Software Development

Outside of Toyota Motors, the Lean Manufacturing system were adapted into services and IT forming the Lean Services and Lean IT respectively. The Lean Software Development adapted Lean manufacturing, Lean Services, Lean IT  to the software domain and merged them with the Agile principles and practices.. This was designed by Mary Poppendieck and Tom Poppendieck based on their experiences in Software development and implementing Lean in their manufacturing industries. It contained 7 principles and 22 tools or practices.

The 7 principles of Lean Software Development are listed here.

1. Eliminate waste 5. Empower the team
2. Amplify learning and create knowledge 6. Build integrity/quiality in
3. Decide as late as possible 7. See the whole
4. Deliver as fast as possible

The 22 tools or practices are listed here.

1. Seeing waste 12. Cost of delay
2. Value stream mapping 13. Self determination
3. Feedback 14. Motivation
4. Iterations 15. Leadership
5. Synchronization 16. Expertise
6. Set based development 17. Perceived integrity
7. Options thinking 18. Conceptual integrity
8. The last responsible moment 19. Refactoring
9. Making decisions 20. Testing
10. Pull systems 21. Measurements
11. Queuing theory 22. Contracts

References

  1. Lean Software Development: An Agile Toolkit by Mary Poppendieck et al.
  2. Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck et al.
  3. Lean Software Development – A History
  4. The Toyota Production System