Cross Pollination

Since I received my Lean Six Sigma Yellow belt from goleansixsigma I have been receiving a lot of emails about how to do things better. How to implement Lean and Six Sigma from doing your gardening to any project. Now, a lot of these posts include techniques taken from the Agile community such as Kanban boards, Retrospectives and such. What we are seeing here is a cross pollination of techniques across different disciplines. Its not surprising. Go Lean Six Sigma, mainly used, but not limited to the manufacturing space  as I understand it and Agile for the software industry have the same parentage in the Toyota Production System and both foster continuous improvement. It stands to reason that in improvement and practice in one discipline could be used in another.

To me, it just proves that we are all on the right track, be it Agile, Lean, DevOps, Theory Of Constraints, they are all on the same path, just in different lanes to the same destination of continuous improvement through feedback loops. Each lane a variation of solving the same or similar problems, but in different contexts.

So my thinking is that regardless of the methodology you employ, or even if you make it up yourself. Provided you are willing to question everything, have an open mind, diligently try to improve and implement a feedback loop to test those improvements and adapt to be better, you will eventually find yourself on or close to one of these methodologies, or potentially a completely different lane as your “context” may be different but still going the same way.

Retrospective Idea – Celebrate Failure

Ok, after more than 2 years of studying Lean and Agile and a little over 1 year since I got my Scrum Master certification, I am finally a Scrum Master (albeit part time) in a project.  I haven't got full control of the scrum process and I wasn't Scrum Master from the start (I was on leave when the project started) but it is a start and there have been and still are a few challenges.

Last Friday I did my second retrospective and I tried to do one of my own making this time.

After a successful showcase the day before (It was the only time we could get all the stakeholders together – so we had a 9 day sprint) I didn't want to focus on the success. Unlike most projects I've worked on, when something is successful – we tend to focus on the successes and the failures and problems get shoved under the rug. This time I wanted to make them front and center.

So, with the sprint report in hand showing a big cliff after 5 days of work, and buttering everyone up with doughnuts we went to work.

The question became "How can be make a sprint more linear in execution instead of the cliff we had?" This became the guideline for the retrospective, but what I was really after was any problems.

I had 3 rules for the Retrospective.

  1. No one can have a doughnut until they bring up a problem. This was to firstly give everyone an incentive to speak up. Doughnuts can be good incentives – except for those who are looking out for what they eat – but they still got involved.
  2. No Blaming, finger pointing. I don't want anything said to be held against anyone else.
  3. No excuses. I don't care there were BAU issues during the sprint.

The first step was to get a list of problems, issues, anything that you hated and anything that you think prevented you from completing stories in a linear fashion. We did this for the first 15 minutes.

Next we identified any duplicates and prioritized the first 5 problems.

The final step was to go through each of the 5 problems and work out the "Why?" the problem occurred. "How?" we can overcome the problem and finally any "Action" that needs to be done.

The board was broken up as follows.

In the Problem section, I inserted the first of the 5 problems.

In the Why, the team then brought up reasons for the problem with me prompting to drill down. I was trying to use the 5 why's technique to get to the root causes. I probably didn't do so well, as there was many root causes, but it is still early days experience wise for me.

In the How section, we brought up contingencies and countermeasures for the causes of the problems.

Finally in the Actions section, we bought up actions for the Scrum Master, Product Owner and Team Members either collectively or individually to do something. These were not assigned, but members decided to take responsibility for the actions.

I think the whole process went fairly well with the only problem that we went overtime by about 10 min. (From 1.5 hours time-boxed for the retro because it was a 2 week sprint).

The reason I liked this type of retrospective was that it actually focused the team on individual issues and problems that "they" found and had issue with. The sprint report gave focus  as to what was wrong rather than pie in the sky thinking.  Now we see what we can do about it in the next sprint.

As a personal note – Implementing Scrum is hard. Especially when you are doing it the first time and have no idea what you are doing, even after studying it for so long. I have this mental model in my head of what a Scrum sprint should look like and we have varied wildly from that. I'm not going to take this as a sign that Scrum doesn't work – but as a sign that I'm doing something wrong, which I know I am. I feel that my job now is to reign in the bad practices and try to introduce good practices as I understand them in gradually. For those practices that I don't quite understand, try something and see if it works while still staying to the scrum framework.

Once everything is reigned in, then start taking stats more seriously and be more aggressive in our improvements.

At least that is my thinking – which is going to be hard with a 4 sprint project. But who knows, it might help with BAU work in the future after this project.

Agile Methodologies

Ok, here is another chapter in my upcoming (hopefully) book on Agile.

This post is the raw text, it still needs refinement, but I just wanted to record my unfiltered thoughts first. At some point this will be reposted as an edited version, or I’ll just release the book if it is ever done.

Agile Methodologies

Most likely if you are thinking about going agile, you are thinking Scrum. Yes, Scrum is the most popular method of Agile, but there have been many that have been developed over the years. Some have stood the test of time and are still in use today. Others have dropped off to the wayside. Some are new comers and have managed to gain a following. In this section, I want to go through some of the agile Methodologies that are out there, but I will concentrate specifically on Scrum for two reasons. Firstly, it is the most popular implementation of Agile, and secondly, it is the agile methodology that I am most familiar with.

The Toyota Production System (Lean)

The Toyota Production System was the first Agile approach although it was developed long before the term Agile. It even pre-dates software development. In fact it started in the Car manufacturing industry. The approach was simple. Elimination of waste and continuous improvement. I won’t go through details of how it was developed, but eventually it was taken up by other car manufacturers in the 1980’s and 1990’s and changed its name to Lean as you could not have car manufacturers saying they worked the same way as Toyota. It wasn’t until Tom and Mary Poppendieck published the book “Lean Software Development: An Agile Toolkit” in 2003 that the Lean software movement took off, even though a majority of Agile Methodologies developed earlier used Lean Principles as a basis.
The lean Software development approach is summarized in the following principles.

  1. Eliminate Waste.
  2. Amplify Learning.
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build integrity in
  7. See The Whole

Lean Software Development Wikipedia Entry
The Lean Mindset – Tom and Mary Poppendieck

DSDM (Dynamic System Development Method)

DSDM was first developed in 1994 and was thought to provide discipline to RAD (Rapid Application Development) software development.
DSDM is an iterative and incremental approach to software development that has elements of the agile development approach and encouraged s end user/customer involvement of the process. DSDM is also where the MoSCoW prioritization method was developed.
MoSCoW uses the four following priorities.
M – Must Have Requirements
S – Should Have Requirements
C – Could Have Requirements
W – Won’t Have Requirements
DSDM is owned and managed by the Agile Business Consortium, a not-for-profit vendor independent organization.

Dynamic System Development Method

Extreme Programming (XP)

Extreme Programming was created by Kent Beck during his work at Chrysler Comprehensive Compensation payroll project which he started working on in 1996. He refined his approach and released the book Extreme Programming Explained in 1999. The premise of extreme Programming was to take the best practices of Software Development at the time and take them to extreme levels. At the time Extreme Sports was very popular. Principles of Test First development and Pair Programming were formalized through the extreme Programming

