Most organisations that I come across that introduce Agile techniques focus on a set of tools and practices that are applied at a working level only - test driven development, continuous integration, stand-ups, user stories etc. Even the best organisations that I get to work with only focus on the next level up and start to change governance processes, business engagement models, financial controls and other surrounding process infrastructure. I’ve only had the pleasure of working with one organisation where they changed the IT organisation from the top down as well as the bottom up. Guess which model was the most successful?

If we think of our IT divisions as socio-technical systems that our managers and leaders control, it becomes more apparent why any change has to encompass the whole organisation. Here’s an example of what I mean…

An Agile team have been happily working together for a number of weeks and are approaching a release of the application. In the final build the tester notices a few defects that have been missed until this point and highlights them to the developers and the customer. The developers decide that there is about one weeks work required to fix them and that the release would need to be delayed. The customer doesn’t feel that fixing the defects is worth one weeks wait so asks the team to deploy the application. Unfortunately the tester has an incentive that hasn’t surfaced until this point Read the rest of this entry ?

A few weeks ago I was lucky enough to spend a week in Toronto at the Agile 2008 conference. Here’s my summary of proceedings…

Agile 2008 Summary

• Something like 62% of the attendee’s were new to Agile.
• The race is on to monetise Agile! Oh dear.
• The Agile community is growing both in terms of expertise and adoption.
• There were a huge number of presentations on Lean and related topics - it’s a growth area.

Two areas of focus seem to be emerging beyond applying tools and techniques at a team level. The first is the development of models to introduce Agile processes to the enterprise in a structured way. The second is scaling Agile processes to an enterprise level - there seems to be a growing recognition that only introducing change at a team level is not going to cut it in the long term.

One gem of information came courtesy of Sue McKinney, a VP in the product division of IBM. Sue and her team started to introduce Lean concepts in 2005 across a number of teams (including Lotus Notes & CICS) with some help from the Poppendiecks. Sue stated that to date their efforts have saved them $90.6M (USD)!

The Wisdom of Crowds - James Surowiecki (Keynote)

James delivered a really interesting keynote that seemed to be a one hour summary of his book The Wisdom of Crowds. James explained that under the right circumstances the collective opinion of a crowd can be far superior to any individual expert within it. The story he told began with a chap called Sir Francis Galton who developed a social philosophy called Eugenics. Apparently Galton was a big believer in the ‘individual expert’ until an experience changed his mind. One day he was at a village fete and observed a competition where folk were guessing the weight of a cow - the closest guess got to take the cow home. Galton somehow got his hands on all of the entries following the competition and found that the average of the entries was better than any individual guess. He repeated the experiment and continued to get the same results.

James went on to explain that this is a consistent phenomenon, however some criteria are required to make it work Read the rest of this entry ?

I’ve made a few minor changes to the site so that I can add more content. I’ve replaced the ‘Agile Glossary’ with a ‘Presentations’ tab in the main navigation at the top of the site. You’ll find all of my presentations (well, almost all) available for download.

I’ve also added my most recent ‘Lean Techniques for IT Professionals’ presentation in this section. I’ve had quite a few requests for a copy of this deck so you’ll find the full version available here. Enjoy.

In Lean Ops we made a mistake. We looked at what we thought Lean organisations were doing, we read the books and we assumed that Lean was all about applying the things that we saw and read. We spent time introducing pull systems, kanban processes and just-in-time and for a period we got improved results. We never got the breakthrough results we hoped for and when we turned our backs things went back to the way they had always been. Why?

When we took a second look we realised our mistake. There is a deeper, less tangible philosophy embeded within Lean that focuses on people, the systems we place them in and the behaviours these systems encourage. It’s more difficult to understand than the tools and practices and it’s much, much harder to introduce and encourage.

One of my Lean mentors introduced me to an article a number of years ago to try to help me understand this deeper issue. The article is a seminal Harvard Business Review piece by Ralph Stayer. It’s called ‘How I Learned to Let my Workers Lead’. It doesn’t mention the term Lean once and you’ll find nothing about A3’s or single piece flow, yet to my mind it is the single most complete document I’ve come across for distilling what Lean is really all about at its core.

