The Machine that Changed the World

First of all, I apologise for the length of this blog, but there's some serious stuff to be said!

The Machine that Changed the World by Womack, Jones & Roos
This is a book that has been on my reading list for a few years. I finally started it last week, and will probably have finished it by the end of next week. It's quite brilliant! Hard going at times... but brilliant.

A historical view - the story of the car manufacturing industry from Henry Ford to Toyota - from the creation of the mass production process in the early 1900's to the lean production process of Toyota in the 1980's.

For anyone interested in agile development or lean thinking, this book should be on your list.

Insight and parallels fly off the pages at you and I am finding that history is repeating itself within the agile movement. There are strong parallels between the problems faced by car manufacturers to adopt lean production, and the problems faced by IT departments / corporations in adopting agile or lean software development.

And at the heart of the entire book are the fundamental philosophies of lean thinking which resonate strongly with the agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Matching Observable Behaviours, without Understanding Underlying Concepts
One of the key insights I've identified throughout the book is that companies attempting to adopt agile are making the same mistakes that western car companies made in trying to adopt lean.

Example 1:
At Toyota:
Within the lean supply chain, Toyota had a "just in time" approach to supplier fulfilment. This meant that Toyota only needed more parts when they emptied a box of parts, and therefore an empty box returned to the supplier WAS the purchase order. So Toyota only order what they need, and have hourly cycle times.

Western companies:
By observing the Toyota process, what western car companies saw was not the lean process, but the observable behaviour of suppliers conducting multiple small deliveries of parts on a daily or hourly basis. So western car companies got their suppliers to do the same i.e. delivery more frequently in smaller batches. Now for the car company this had the advantage of reducing inventory... but instead of removing the inventory from the supply chain, rather they pushed the costs of more frequent delivery and inventory onto their suppliers.

Example 2:
At Toyota:
A car consists of around 10,000 parts and various car companies (assemblers) manufacture a certain percentage of their own parts and "out-source" the rest. Toyota in the 80's was about 37%, whereas GM was 70%.

Sourcing these parts externally is an expensive, protracted process, so Toyota created a "tiered" structure where they dealt with a few hundred suppliers that provide a specific system for the car and the Tier 1 supplier then manages their out-sourced parts themselves. The approach is collaborative and in partnership, and in addition to this Toyota invests in the supplier companies, owning between 10-20% of these Tier 1 supplier companies.

Western companies...
Typically western car companies had about 1500-2500 suppliers to a car, and at one point GM employed 6000 people in their purchasing department. They made the observation that lean car companies had smaller numbers of suppliers and by having smaller numbers their purchasing costs could be lower.
So they reduced the number of suppliers... But importantly, they didn't change the relationships - they just extended the contracts from an average of 1 year to 3 years and continued to measure the value of the supplier by cost and defects per shipment. In contrast to Toyota, they did not collaborate and try to make continuous improvements to the people, process and technologies across their supply chain.

Supplier Behaviour

Highlighting this lack of understanding of fundamentals, a western supplier won a contract with a lean car company and observed that quality standards were the route to maintaining the relationship. This western component supplier focussed on delivering high quality parts, and once it established itself in the relationship tried to increase its prices. The reason for this was that it was unsustainable for this company to maintain the quality level of products delivered.

This for me, highlighted the underlying problem perfectly, i.e. aiming to mimic the output without fundamentally changing mindset, processes and the culture of the company and its relationships. This supplier did achieve the quality goals but at what cost?

Agile Programmes are Copying Observable Behaviours, but not Changing the Fundamentals!

Hopefully, from the examples above I have clearly articulated the problem western car companies faced in the 1990's in adopting lean production processes. They were observing and copying behaviours without understanding the fundamentals and making change happen.

I believe that history is repeating itself for companies trying to adopt agile practices. The fundamentals are not right. Here's a few key areas where companies are trying to adopt agile practices by mimicing behaviours but failing to grasp the fundamentals