The lifecycle of Extreme Programming consists of 5 phases.

  • Exploration
  • Planning
  • Iterations to Release
  • Productionising
  • Maintenance and
  • Death

The 4 basic activities for Extreme Programming are

  • coding
  • Testing
  • Listening
  • Designing

The 5 values of Extreme Programming are

  • communication
  • Simplicity
  • Feedback
  • Courage
  • respect

Extreme Programming Wikipedia Entry

Kent Beck – Extreme Programming Explained

Agile RUP (Rational Unified Process) or AUP (Agile Unified Process)

Agile RUP is a simplified version of the Rational Unified Process. The Rational Unified Process is an iterative software process originally developed by Rational Software in the 1990’s. Rational was later purchased by IBM in 2003.

AUP has seven disciplines.

  • Model
  • Implementation
  • Test
  • Deployment
  • Configuration Management
  • Project Management
  • Environment


  • Your staff know what they are doing
  • Simplicity
  • Agility
  • Focus on high value activities
  • Tool independence
  • You’ll want to tailor the AUP to meet your own needs

Wikipedia Entry For Agile Unified Process


Kanban in software development is a method for managing knowledge work. It is a visual method that specifically uses “pull” to control the flow. This is in contradiction of more traditional methods of work management where work is “pushed” into process.
Kanban was developed by David Anderson n his 2010 book “ Kanban” where he used the Theory of Constraints methodology at a project at Microsoft. The name Kanban comes from the Toyota Production System where it means “signal” and is used to signal the need for something.
A simple example of a Kanban system in manufacturing would be where an assembler might have 2 tubs of screws. The first tub he takes from, the second is standby. When he runs out of screws in the first tub, a card attached to the tub is taken to signal that the assembler has run out of screws. The assembler continues to use the second tub. The card, known as a Kanban card is then taken to inventory where the screws are kept. This signals the inventory to send out another tub of screws to the assembler, which now becomes his second tub.
That is not the end of the card though. That card is then sent to the purchasing department where it triggers he purchasing of another tub of screws. As a side note, Toyota does do orders at least daily for the work to be done the next day, if not more often. Very rarely do they order in bulk. That would only be for times when there is long shipping times for parts directly from Japan, at least here in Australia. Most parts are sourced locally, delivered either that day or the next day for the cars to be manufactured that day.
Back to software development, David Anderson modeled work in a similar manner. Cards represent the work that needs to be done. There are lanes that indicate the process the “work” needs to go through. The idea is that the worker pulls the cards as it progresses from one process to the next. Work in process is limited only to a maximum of 3 items per worker. This helps alleviate some inconsistencies. If a worker has more than 3 items in progress in a process, then the person giving the work needs to step in, and help that worker get back on track.
For example, a developer develops 4 features quickly in succession, but the tester is stuck on the first feature still. The developer stops further development and then helps the tester with testing. The developer may help test 2 features. Now when the testers work in progress drops down to 2, the developer goes back to development.
The advantage of the system is that it gets things done quicker. It also allows you to see where the problems are in the system and know where to add additional resources. Kanban is also very visual. You can see at a glance the work in progress, what is remaining to be done and what has been done. Especially when a physical board is used. Some people also like virtual boards. The advantage of a virtual board is that it can help teams with remote members, automatically generate reports and not be knocked over, but you loose the visibility. You have to “open” the software to view the board and thus it can fall to the “out of sight, out of mind” problem.

The Kanban system has been so successful that is is used on many agile Methodologies as a means to manage work to be done. Many teams that use agile of varying types can be seen to have physical boards around their office as a means to manage work, be they use Kanban itself or Scrum, XP or even Lean Software development.

Wikipedia – Kanban Development>)

David Anderson – Kanban


Crystal is a family of Agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and Crystal Red. The darker the colour, the more heavy the methodology. Each approach is used depending on the project size, team size, critically, project priorities etc.
Several of the key properties of crystal include teamwork
, communication and simplicity. There is an element of frequent reflection to adjust and improve the process. Like other Agile processes, Crystal promotes the frequent delivery of working software, high user involvement, adaptability and the removal of waste in the form of bureaucracy or distractions.
Crystal was started by Alistair Cockburn when he released the book “Crystal Clear: A Human-Powered Methodology for Small Teams” published 2004.

Wikipedia Entry for Crystal Clear)


The DevOps movement was started by Patrick Debois in 2009 when he saw the live presentation streamed over the internet by Paul Hammond and John Alspaw at the 2009 Velocity Conference.
The talk, “10 Deploys Per Day, Dev and Ops Co-operation at Flickr”.
Through the twitter stream, Patrick sited how much he would have liked to be at the conference and through a joke was told to start his own conference.
Patrick did just that and in 2009 in Ghent Belgium, the first ever DevOps Days conference was held. Due to Twitters 140 character limit, the “Days” portion of the name was dropped and the hash tag #DevOps was born and has stuck since.

DevOps was created by people in operations who were frustrated at the way work was being done. They would see Agile being used by Developers, but would stop once the features were in production. There had to be a better way. And so people in operations started their own methodology which included culture, tools and philosophy. Technology such as Infrastructure as Code, Continuous Deployment and culture borrowed from other Agile processes such as Theory of Constraints, Lean. They embraced the teachings of W. Edwards Deming, Elyahu Goldratt and Taichi Ohno. Learned lessons from the Manufacturing industry from 30 years previous. They embrace Agile methodologies such as Scrum, but expand on the process to continue into operations.
DevOps promotes continuous delivery, automation of the mundane, the difficult and frequent deployments. Some companies deploy multiple times per day. Amazon, one of the most prolific users of DevOps deploys on average once every 11.6 seconds. DevOps encourages experimentation to try to improve processes and continuously strive to get better.

Some say that DevOps may be the next evolution of Agile. They may be right.

Wikipedia Entry For DevOps

Damon Edwards – The History Of DevOps

John Alspaw and Paul Hammond – 10 Deploys Per Day

Amazon Deploys Every 11.6 Seconds


We finally come to Scrum. Scrum is a methodology and framework developed by Jeff Sutherland and Ken Schwaber and presented to the OOPSLA conference in 1995. Scrum is an open source framework. You do not have to pay any licence fees to use Scrum, but you do need to follow the required portions of Scrum, otherwise as mentioned in the Scrum Guide, although you can use portions of Scrum, if you are not following the requirements as per the guide, you are not doing Scrum.
Scrum is a framework. It has been created to form a base process. Once you have the basics in place you can develop on top. Practices such as User Stories and Kanban Boards are examples of this.
Scrum consists of 3 roles.
The Scrum Master who is in charge of making sure that the team follows the Scrum principles. Without someone driving the principles, teams tend to regress to more familiar development processes such as Waterfall, or start doing the “Easy” Parts of Scrum without doing the hard parts, thus not getting the full benefit.
The second role is the “Product Owner”. The Product Owner is the advocate for the business. They provide the requirements. What the business wants. They are also in charge of what work is to be done which is in the form of an ordered backlog. The backlog is ordered based on what gives the most value to the business. The product owner does not dictate how the work is to be done.
The third and final role is the Development Team. This is a self managed , cross functional dedicated team who performs the work. The team is in charge of how to implement the requirements. There are no leaders within the team. The whole concept is very egalitarian.