Deming understood that as leaders and managers our roles are to create the right systems for our people. I think he put it best when he said “A bad process will beat a good person every time”. The Stayer article explains the leap of faith we have to take as leaders to create new systems where the people can determine the process.

In Lean Ops we missed this deeper philosophy. We focussed on the tools and when they didn’t work we just tried harder to enforce the application of the tools. The irony! We went through ‘The Tool Age’ and emerged the other side with a new understanding of the challenge we faced.

So what? Well, I’m at Agile 2008 in Toronto at the moment and one of the hot topics is Lean. Fantastic! I think this is completely the right direction for IT to go. The challenge? A lot of the presentations are focussed on tools and practices like kanban systems, A3 reports and just-in-time. We’re going to apply them and get short term results but there won’t be the breakthrough we’re looking for. And then we have a choice. We can try harder doing the same things, we can abandon Lean and write it off as a failure in IT or we can continue on our learning journey. I hope that we’re on a journey to the point where we realise that we have to change the structure of our IT divisions, the way we incentivise our people and the things we measure. But we’re not there yet.

Welcome to The Tool Age. Where do we go next?

I’m currently lucky enough to be on the road delivering Lean presentations to industry in a number of our key cities (Hong Kong, Beijing, London, Manchester, New York, Chicago, San Francisco - details on the ThoughtWorks website). I’ll write more about the presentations and the people I’m meeting soon - I want to talk about something that I’ve noticed along the way in this blog…

There seems to be a perception in the IT community that Lean and Agile are two mutually exclusive processes for delivering software. I wanted to talk about it because I hadn’t even thought of Lean as a delivery process at all and I think my view of Lean and how it can be used in IT is diverging with some of the IT community. I’m worried that we may be missing the point.

First of all I think it will be useful to talk about Agile. I’ve spent a lot of time talking about this recently because I think it is important. The Agile Manifesto was signed in 2001 by the key individuals involved in the development of the Agile Software movement and if you read it I think that it’s very clear that it belongs at a philosophical level, rather than a practical one. It’s non prescriptive and that’s important. The original signatories recognised that there is no ‘one right way’ to build software and this is reflected in the manifesto. It simply outlines principles that we all agree with, at least in the Agile community.

Lean also belongs at a philosophical level. Deming’s and Ohno’s work teaches us how to get the best from people and how to build business processes to get the best from them by aligning their futures with that of the organisation. Toyota recognised that there was no ‘one right way’ to build cars and equipped their workforce with tools that supported them in continually improving how the cars were built.

Why do we like Lean as members of the Agile community? Well, at a philosophical level Lean and Agile are incredibly well aligned. They are both about empowering people to get the best results. They are people centric and they teach us how to adapt and improve processes to get the best results from the people we have to solve the problem that we are confronted with.

With this in mind I don’t fully understand how it is possible to follow a Lean software development process. We can only have processes that are more or less efficient than each other in a particular context. There is no ‘one right way’.

What do I mean by that? Well, let me see if I can explain. There are 4 situations where I call on my Lean knowledge heavily. Let’s take them in order… Read the rest of this entry ?

It’s usually viewed as customary to let folk know about a presentation in advance. Unfortunately I’ve been so busy over the last few weeks that I’m only just getting a chance to write about this years Australian Architecture Forum (AAF) now….

Last Friday was the AAF in Melbourne, where ThoughtWorks were a gold sponsor. Last year I presented on analysis techniques for Service Oriented Architectures (SOA), which went down pretty well (for a post technical guy at a conference full of enterprise architects anyway). This year I got invited back to present the locknote presentation with my regular sparing partner, Josh Graham.

The locknote presentation was on middleware and specifically how it’s grown out of all proportion, making even the simplest task slow and expensive. We stole it straight from the presentation that Jim Webber and Martin Fowler used for the keynote at Qcon, except that we removed all of the terms that caused offense to the crowd at Qcon! Webber is doing the presentation today in Sydney with Josh so I’m sure the ThoughtWorks complaints hotline will be ringing off the hook for the rest of the week.

I’m doing quite a bit of presenting at the moment and I’m looking for a way to make the slides available in a sensible way, either through this site or one of the cool slide sharing sites that are popping up around the place. If you’re using anything that you think is particularly good for sharing slides (sideshare etc.) then let me know…