Lack of ability to change
Fundamental and at the heart of agile practices is an empirical process. Building software with multiple feedback loops, where continuous reflection and improvements are made.

In order to support this philosophy, everyone from developer to CIO, should be focussed on impediment removal, retrospectives and continuous improvement activities.

An agile programme shouldn't be a "planned" activity, it should be an entity focussed on helping teams to become more productive, more innovative, and more efficient at delivery business value through technology.

The agile programme should therefore be driven by the needs of the individual software teams whether its environment provision, training, process change, governance change, organisational change - whatever is at the source of an impediment, defect or element of waste.

By focussing on creating a culture of continuous improvement, companies will become "agile".

Relationships over Contracts
Toyota has often been quoted as stating that transforming to a lean organisation takes 10-12 years. I believe them. I'd also add that transforming a company from traditional to agile development will take years not months.

So what relationships do you want in place if you know you're embarking on a 3-year change programme? Long ones!

Therefore supplier relationships need to be fostered and framework agreements put in place that encourage a collaborative continuous improvement process, with transparency of costs AND profits where both parties can profit from the joint activity.

AND a key change for the organisation is to focus on the retention of staff, even if this means significant pain! Software development people are knowledge workers, and when they walk, the knowledge walks.

Still Measuring Against Cost and Time Instead of Demonstrable Value
Even relatively strong agile teams are still subjected to time and cost deadlines. The purpose of software development is not to deliver to time and cost, the purpose is to deliver business value - to help the business meet opportunities and threats in the marketplace through the provision of technology.
Companies need to learn and adapt and find a way to measure the success of projects not on hitting deadlines or getting it live, but delivering business value. There are plenty of ways to do this, but changing executive mindsets is not easy and individual teams need to build enough trust with their executive to be able to work in this manner.

Still Structured in Functional Departments Instead of Value Stream Teams
All the agile methodologies are focussed on adding incremental value, of constantly focussing and business value... So why aren't organisations that have been "doing agile" for a couple of years structured on providing value to customers.
Teams need to have the skillsets to create an increment of value within the company's value stream. This does not mean a BA function, Test function, Dev function, PM function, Infrastructure function etc.

Still planning portfolios in yearly cycles instead of responding to customer demand
How many commentators do we hear say that technology changes every 6 months, for the web its faster! So why do companies persist with annual portfolio planning? I can understand it for a piece of work that will take multiple years, and then, only if broken into incremental business value. Most work is not a whole year, most opportunities in the marketplace require rapid delivery, and annual portfolios are not the answer.

The Burning Bridge
If you're still reading this, congratulations I'm impressed and I've saved the best until last. My final observation is probably the most poignant and may well be at the heart of the problems of implementing agile.
All the innovations that Toyota made, that collectively became known as Lean Thinking were forced upon them.
Toyota had to evolve and had to change. They were being threatened by US imports, did not have the capital to copy the US system of manufacture. They also had union issues which resulted in Toyota's "job for life" contract where all their employees were guaranteed a job for life. This meant that employee salaries became a fixed cost, and therefore they needed to "sweat the asset" which means pushing more responsibility towards the coalface and reducing management heads.
In a competitive market with considerable constraints they needed to constantly reduce costs in order to make a profit and build consumer trust - there was a compelling need for change otherwise they wouldn't exist.

Most change management books and guru's talk about and allude to "Creating the Burning Bridge". Scaring everyone enough so that they will feel uncomfortable and see the need to really change." And lets be honest, if you're making profit and fairly comfortable, why change?

Thoughtworks pretty much established its business by taking on failing projects, because when something's so bad, maybe you'll be willing change things and do things differently!

This may well be the true reason why significant and continuous improvement is eluding agile teams.

Agile change programmes need to create the burning bridge, and then spend their efforts removing impediments, actively working on retrospective data and continously improving the organisation.

Human nature is getting in the way!
Evolution through fight or flight, but what if there's no impending threat?