In Scrum there are 4 ceremonies.
The Sprint Planning Sessions where planning of the sprint, a short period of development usually about 2 weeks.
The Daily Standup where the Development Team members synchronize on what they are doing.
The Sprint Review where the development team shows the stake holders what they have done during the sprint and finally the
Retrospective where the team reflects on the sprint. Determine what practices went well, what didn’t and try to find out how to improve on the next sprint.
This is another form of the feedback cycle.

Finally, there are 3 artifacts in Scrum.
The Product backlog.
The Sprint Backlog and the
Product Increment. A portion of the product that should be in a state that is releasable to production after each sprint.

We will go through the details of Scrum later in more detail.

The Scrum Guide

Wikipedia Entry – Scrum Software Development)

Scrum Hybrids

Finally there are Scrum Hybrids. These are where 2 or more methodologies are combined with Scrum. Some notable hybrids are Scrumban, a combination of Scrum and Kanban and Water-Scrum-Fall where the waterfall methodology is combined with Scrum. It should be noted that Water-Scrum-Fall is not generally an accepted methodology in the Agile community, but is seen as an example of what can happen when the easy bits of scrum are combined with the Waterfall Methodology. Generally the benefits of this approach are minimal compared to properly implemented Scrum.
Not all hybrids are bad – Scrumban is considered a success, but you do need to know what you are doing to get the full benefits.

Wikipedia Entry – Scrumban


Notable Mentions

Other notable mentions are
The Theory of Constraints. Not considered an Agile Methodology, but can be adapted to Software development and in the case of DevOps has been incorporated. Released when Elyahu Goldratt released his Management teaching novel “The Goal”.

Lean Six Sigma. Another manufacturing methodology that can be adapted to Software Development that combines the elimination of Waste part of Lean with the Continuous Improvement parts of Six Sigma.
Six Sigma uses the DMAIC process for problem resolution where it stands for
D – Define
M – Measure
A – Analyze
I – Improve
C – Control

Pair Programming – My Ignorant View

Firstly a disclaimer. I have never done pair Programming. Never read officially about it I.e. Kent Becks Extreme Programming Explained. I have only what I have read in blogs, which is limited and my own thoughts. 
I feel it is important to document my ignorant understanding before I embark on learning as it gives a base level of my understanding based on what I currently know about agile methods which I can look at in the near or distant future and see my progress. 

Now, for my ideas on pair Programming .

Say you have 2 people, A and B. A has knowledge that B needs.

First phase, A and B sit together. A works while B observes. B can ask questions, but A explains as they go along what they are dong.

Second phase, B takes over while A observes. B applies the knowledge they have learned, while A corrects B for any mistakes or answers any questions as required.

At the end of both phases, you now have 2 people converse in the knowledge.

Now it it time for the third phase. B now teaches C and simultaneously, A can teach D if required.

This I see as a good way to disseminate knowledge through a group. You get the one on one time and then apply the knowledge through teaching. 

I first saw something similar in a TV show. ER as a method for surgeons to disseminate knowledge. The saying was…

  • See one
  • Do one
  • Teach one

Now, as I mentioned earlier, this is my ignorant thoughts, but I would like to know everyone else’s on the topic. Let me know in the comments.

The Founder

I recently watched the movie ‘The Founder’, and i was watching the MacDonalds brothers talking about how they started. To me, the way they worked everything out looked like Lean to me. They way they worked out the restaurant layout, on a tennis court, with chalk outlines then get the people in to simulate their work. Try it out, when it doesn’t work, scrub out the lines, re-draw. The way the brothers automated, also how they failed but kept trying different things. They also didn’t hide anything. Eye showed everything off. Not only to Ray Kroc, but anyone interested. Just like TOyota does.
The whole system looked like lean in the making, if this story is accurate, it meant that the US had lean concepts 30+ years before it was formally introduced by Toyota in the 80’s. The movie was sad in the end, the McDonald brothers lost their legacy. Had there been collaboration instead of confrontation between the McDonald brothers and Ray Kroc, maybe lean might have been incorporated into the culture a decade or so earlier.

I guess we’ll never know.

Yellow Belt

I’ve just completed and passed the Lean Six Sigma Yellow Belt course at

The course is an introduction to Lean Six Sigma and goes through the DMAIC steps. The basic introduction is the white belt which is also free, but I didn’t take.

D – Define

M – Measure

A – Analyze

I – Implement

C – Control

The course itself is free and I recommend doing the course as it will give you another perspective to Lean. Whether or not you choose to do the certification, I leave that up to you, but it costs $99 US to take the test with unlimited retakes, which I happily paid.

At some point I’ll go through the things I found interesting in the course, but for now I just want to let you know about it.

The Agile Mindset

This is the second chapter. Lets see how we go.

The Agile Mindset

There are two parts to being Agile. The first half is the Agile mindset. This is where your thinking needs to change. Agile when implemented correctly is a paradigm shift in the thought process compared to how work is performed today.
The second half is the process. The process adds discipline and structure to your Agile thinking. Implementing the Agile mindset, is a cultural change. Even if you do not implement the process side, you can still do great things. The problem is that most people, when they start to implement Agile only implement the process. Although benefits can be gained, they are small. The process itself feels empty like you are just going through the motions, which you are. If you don’t make the leap to the mind set, then most likely your Agile journey will end and you will regress back to your previous work practices.

So what is the Agile mindset and what is the alternative mindset?
According to Linda Rising and her talk on the Agile Mindset, there are 2 types of people. The first is people that think you are born with a certain level of intelligence/talent or ability, you can learn new things, but you can’t change how intelligent/talented or able you are.
The second type of people are those that think that no matter how intelligent /talented or abled you are, you can always get better. Sometimes you can improve a lot.

The first type of people are considered the “Fixed” mindset. The second are considered the “Agile” or “Growth” mindset. Now, we all have these mindsets at some point. We flip flop depending on the situation and what we know all the time, but some people are more dominant in one mindset that the other.
People with the fixed mindset are more prone to fear failure. They will choose an easier path. The path of less resistance. The one less prone to failure.
Their thinking is that it is too difficult to do, so why try. They avoid challenge and prefer proven techniques. Techniques that have proved their success. Alternatively, when they fail, they look at the “success” in the failure and focus on that. These people are more interested in looking good.

On the other hand, those with the Growth or Agile mindset, look at a difficult situation and think – If I just work a little longer, try a bit harder, spend a bit more time on it, I will get it. If they fail, they try again.
There have been numerous psychological studies on this. In one of these studies, it found that a particular mindset can be easily induced. At least for a short period. Ever been told that something is too difficult to do, then give up? Alternatively, when you do something well, you think I’ve made it. Then stop? That is the fixed mindset.
On the other hand, if you have been told that something is too difficult and decided to try it for yourself anyway, or when you get something right, try to improve it, that is the Agile mindset. These are just a couple of examples.