Later this year I’m going to be going on a world tour to present on Lean Software Development and other uses for Lean in Information Technology. The tour will be taking me through China, where it’s planned for me to present with Martin Fowler, the UK and the US.

The details of the UK event are now online here….

Big in Japan: Lean Thinking Techniques for IT Professionals

You can register online for the Manchester and London events. Hopefully I’ll see you there…

I think this is a question on the minds of a lot of people in the IT industry at the moment. The Lean operations community have been on their journey longer than we have in IT and from my experiences at Lean 2008 I think that they are starting to really understand what Lean is all about.

So, what is Lean?

Well, it’s a set of tools (JIT, 5S, 5 Why’s…), it’s a production system, it’s a product development system, it’s a business model, it’s a mentality of continuous improvement, it’s about the ruthless elimination of waste.

Right?

I don’t think so. Of course it is all of those things but today I tend to look at these elements as symptoms of what Lean is really all about; a leadership philosophy for business and life focussed on getting the most out of people.

I’m not going to try and describe what I mean by this becasue I think Konosuke Matsushita, the founder and president of Matsushita Electric (the parent company of Panasonic, Technics and other famous brands), put it much better than I ever could in his speach to visiting European and American managers in 1979….

“We are going to win and the industrial west is going to lose: there’s nothing much you can do about it, because the reasons for your failure are within yourselves. Your firms are built on the Taylor model; even worse, so are your heads. For you, the essence of management is getting the ideas out of the heads of the bosses into the hands of labour. We are beyond the Taylor model : business, we know, is now so complex and difficult, the survival of firms so hazardous in an environment increasingly unpredictable, competitive and fraught with danger, that their continued existence depends on the day-to-day mobilisation of every ounce of intelligence.
For us, the core of management is precisely this art of mobilising and pulling together the intellectual resources of all employees in the service of the firm. We know that the intelligence of a handful of technocrats, however brilliant and smart they may be, is no longer enough. Only by drawing on the combined brain power of all its employees can a firm face up to the turbulence and constraints of today’s environment.”

Is your organisational philosophy about getting the ideas of the managers into the hands of the people or about empowering the people to lead the company?

“The fault, dear Brutus, is not in our stars, but in ourselves” Shakespeare - Julius Caesar.

About Kent :: Kent Beck is the creator of eXtreme Programming and author of Extreme Programming Explained: Embrace Change. Kent was also one of the original signatories of the Agile Manifesto in 2001 and is the founder and director of Three Rivers Institute (TRI).

Q. What influence, if any, did the Lean revolution taking place in the automotive industry have on the development of Agile XP during the C3 project?

None. It wasn’t until a few years later that I ran into Taiichi Ohno’s book “Toyota Production System”. Bob Charette was the first person I heard make the connection between lean production and software development, but again, this was several years after the C3 project.

Q. What do you feel the current view is within the IT community at large toward Agile and Lean software development?

I don’t think there is any one reaction. I hear healthy scepticism, which makes sense given the history of inflated claims in our industry. I hope that things really can be better. I hear curiosity and a willingness to try new things. I hear resistance to change.

Q. What are your thoughts on ‘Lean Thinking’ principles and their application to software development processes?

There are at least two levels of lessons for software development in lean production. One is the techniques themselves, something I explore in www.threeriversinstitute.org/LearningFromLean.html. Many of the techniques of both lean manufacturing and lean product development suggest techniques in software development. The second level of lessons comes from Read the rest of this entry ?

A3 reports have been a favourite Lean tool of mine for a long time. The idea is a simple one… All reports should be presented on a single side of a single piece of A3 paper. The philosophy is that ‘less is more’, all the information required should be concise, anything else is just fluff.

Toyota have been applying this concept for a long time and I’ve seen it successfully adopted at a number of organisations outside of Toyota. I heard a rumour about a year ago that Toyota are moving to A4 reporting but I’m not sure in the truth behind that one.

To understand the power that this simple tool provides sit down and think about the amount of time you spend writing stuff and reading stuff. Will anyone read past the executive summary of your business case? Will your executive come back to you and say “that report’s great but could you summarise it to me in a paragraph?”. Maybe A3’s are worth a shot.