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 and I finally got round to reading it a few months back. 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 outputs and metrics 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 delivering 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?

On the one hand, following a period of intense change, budget spend and organisational upheaval… your department will have quicker cycle times to market, be more predictable operationally, produce higher quality software, have better working relationships with its customers and will be more adaptive to changes of business objectives and requirements.

On the other hand, all the department’s problems that you know currently exist will become very visible and transparent very quickly. All those skeletons in closets you’ve been dampening down, or battles you’ve been fighting to secure funding will rise to the top of agendas. If you’re looking for an easy ride or at least some calm seas, don’t start agile.

Agile methodologies expose the weaknesses in your value stream of delivering software, it exposes poor infrastructure, asset management, governance, processes, delivery, and most fundamentally, it will expose weak people…

Agile not only highlights these problems, it rubs your face in it by reporting all the dirty linen as impediments and waste, and directly attributes slow delivery to the specific problem. These could include lack of testing environments, or poor VM performance, or production support interruptions, or no automated tests, or poor architecture etc, etc, etc.

Not only that, but if you walk this road, your department will start to judge you and the success of the agile initiative by your personal ability to secure funding and remove organisational impediments i.e. your executive skills.

So before you start down this road I think the first question for a CIO should be “Should building software be a core competency of this company?”

If the answer is no, then maybe the answer lies elsewhere in out-sourcing your software development to a good agile house. However, if there is a need for a strong software development capability because technology is fundamental to your business strategy, and the board of directors are in agreement, then agile is the best approach. This is because Agile development, specifically Extreme Programming, is one of the the most disciplined approaches to software development in the world.

So, let’s assume you’re a pro-active CIO/IT Director, with a supportive board behind you, ready for the challenge… Where do you start?

Fundamentally, you’re initiating a change programme to completely overhaul the way your company builds software. Don’t fool yourself into thinking you’re doing anything less!
The change will affect everyone involved, your consumers, your internal customers, finance, marketing, HR, Operations and your own area.

Forget the Hype – Moving to Agile is a large organisational change programme that will overhaul your approach to software delivery.
Make no mistake, it’s about people, its about change and therefore we all know it won’t be easy!

The good thing is that each change is incremental, there’s no big bang, you just have to keep removing barriers, impediments and keep the budgets going.
It’s continuous improvement, not revolution.

You’re going to need help!

There’s plenty of agile consultancies out there at the moment flooding the market, but fundamentally I think you need to look for experience and named resources to cover 3 fundamental areas; the organisational change, the delivery process and the engineering practices:

1. Experience of managing organisational and cultural change including the stakeholder communications, business case creation, and internal marketing. And be able to demonstrate the energy it requires. (regardless of if its agile or not).
2. Delivery management expertise, commonly Scrum is the predominant process adopted by agile teams. So look for Scrum Practitioners or Coaches with at least 5 years experience and references to back it up.
3. Engineering Practices – Extreme Programming expertise, automated tools usage, and deployment specialists… basically strong agile engineering experience.

With competence in these 3 areas, you won’t go too far off track but do not underestimate the need for the Engineering Practices as it is fundamental to the quality of product and reducing cycles times to market.
And as with all change programmes… this will take months not weeks.

“The propensity to exploit Agile delivery to achieve business success is directly proportional to the capacity of a company to change and continuously improve.”

As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines.

And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders.

But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager:
· The Iron Triangle
· The Role of Project Manager

The iron triangle of cost, time and scope (or quality) is typically the responsibility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group.

Previously on traditional projects I owned and was responsible for this triangle and reported to the project board if any risks or issues were likely to break the tolerance levels.

In a traditional project a deliverable-focused approach to planning is used (Prince = configuration plan), whereby all the intermediate work products and “pieces” of the solution are identified and a plan drawn up to show the route to delivery usually utilising a gantt chart or network diagram. From which timelines, resources, and costs can be identified and critical path analysis and risk management conducted.

Now scrum doesn’t throw this all away… rather we open out the Iron Triangle and share responsibility across the team, and recognise that no matter how well we plan the project, things will change, and problems will occur.

So… lets make time and cost fixed for a set period, say 4 weeks.

So the resources I’ve identify for the project will work for 4 weeks together which will cost a fixed price…

Now, let’s not set the scope as fixed, but accept that scope is variable within this part of the project.

The amount of work and quality of deliverables achieved within the fixed cost/time axis will depend on people… it will depend on the team’s productivity and practices. Let’s remove focus from the iron triangle established at the beginning of the project, and instead focus on making the team as efficient and productive as possible.

So the role of the Scrum Master is one of maximising the productivity of the team by removing obstacles, inspiring, motivating, and ensuring the scrum methodology is followed.

The responsibility for what is built (the scope) is then given to the business. Scrum identifies a Product Owner, a business stakeholder who has a list of the requirements for the project prioritised by business value.

Maintaining quality levels can be aided through the use of agile development practices such as automated tested, continuous integration and refactoring. http://www.martinfowler.com/articles/continuousIntegration.html

The project team select the highest priority requirements (as specified by the product owner) they think they can build in 4 weeks. So time is fixed, cost is fixed, the highest priority business needs are defined, and how much is achieved (scope) is based on the team’s productivity level.

So whereas PMs own the Iron triangle and spend their time, directing, planning, mitigating, and monitoring progress, Scrum Masters give the responsibility for the scope of the project to the business, set time and cost as fixed, and focus their efforts on the productivity of the team.

The team is responsible for delivery, the business defines the direction or scope, the scrum master helps the team meet its objective for the 4 weeks.

The role change from PM to Scrum Master is not easy… releasing control and sharing the responsibility with others can be a little disconcerting. However, I’ve seen at first hand that the productivity gains in adopting this approach are impressive.

The business sees its highest priority requirements built and delivered every 4 weeks. The team continually improves and increases its productivity levels, and every 4 weeks everyone knows exactly how far the team has progressed because the software is there for everyone to see, test and review.