The thing is that we become either mindset when we are young. If we are told when we are children that we are “Talented” in something or “You’re so smart!” or the negative “You are so stupid” or “You won’t amount to anything”, then this induces the expectation. For those that get the praise, they become praise junkies. They look to what they can do to keep getting the “You’re so talented” praise. The best way to do that is to find a challenge that isn’t too difficult. One that isn’t too far out of reach.
The problem is, that when a child with this type of thinking comes across a challenge that is too difficult, the child either avoids or ignores the challenge.
These are the children that grow up to be fixed mind set dominant.

Alternatively, children that are praised on their “effort” rather than that result, even if they fail, or for the negative, told that they “need to work harder” actually become more resilient to change. They try to tackle it head on. They are more open to ideas and willing to give them a go, because failure is part of life and you just move on.
These children grow up to have an Agile dominant mindset.

Its not only people that can have these types of mindsets. Organizations can too. It is not surprising. Organizations are made up of people.

But, all is not lost. People can change. Those with a fixed mindset can have an Agile mindset. You just need to want it.

So with Agile development in mind, the Agile mindset at its core is:

  • Thinking of your customer first. How can you make their life easier/better or what value can you give.
  • The willingness to try and learn new things.
  • Have the goal to improve yourself, your team and your colleagues and
  • Never be afraid to fail.

Thinking Of Your Customer

When I say “Thinking Of Your Customer” the question that comes to mind is “Who is your customer?”. The first and obvious answer is the people who use the product or service that you provide. These may be the general public or other companies. By thinking of the customer in this instance, you try to provide a product that is valuable to them. Value can be very subjective. It could be something simple that helps your customer accomplish a goal or it could be a complex.
For example, Facebook started out as a web site where University students (I’m Australian so I won’t say College – A College here is high school) stay in contact and share information. Google started out as a search engine because the founders didn’t like the current search engines that were out there. They thought that a good search engine would be valuable to others. Zappos wanted to see if people wanted to buy shoes online.
These companies started by adding large amounts of value to a small group of people. It wasn’t until later that they stared expanding and adding value for other customers.
The second lot of customers are your internal customers. These are other teams or other members within your team. Be they under you, your peers or your seniors. These customers, you help indirectly. For the people under you, there is the concept of “Servant Leadership”. Servant leadership is much different to the standard method of leadership which I will term “Command And Control”. With Servant Leadership, instead of telling people what to do as you would with Command and Control leadership, your job is to guide and grow your people. Give them direction and hen get out of their way.
You, as the leader have the big picture. So you give the team the goal to help accomplish the big picture. You do not tell them how to reach the goal, you leave it up to the team. If the team veers too far from the goal, you nudge them back toward the goal. You never ever tell them how to reach the goal. The reason for this is that it helps grow your team. The team becomes stronger because they make mistakes (and they will) but you guide them back. You never solve the problems for them, you need to let them solve the problems them self. Believe it or not, this makes for a happier team as the members then have full responsibility for reaching the goal. The autonomy to make decisions on how to reach the goal themselves. They also master the skills required to accomplish the goal. For those that are peers, you help make their jobs easier. Try not to send crap work. Share knowledge. For your manager, help them accomplish their goal.

By thinking of the people first instead of results, you grow your customer base, both externally meaning more profit, and internally meaning you have a more dedicated workforce.
One thing to remember though is that respect for one another can be gained very easily. It can also be lost very easily. The problem is that once it is lost, it can be very difficult to regain.

The Willingness To Try And Learn New Things

By simply having an open mind to try something new. By trying something new, you open your mind to new possibilities. A way to work better. A way to work faster. A way to improve quality. As humans, we try to find the one true or best solution. For some problems, this is the case.
These types of problems though in reality tend to be the simple problems. What font size is the best for me to read. What is the boiling point of water at sea level. These are like “Mount Fuji” type problems where the peak is the optimal solution.

photo credit: reggiepen Reaching Out via photopin (license)

For more complex type of problems, the landscape is a little different. There are peaks and valleys. One solution is at a peak, the dismal failure is in the valley. The problem is that there are many peaks. Some higher than others. The only way to reach another peak is via a different path.
These types of landscapes are like a “mountain range”. The only way to find out which peaks are the highest is to try different things. Different combinations or completely methods altogether. Even counter intuitive methods can bring surprising results.

photo credit: romanboed Sunny Mont Blanc via photopin (license)

For really complex problems. More like real life problems. We have the mountain range, but it shifts continuously. In other words, its waves. You may be high at one point, but if you stay still long enough, or short enough, you are in the valley of failure. The only way to continually remain high is to “surf” the waves. You have to continuously shift and change. What worked one day will not necessarily work the next.

photo credit: jijake1977 Rip Curl via photopin (license)

Companies like Google continuously try new things. They have great successes, Their search engine, Gmail but they also have dismal failures. Google Wave, Google+. Yet they continuously surf.

Peter Palchinsky a Russian engineer in the early 20th century summarized how to surf through his 3 principles.

  1. Seek out new ideas and try new things.
  2. When trying something new do it at a scale that is survivable.
  3. Seek Feedback and learn from your mistakes.

This leads us to our next section.

Continuous Improvement

Continues Improvement as the name suggests is well, improving continuously. Not every now and then. Not when you have the time. But always. Always looking for ways to improve. This on itself is hard. Paul Akers from 2 second Lean suggests everyone looking for an improvement of 2 seconds every day. His findings are that if everyone looks for improvements of at least 2 seconds, then every now and then, a significant improvement is found. Even if it doesn’t. Those little improvements build up over time. This in Lean terms is called Kaizen.
So instead of thinking “If it ain’t broke, don’t fix it” think “If it ain’t broke, fix it anyway”.
So the question now becomes, how do you improve? What is the definition of “improvement”. Well, its different for everyone, but for me and what I think it is in Agile is simplification. Simplify the process, simplify the program, simplify as much as you can. The best way I think to simplify something, is to subtract the complexity.


In Lean, the simplification process is done through the removal of what they call Waste. There are 3 major types of waste in Lean.

  • Muri – The waste of Overburden.
  • Mura – The waste of Unevenness and finally
  • Muda – The waste of Futility.

These wastes are further broken down into 8 more wastes.

  • Overproduction – This occurs when you create more than you currently need. When you over produce, you need to store the over produced product. This becomes
  • Inventory – Then you need to figure out how to move all your stock. This leads to
  • Transport where goods are moved from one area of the warehouse to another. Then you have to work out a process to keep track of everything. This is
  • Over processing. Your processes become more complex. Stock gets damaged. The damaged stock become
  • Defects. To fix the defects, your people need to move the stock back onto the floor, fix the defect then move it back into storage. This is a lot of
  • Motion. All the while, your customers are
  • Waiting for their goods. All the while your people are sick of redoing work. They want make things better, they want to be happy at work. But they can’t because they are not allowed to. They fell they have
  • Underutilized talent.

Notice how I put the 8 wastes into a story I have taken this queue from Paul Akers of 2 Second Lea. The idea being is that having a little story you can tell about the wastes. It helps you learn them, but also helps you understand them. its much better than just remembering an Acronym such as DOWNTIME.
Now these wastes are generally for the Manufacturing industry, but they are similar to what you will see in the IT space. Saying that, there is a list of wastes specifically for IT. I’m going to attempt a story here, but I don’t think it will be as good at the one above.

When you have so much work to be done, and its all done on the fly with no

  • Standards and Manual work, the priority of tasks keep changing. Do this now, no stop that and do this. You are constantly
  • Task Switching. This leads to
  • Partiality Done Work. Nothing really gets completed on time. Everything gets late. the customer is
  • Waiting for their software longer. Since it takes so long to get to the customer, and we are under the pump, we make mistakes, cut corners this introduces
  • Defects that need to be fixed. The buggy code goes back to development, then testing, then UAT again. Its constantly in
  • Motion. The software is so buggy, we introduce gated changes and procedures and other.
  • Extra Processess to prevent the issues.
    The deadline looms, Nothing is complete. Everyone stays back late into the night. Works weekends. Their
    -> Heroics is astounding.
    We finally ship. We planned everything up front, Did everything the customer initially specified. Oh no, they didn’t really need that
  • Extra Feature that we spent months building. It has no business value. It was just a nice to have.

Believe it or not, but over 90% of the work you do is waste of some sort or another. I know, it’s an outlandish statement, but this is part of the mindset. The hard bit is trying to remove that 90%. Most of the stuff we do we think is required. That is why we do it. But if you really really look at it, there are ways we can automate, remove or change our practice to reduce. Over time, you will find that you are doing the same amount of work quicker. In most cases significantly quicker. You will also find that you can do more in the same amount of time as you do one thing now.
It is through the reduction and or removal of these wastes which is at the heart of Agile. It is one of the methods on how you get faster. What? You thought that doing Stand-Ups, Sprints and so forth would make you faster? How would it? you are adding extra processes (a form of waste) if you apply it to the way you currently work without changing the way you work. You are actually making things longer. Just think about it.

Feedback loops

The other tool to help with Continuous Improvment is the Feedback loop.
This is a universal tool to improve. There are many feedback loops. I mentioned one earlier. Peter Palchinsky’s principles.
Another one that is synonymous with Lean is the Demming Cycle, or the PDSA/PDCA loop which stands for Plan, Do, Check/Study and Act.


Plan what you are going to do.
Do what you are going to do.
Check or Study the results from what you have done.
Act on the results of that Check or Study and feed that back into the next Plan.

Another type of feedback loop created by Eric Ries of Lean Startup is the Build, Measure, Learn loop.

You Build a piece of the product. Just enough to get a minimum working product.
Release to your customers.
Measure their responses to that minimum viable product.
Learn based on the measurements what the next direction will be, then Build the next iteration. Do this continuously.

Yet another feedback look is the Observe, Orient, Decide, Act.

Observe the situation.
Orient yourself based on the observation.
Decide What to do.
Act Then do it.

In Scrum, there is a feedback loop within a feedback loop. I will go through that in more detail when I cover Agile methods. Especially Scrum.

Now, there is no sure way you can eliminate waste, adding feedback loops and short cycles will help, but ultimately this is a trial and error process. The problem with trial and error, is that you have to be able to accept error. In other words, failure.

Not Being Afraid To Fail

The fear of failure is generally what holds people and companies back. They become cautious, slow down. Take the easy route. If you fail, you are seen as a pariah. Failure is stigmatized so it is avoided at all costs. Eventually you stagnate.
People and companies that embrace failure, look at it as a learning experience actually become more healthy. They learn and grow. Some companies actually embrace failure. For example, at Etsy, the person who broke the build the most times at the end of the year is awarded a 3 armed sweater. Other companies hold a celebration. The failure is celebrated as a learning experience. It is investigated and ways are found to prevent the failure from happening again in the future.
Yes you may fail again, but so what. It’s part of learning.
Those of us who are in senior roles, why are you there? Is it because you got everything right? How did you get it right? Or Is it built on a lifetime of failures where you learned?

Further along, I’ll go through a game you can play to help remove the stigma of failure from your team.

It is my belief, and thats all it can be as I’m not a psychologist or expert on human behavior, that by taking these 4 core principles of Thinking of your customer (people), Having a willingness to try new thing, continuously try to improve and finally not being afraid to fail, will give you the required foundation to have an Agile mindset.

If you find it hard to have this mindset, and it will be difficult to change, my advice is “Fake it till you make it”. The mere fact that you are trying to change will help you to change.

What Is Agile

I’m going to try to write a book. It will be the third attempt at a book. The first one I started over 8 years ago on Java CAPS testing. I got about 30 pages in and it needed up abandoned. My last attempt was at DevOps.  This was started at the end of last year. I got a couple of chapters in, but it ended up being abandoned as well as I got stuck on a chapter. No time, I kept concentrating on my blogging and working on my Six Sigma Yellow Belt. This time, i’m going to try to write the chapters as blog posts. This kills two birds with one stone. I get a blog post out and a chapter. So it may be a couple of weeks between posts,but I will try to keep at least one per week.

So, here is the first chapter in its current form. Subject to change before the book is generated.

What Is Agile


  1. Able to move quickly and easily.
  2. Able to think and understand quickly.
    Oxford Dictionary (Online)

If you do a search for “Agile” online in the Oxford Dictionary you get the following which is related to the Agile methodology

Relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.
‘agile methods replace high-level design with frequent redesign’
Contrasted with waterfall (adjective)

The contrast to Waterfall is that Waterfall does the design up front of the whole solution, then you develop the whole solution. Finally you test then deploy the whole solution.

Although the definition is correct, I don’t like the following:
The phrase software development which I have emphasized denotes that Agile is specifically for Software Development, but this is now not true. Agile methods and techniques are now no longer in the software domain. It is being used to make cars (Wikispeed), Law Firms (Lonely Planet), Education, even the US military uses a form of Agile for combat.
As for Project Management again which I have emphasized, it no longer is specific for this domain. Agile in the Software Development industry is used for day to day activities, as it is with the other domains I have mentioned above.

For me:

Agile is an umbrella term for a set of methodologies that developed originally in the software industry but are being adapted outside of this domain to formalize continuous improvement, simplification of tasks and iterative/incremental approach to work, with the goal to allow change and adaptation to happen quickly and easily with minimal disruption.

Even this sentence doesn’t quite explain Agile as I see it.

In this book, I want to go through exactly what Agile is – at least to me. How to have an agile mindset, how to implement agile – at least one of the methodologies, Scrum and some techniques on how to expand Scrum to get the most benefit.

Firstly, lets go through the history of Agile.

History Of Agile

If you are reading this book. You most likely work in the IT industry. Either a Software Developer, Architect, Project Manager, Manager or so forth and are curious about this new Agile thing.
Well, Agile isn’t that new. In fact Scrum, the most popular implementation of Agile techniques is 21 years old at the time of writing, but the methods of Agile and the thinking process are even older than that.

In fact Agile techniques have been used for a long time, it just wasn’t called Agile.
For example, the construction of the Empire State Building. The building was designed in 2 weeks. They had 1 year to construct the 80 story high building ready for opening on the 1st of May 1931. They designed the building “after” purchasing the site. Construction at its peak was at 4 and a half floors per week and over 500 trucks per day coming to the site. The trucks would come up, their load unloaded and placed where it was needed then and there. No waiting, no putting aside, just work. Remember, this was 1930, so no computers to schedule everything. It was all done by hand and worked out on the fly. Planning was done for the weeks worth of work. Not months in advance, they just didn’t have the time. Workers had a problem solving attitude. Every day over the scheduled opening day would cost the company $10,000 1930’s per day. so whatever they could do to save time, even if it cost money was implemented. For example, they had a miniature railway to bring materials.
To top it all off, the project was completed 12 days ahead of schedule. That is amazing!
These techniques were not even new at the time, it was just how buildings were constructed.
This wasn’t standard across all industries. In fact the mass manufacturing techniques developed by Henry Ford and the teachings for Frederich Winslow Taylor were the standard.
Fast forward 10 years and then you have World War II. Men would go off to fight and women would be the ones working in the factories. These factories needed to be efficient. They needed to make the armaments. weapons, bombs, planes, tanks even clothing for the soldiers as fast as possible so that they could be used for the war effort. The quality needed to be high grade. Who would want their sons fighting a war with substandard equipment, but had to be made cheaply. W. Edwards Demming was part of a 5 man team that developed the statistical methods that helped the manufacturing standards during World War II. When the war ended, the men came back and things started to follow they way there were done before the war. All the efficiencies developed with the women were abandoned.

Deming and his colleagues efforts were not unnoticed. General Douglass MacArthur asked Deming and his colleagues to help Japan with their national census with statistical knowledge. In 1950, the Japanese Union of Scientists and Engineers had been studying Walter A. Shewarts techniques for reconstruction and manufacturing and since Deming had studies under Shewart, he was asked to speak and teach. One of those students of Demings was the co-founder of Sony.

Demings work in Japan was revered. An award for Quality was given in his name, the Deming Prize. Unfortunately in his own country his name was unknown and remained so until the 1980’s.

Another company that took these teachings on board was Toyota. More specifically, a man named Taiichi Ohno. He took the teachings further and developed techniques such as Just In Time (JIT) and eliminating waste (Muda) and Continuous Improvement (Kaizen). He is also considered the father of the Toyota Production System.
Toyota had a reputation of quality cars that were manufactured cheaply, and this didn’t come to light in the west until Toyota started exporting to the USA. Toyota made cars cheaper, and of better quality that any of the US manufacturers and it had them scared. Even so, it still took them decades to take on board the learnings. When they did, the name changed. You couldn’t have General Motors saying for example that they used the “Toyota Production System”, so the name changed to “Lean” to reflect the elimination of waste. Or “Trimming the fat”.

About the same time that this was all happening, many software developers were looking at better ways to develop software. The Waterfall method where you work out the requirements up front, design the system, implement, test then finally release was starting to fray at the edges. Customers would change their minds once they saw how things were working. They were not happy with the final product as it didn’t do what they wanted or since projects lasted 6months to 2 years or longer, by the time the software was released, it no longer met the requirements of the business. Something had to change. Something lightweight was needed compared to Waterfall. Using inspiration from Lean, a lot of new techniques were developed. DSDM (Dynamic Systems Development Method), (RAD) Rapid Application Development, Crystal Clear, (XP) Extreme Programming and Scrum.
Many of these techniques are still around over 20 years later, but the most common of these is Scrum.

In February 2001, seventeen software developers met together at the Snowbird resort in Utah to discuss lightweight software development techniques. Among those were the developers of Scrum. Jeff Sutherland and Ken Schwaber. There they published the Agile Manifesto.

We are uncovering better ways of develoing software by doing it and helping others do it. Through this work, we have come to value:
Individuals and Interactions over process and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This is the moment when Agile became a thing.

Since then, we have had other Agile methodologies developed such as Kanban which was developed in 2010 by David Anderson and is modeled on the Kanban system used by Toyota to track the usage of parts and components during the manufacture of cars and Lean Software Development developed by Tom and Mary Poppendieck and DevOps which started Patrick Debois, John Alspaw, and Paul Hammond.

Many of the Agile methodologies have the following in common.

  1. The elimination of waste
  2. Continuous Flow of work
  3. Continuous Improvement
  4. People

Why Go Agile

There are many reasons why people start to go agile. These usually are

  • A CEO/CIO/ or some other level manager sees another company using Agile and decides that they should use agile too.
  • Agile is the new hot thing. We should do it!
  • My manager told me that we should use Agile.
  • Agile will make us go faster, reduce costs and increase quality.
    The one I like the best…
  • I want to improve and get better. I’ve heard Agile can do this.

Whatever reason you want to go Agile, I would like you to know what it involves which is why I am writing this book.
Agile can be easily implemented incorrectly. In fact, most companies that implement Agile get it done incorrectly because they do not research what they are doing. They see practices and just follow without understanding. The beauty of Agile is that even in these cases, there is some value still to be gained. The problem is that the value is only a small fraction of what can be accomplished compared to when Agile is implemented incorrectly. I will go through the pitfalls of going Agile later in the book.

Just remember, Agile isn’t a silver bullet. It can bring you all the above, but what it does do is let you know when something isn’t working sooner. What you do with that information is up to you.


Overwhelmed Part 2 – Teams

In my previous blog post, I talked about multitasking and how to handle it by using pull instead of push. In this post, I would like to expand on the concept to teams and my thoughts on how to optimize.

Now for this, I’m going to assume you are wanting to use Agile methods, but this could possibly work with a staggerd waterfall approach.

The Basics

In order to increase flow, you have to start at the basics.
Lets say you have 4 stages before your piece of work goes into prod.

Each piece of work goes through each stage.

As you have multiple pieces of work, each piece will go through each stage as it is pulled through the system to completion.
Since I’m assuming that you are doing Agile, each piece of work should take no more then a couple of days to complete. So initially, Test should be waiting 2 days before it starts testing. Stage/UAT should be waiting 4 days and nothing should be going to prod until about day 6. Now I’m talking stages here – not people. This system works if you have one person doing all 4 stages or if you have separate people for each stage.
Again, this is highly speculative, things may vary from situation to situation but I’ll get to that later.

Now, does this model remind you of an an assembly line? If so, that is exactly what we are trying to model here. Once we have the assembly line running with features going and everyone is working on something, our next step is to try to achieve flow.


Flow just as the name implies is that the work flows from one stage to the next without stopping. Now I hear you say, that is impossible to achieve – well that is not the point. The point is to try to achieve that goal. If you don’t try, them you definitely will not reach that goal.

Now I hear you say, work doesn’t flow through evenly through. There are variances. One task may take 2 days. Another will take 5 days at the same stage. Another half a day. Also, Testing may only take a half a day for something that took 2 days to develop, or vice versa. I will go through that later, but I’m more interested in averages, but when there isn’t an average, the largest time will do.

Analyze The Variance

This is the next step. Analyzing the variances.
In order to do this, we need to identify the time it takes for a feature to travel within each stage, and how long it waits between stages.
The time it takes within each stage helps us identify bottlenecks.
Say for example we have the following times on average for each stage.

Here, the Testers are staved for work. The same with UAT and well, we’ll just say migration to prod is the same.
In traditional manufacturing, the way to control flow is to limit the work to the slowest point. In this instance it is development, which takes 5 days. Any project manager with half a brain will tell you this isn’t acceptable, and they are right. The throughput is too low. So how do you increase the throughput?

Increase Throughput

One way is to increase the number of developers.
Now for our example we have developers releasing a feature every 2 days.

The Testers are now overworked. A backlog occurs before the testers and will keep occurring. This in itself is not a bad thing, but it needs to be managed. How can you do this, again, with Agile, cross functional teams, if the buffer for test gets too large then Developers can move across to the Testing stage and do testing. When the buffer drops down to a more manageable level, they can move back to Development.

What if increasing the number of developers isn’t an option but you still need to increase throughput. Another way to increase throughput is to identify tasks in the bottleneck stage and try to remove any non-value added work.
This in itself is a lot more difficult to do, but it is significantly cheaper. You have to really think what the developer is doing, determine if the step they are doing is really required or if the step can be done differently or more efficiently. It will take a lot of work, but ultimately it is cheaper for the simple reason you are not paying for another resource.

Now what I have said above isn’t new. Its been talked and implemented in the manufacturing world for at least the last 40 years and is known as part of the “The Theory Of Constraints”.

I know what you are thinking. It’s only a “Theory”. It’s just made up. Well, the person who came up with the “Theory” was Eliyahu M. Goldratt. A physicist, and in physics, a Theory is backed up by empirical evidence through many experiments. It is not something you just make up. It is only called a Theory because in physics as well in the sciences, there is always the possibility that the subject can be proven or disproved by a better process, equation or “Theory” that has been proven by empirical evidence. Goldratt applied the same principles to his “Theory of Constraints”.

In the book “The Goal”, Goldratt used an analogy of boy scouts walking along a track to describe this system and I’m going to steal the same analogy here.

Imagine a line of boy scouts walking down a track. Some boys are faster, and some are slower. The fast boys if they continue walking at their own pace will end up going so far ahead, that you can’t see them.
The boys that are too slow, end up falling behind and keep falling so far behind that you cannot see them either. So what is the solution. Goldratt used a proverbial rope to tie the boys together. The boys that go too fast get tugged back by the rope.
The boys that go at normal pace also get tugged by the rope. They all get tugged by the slowest person. There is no point pulling the last boy along as all you would be doing is dragging him along. Not a nice thought. So everyone walks at the slowest persons pace.
The only way you can get the whole troop to get faster is to increase the speed of the slowest person. The bottleneck. Goldratt called this “Drum, Buffer, Rope”.
Drum – The pace is set by the slowest person/process. ie, everyone follows the same rhythm of the drum.
Buffer – The slack in the rope. There needs to be some buffer to be able to handle outages and variances. Not too much buffer, nor too little. Experimentation will help determine the best level.
Finally, the rope. The rope implies a pull system. Work is pulled along the line rather than being pushed. As I mentioned in my previous post, this is how the Kanban system works. It makes sure that no person or process is overworked.

Goldratt had 5 steps to achieve this.

  1. Identify the bottleneck. I’ve described a couple of methods to do this above, but the only way you can identify a real bottleneck is through single piece flow.
  2. Exploit the bottleneck. What does this mean. Try to make the bottleneck faster by finding ways to quicken the work. Eliminate waste or try doing something differently to see if it does it quicker. Also make sure it is never staved of work.
  3. Subordinate the bottleneck. This is where you slow everything down to the bottleneck speed.
  4. Elevate the bottleneck. In this case, if you still need to increase throughput, add more resources.
  5. Finally, repeat the process fort the next bottleneck.

The steps are simple, but implementing them can be extremely difficult. Half the time you don’t know what you are doing, but this is where experimentation comes in. Keep trying new things, but remember Peter Palchinsky’s principle:

  1. Seek out and try new things.
  2. when doing something new, so it at a scale where failure is survivable, ie. not at the cost of your productivity or at a monetary cost so great that if it doesn’t work your company goes bankrupt etc.
  3. Finally, seek feedback and learn from your mistakes as you go along.


Now, another thing I mentioned previously was recording the time between stages. In other-words, how long a piece of work waits before it is worked on.

This diagram is a very rudimentary value stream map. A value stream map shows how long it takes for a piece of work from conception to fruition to start giving value. When does a piece of work start giving value in software? When it is being used in production.
Here we have the times a piece of work waits before it is processed by the next stage. Those of you in Agile probably don’t see times like these, but with Waterfall, you definitely do. In this made up example, for a single piece on average to get to production there is 78 days of waiting! with only 6 1/2 days of active work being performed on this piece.

That means that it takes 84 days in this instance before a piece of code is helping your company make money. The shorter we make that time, the sooner the business gets the value, but also the sooner we are able to find out any problems and address them.

Now normally I would end here, this article gives some of the building blocks to improve throughput and increase speed, but as these techniques are simple and for quite a number of people seem to make sense, I thought I would go through a trap that I’ve seen.

False Flow or Multitasking By Stealth

I’ve seen the following done with some variances, but doing something similar using a Kanban Board for a team starting out with Scrum.
Here you have a piece of work flowing through the Kanban board, but its not actually a piece of work, its a task. A development task. Here, development tasks are being batched up, but because there is one card per task – not per piece of work, there is no flow although the movement of cards gives the illusion of flow.
I’ve also made it quite obvious here by naming the tasks “DEV”, but this is not always the case.

The correct way to implement is to have the work all encompassing of all stages of the development cycle. The individual tasks for each stage linked to the piece of work. This highlights when you are doing proper flow as opposed to false flow.

Using these techniques continuously over time, you should see improvements in throughput.

Please let me know your thoughts of this subject in the comments. Am I full of it or does this make sense. I’m very interested to know.

An Agile Story…Sort Of

This article first appeared on the Scrum Alliance Community Articles.

One of the most inspirational Agile stories I have heard isn’t really an Agile story. It’s the story about the New United Motor Manufacturing, Inc. (NUMMI). It’s a Lean/Toyota Production System story about how collaboration between two enterprises can lead to great things.

In the beginning . . .

The story starts at a General Motors (GM) manufacturing plant in Fremont, California. GM had been running the plant since the 60s, and by the early 80s, it was one of the worst auto manufacturing plants in America — not only in terms of quality of the cars manufactured, but also in terms of the workforce as well. The relationship between the workforce and management was, to put it mildly, adversarial. The workforce was unionized, so it was difficult to fire anybody, and management wanted throughput increased. Over time, the relationship degraded to the point where the behavior was careless and unprofessional.

Management’s hands were tied by the unions, but they made sure that the work got done. Why did things degrade to such a point? To put it simply, the workers had no pride in their work. It was only a job.

The cost of stopping the line

What was there to take pride in? All that was drilled into the workers was that the line had to move. If it didn’t, it would cost the company $15,000 per minute while it was down. If someone was fired, then the workforce would walk off the job, causing the company significant losses. Management pushed and pushed. There are accounts of people falling into the pit, yet they would not stop the line. If someone was injured, they would not stop the line unless it was an emergency. Find a defect, mark it with a slip of paper, and send the car on its way under the mindset, “It will be fixed later.”

And, boy! Was it worth fixing problems later! The overtime was lucrative. Be it a wrong bumper bar put on the car or something wrong under the dashboard, it was worth fixing later, even if it meant ripping out the entire dash, fixing the problem, and putting it back together. The dash would never be right again, but neither the workers nor management cared at that point. It was the customer’s problem. The fixing aspect was standard practice at the time, and the car quality suffered for it. (I remember that here, in Australia, there were problems with Holden Commodores. Car doors would not sit right, and “lemon laws” were introduced.) Eventually GM had enough, and in March 1982, the plant was closed. The entire workforce was laid off.

The partnership

Meanwhile, Toyota was trying to break into the American market. It entered negotiations with GM. GM would supply the facilities, and Toyota would teach them the Toyota Production System. Toyota was making cars more cheaply then, and of better quality than any American manufacturer could. So for GM to get the “secret sauce” was considered lucrative.

In 1984, the Fremont plant was chosen as the location, and the venture was called NUMMI. As part of the deal, more than 85% of the workforce that had been laid off two years earlier had to be rehired. Charles Duhigg’s book Smarter Faster Better: The Secrets of Being Productive in Life and Business recounts the story of Rick Madrid, one of the line workers who was fired from GM and rehired by NUMMI. Madrid recalls that after he was hired, he was sent to Japan to see how things worked. When he reached the Toyota plant, he remembers seeing everything pretty much as it had been in Fremont, but more clean. He recalls thinking, “Why the hell did they send me all the way here to see how things are done when it’s almost exactly the same as it was done at home?”

And then something happened: He saw a worker put in a bolt for a car door incorrectly. Nothing unusual about that; it was a common problem. But what happened next blew his mind away. Instead of marking the defect and then carrying on to the next job, the worker raised his hand and pulled on a cord. Lights flashed and music played. The worker then removed the bolt, and the line resumed. The worker’s supervisor arrived and asked questions. The worker ignored him and carried on, while giving his supervisor orders! Had anyone done that back in Fremont, they would have been decked.

When the car had reached the end of the station, something amazing happened. The entire line stopped. Another manager came up, but instead of yelling, the manager laid out a new bolt like a nurse lays out surgical instruments for a doctor. The worker then ordered both managers around. During this time, at every other station, workers were double-checking parts they had already installed. Rick was thinking that this was costing Toyota $15,000 per minute. Once the bolt was back in place correctly, the worker raised his hand and pulled the cord again. The line then resumed, and everyone went back to work. Rick was floored.

That scenario wasn’t the only surprise Rick Madrid saw while in Japan. Halfway through a shift, he observed a worker, who had an idea for a new tool to help him with his job, tell his manager about it. The manager went off to the workshop and, 15 minutes later, came back with a prototype. The two refined the tool for the rest of the shift. The next day, everyone their own similar tool.

When Rick got back to the States, he told his fellow workers what he saw. They didn’t believe him. What Rick saw was Toyota’s philosophy that the person doing the work is the expert at what needs to be done. The individual is in charge when something goes wrong; it is his or her responsibility to fix the problem. It is management’s responsibility to support the worker in fixing the problem. It is management’s responsibility to help, guide, and support the workers in doing their job, not just to order them about. Also, Toyota hates waste, and it’s a waste to not exploit everyone’s expertise.

Applying Toyota’s philosophy back home

When the Fremont plant reopened, those who returned to work didn’t go back to their old ways. They were too scared. They needed their jobs. Therefore workers didn’t start pulling their cords when things went wrong. This was not good, as Toyota’s philosophy is to fix problems at their earliest point when they occur — that is, at the time the problem is identified.

A month after the plant opened, NUMMI’s president Tetsuro Toyoda was touring the facility when he spotted a worker who had put in a taillight incorrectly and was struggling to get it back in. He looked at the man’s uniform for his name and said, “Joe, please pull the cord.” The president, Joe’s supervisor, and his manager were all watching.

“I can fix this, sir,” said Joe.

“Joe, please pull the cord,” repeated Tetsuro. Up to now, the cord had been pulled only three times since the opening of the plant, and one of those times was by accident. Everyone was afraid to cost the company $15,000 per minute.

Joe repeated, “I can fix this, sir.”

Tetsuro took Joe’s hand, raised it to the cord, and then pulled it. Joe was shaking. The two men then fixed the taillight and pulled the cord again. From that point on, workers started pulling the cord more often. Now, you would think that this would have been bad for Toyota. However, in a typical Toyota factory in Japan, the cord is pulled more than 5,000 times per day. Toyota’s philosophy of fixing problems when they occur has been found to be significantly cheaper on average than fixing the defect later. That is why pulling the cord is encouraged.

It didn’t take long, about six months, for the Fremont plant to produce cars of the same quality as those from a Japanese plant. These same workers, who two years earlier were causing all types of mischief, were taking pride in their work. In WBEZ’s This American Life broadcast and other interviews, Rick Madrid remembers fondly his time at NUMMI. He took pride in his work.

It’s a Scrum story, after all

Given that Scrum, specifically, and Agile have their origins in the Toyota Production System, it is my opinion that a ScrumMaster and a product owner have the responsibility to support team members so that they can do the best they can. If that means being ordered around by a team member to fix a P1 issue, resolve a blockage, or even give the team some tough love to point them in the right direction — basically anything that will help them succeed — then so be it. Anything short of that, and you introduce the possibility of failure. When workers are empowered to do a good job; aren’t struggling against impediments; and are given the responsibility, the right tools, control, and support, they will take pride in the work and be more productive. This, in my opinion, is what Scrum and Agile are about.

GM had sent 16 rising stars to start the NUMMI plant. Once the plant opened successfully, the 16 were ready to spread the word throughout GM. They were motivated; they wanted to change the world. But GM put a wet blanket over that spark. They didn’t know what to do with the 16. Some became frustrated over time and eventually quit. All that knowledge was lost. It took GM more than 15 years to implement the lessons learned at NUMMI, but by then it was already too late. In 2009, in the middle of the global financial crisis, the auto industry was all but destroyed. The fallout is still being felt today, with the closure of car manufacturing here in Australia. GM became the largest industrial bankruptcy in U.S. history. The NUMMI plant closed a year later, in 2010, although it has recently reopened as a Tesla plant.

Rick Madrid retired in 1992. His hat and badge are at the Smithsonian in the American Enterprise exhibit.


Thoughts, Tutorials and Learnings specifically with regards to Agile, DevOps and SOA/EAI