Having often listened to John Seddon I’m wary of “lean”. He, too, learned from Ohno, and regards lean (which is the production approach extracted from Toyota) with disdain. His view is that lean is a version of Ohno’s approach which has been packaged by business school professors to sell to Western executives who want easy answers handed to them on a plate. Ohno’s real approach, he says, is to get people as close to the work as possible, and let them solve any problems that arise.

So while reading the summary of The Toyota Mindset I was curious as to what I would find, especially as it proclaims to hold “The Ten Commandments of Taiichi Ohno”. That sounds a bit packaged-for-resale to me. But in fact I was pleased to be wrong.

The “ten commandments” are much more ways of thinking, and ways of approaching business problems, than actual commandments. Two things really stand out from the stories of Ohno that Wakamatsu relates, via Abilla.

First, the number of times the phrase “the shop floor” appears. This is the reason lean might be considered packaged for resale: because Ohno’s real lessons are about getting onto the shop floor and seeing problems first hand, something that most executives in large companies would like to think they are beyond. Some examples from Abilla’s 10-part review:

• On standard work: “Standard work must be realistic and applicable on the shop floor”
• On how to know things: “Taiichi Ohno believed that one should base their judgments on his or her experience on the shop floor, not from a document alone.”
• On learning from the masters: “What you read from books is not usually useful when it comes to improving the shop floor. You will find much better ideas by just trying different methods on the shop floor.”
• On truth and understanding: “Stand and Observe the Shop Floor”
• On disclosing mistakes: “One day, Ohno stepped into the shop floor…”

Okay, that last one wasn’t such a big deal, but it’s notable that there aren’t any Taiichi Ohno stories that begin “One day, Ohno was sitting in his office…”

The second thing that stood out for me was how frustrating it must have been to work for Ohno. There are so many stories in which he asks an employee to do something, they do it, and he scolds them for doing exactly what he says (and in one case, for doing it immediately).

But the lesson here is that the staff should be thinking for themselves, solving problems for themselves, and always going beyond mere instructions.

Of course there is much more to the lean — sorry, the Ohno — way of thinking than these two observations. There is, for instance, the mindset of the continuously watching for waste and acting on it.

The stories related by Wakamatsu seem to be fascinating, and it’s yet another book to add to my growing reading list.

• Space to learn. Startup veterans are always quick to say how much they’ve learned — often from their failures. We need to give our teams space to learn, too. Only then can they really own the knowledge and take it beyond what we intended.
• Communication to the team. To ensure the team has your vision and can feel part of the long term picture while they deal with the immediate issues, continual communication is key. Gossip adores a vacuum. Also essential here is honesty. Honesty simplifies explanations when things go awry later, and forces us to clarify our own thinking and confront your own prejudices.
• Let the team present. Knowledge sharing is important, and that’s forced out when this happens. Encouraging the team to present externally also shows them independent validation of their expertise.
• Proximity to the product. Technology is great, but technology has to be about something. By keeping the team close to the end product and the end users they become much closer to the business, and therefore much more valuable. It also provides many more opportunities for innovation.
• Job titles. Less about creating brilliant teams, more about maintaining them. It’s important to understand that the demands on people will change, particularly in a small company. So make sure job titles are future-proofed, and you’re not going to have to give someone a lesser job title when things do change. If you’re a three person startup and the most technical person is the only developer, then should they be given the title CTO? It might help secure them, and it fits their current status, but is the greatest developer the Chief Technology Officer of Year 2 or 3?
• Remind them they’re brilliant. It’s easy for the team to get lost in the details, and the pride they have isn’t built on the same things that your pride is built on. So take time to remind the team that they are brilliant, and show the team why.

There were lots of smart questions, too.

You can also see great presentations from…

• Andrew Nesbit, of Forward Technology: Form Analytics With iForm
• Avi Patchava, of LinkOut: Online Connections to Offline Relationships
• Azmat, of CityMapper: How to get to #1 in the App Store

Finally, we were entertained by Shed Simove, who talked about his life of pushing boundaries in the name of having a lot of fun (mostly). If you have the opportunity to see Shed talk, then go.

“It’s a mix of ignoring them [non-Agile managers] & making shit up” #ProductTank How is this consistent w/ Agile values of openness & trust?

There’s a conference-worth of material to unpack from that question. You can make up your own responses, whether cynical, pragmatic, witty or all three. I wasn’t at Product Tank, so I can’t take issue with that in detail (though I would caution readers: I know Tom, and his presentation will have been as much about entertainment as education and information, so take that statement with some amount of salt).

However, regardless of its literal truth about alphagov specifically, there is a truth in there about projects in general: if the idea of agile is used as a trojan horse to allow bad behaviours, then any success will be shortlived. That thing masquerading as agile won’t scale to other teams; it certainly won’t scale to larger projects. Agile might be seen as the success factor in the initial project, but the inevitable failure of future projects will ensure its adoption is halted pretty quickly.

This is true for small and large organisations of all kinds, and is one thing that James Yoxall touched on in his presentation to the 2011 Agile Business Conference.

When I manage development teams I see one of my responsibilities as being the angel on the shoulder of those developers, urging them to “do it right” in the face of the project manager who’s urging them to “do it now”. But project managers can be angels, too. Some will be interested only in the success of their own project. And some will want to ensure that good practices are recognised, learned and adopted by others. Unfortunately those two views are sometimes at odds.

• The business decided that the team should be “coding” for a full 7 1/2 hours a day and continually checked that this was the case.
• The management take care of the estimates
• The developers are not part of the planning process
• Estimates are made on a best case scenario
• [Management] think when we are talking about architecture and code quality that we are not working hard enough.
• They do not understand that if time is not given to extensibility and maintainability, that delivering software will become very costly

There are other things, too, but those are the ones I want to highlight. Because the correct response to the question “Is it agile?” is “Wrong question”. It’s a bit like realising the aeroplane you’re in is heading towards a crashing landing, and frantically checking your ticket to see if you really did book a window seat after all. Never mind about whether it’s agile — this is just not even sensible.

All the practices above are the kinds of things enforced by people who aren’t very experienced with running software projects — although I would agree some of them seem like common sense to an outsider, and all of them are the kinds of things software managers can get pressured into by stronger outside forces. But they’re a long way from what should be happening in any well-run development environment. Let’s address them in order:

• Yes, coding is absolutely essential. But so is co-ordination, planning, revising, sharing knowledge, flagging complexities, helping colleagues and a lot of other things that don’t involve typing.
• If the person doing the job doesn’t make the estimates then there’s no reason to expect the estimates to be right.
• If the people doing the job aren’t involved in the planning then there’s no reason to expect the plan to be realistic.
• Estimates aren’t predictions.
• If you don’t design the system right, and keep checking and refining that design, then everything will be more difficult for everyone. Getting this right is called “architecture”. Poor quality code also usually makes things more difficult for a lot of people, so it’s worth spending time on.
• It is very easy to cut corners early so as to increase development costs later.

The second, third and fourth points here should be common sense, while the rest probably aren’t obvious to a non-software person. But in the world of software development getting these right is essential — it’s just good practice. And in doing so you would make the life of a developer like Paul (and the projects he’s working on) a whole lot better. If you want to be even more effective you could adopt agile practices, too. But you can still be sensible without being agile.

When I speak to developers about this I remind them that they are a professional and that no-one (or at least no-one who isn’t a fellow software professional) should be telling them how to do their job right. If you say something will take 1.5 days then there shouldn’t be much picking apart of that, even if 0.5 days of that time is refactoring old code, shoring up the build system, or whatever. That’s what it takes to do a professional job. Not necessarily goldplating it, but doing it responsibly. And yet it frustrates all of us that developers are constantly beaten up on delivery time and pressured to cut corners, making short term gains at the cost of the long term.

But here’s a funny thing. Did you know that finance people do a thing called “double-entry bookkeeping”? This means that every time they capture a transaction they write it down and categorise it twice. Twice! And nobody questions them. Imagine how much faster your friendly local finance team could go if they weren’t busy goldplating their numbers! Now you may say something about finance being much more than just writing down numbers, but surely that’s a crazy suggestion — it would be like saying software development is more than just typing. And you may say something about needing to provide a fully-rounded view of the financial state of the company, but surely they should just get the numbers right first time and then work overtime to sort out any resulting problems. Because that’s what developers are supposed to do, right?

Or maybe — and I’m just throwing this out there — maybe people should respect the professionalism and experience of finance people, technical people, and others.

As the five days unfolded so did a rich collection of ideas, insights and tools. Instead of recounting various presentations, I’ve decided to present a list of books which were cited along the way — or at least those which I noted down. Some of these are by people who presented, though in those cases I’ve mentioned only the ones that were cited first by others. These are listed in (almost) no order and without comment. And, in an act of apparent masochism, none of the links are to Amazon…

• “EVO” by Kai Gilb
• “The Sciences of the Artificial” by Herbert Simon
• “Software For Your Head” by Jim and Michele McCarthy
• “Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving” by Billy Vaughn Koen
• “Freedom From Command and Control” by John Seddon
• “121 Heuristics for Solving Problems” by By Marco Aurelio de Carvalho and Semyon D. Savransky
• “Out of the Crisis” by W. Edwards Deming
• “Economic control of quality of manufactured product” by Walter A. Shewhart
• “How to Measure Anything” by Douglas Hubbard
• “The Failure of Risk Management” by Douglas Hubbard
• “Changing Minds: In Detail” by David Straker
• “How to Invent (Almost) Anything” by David Straker
• “Applied imagination: Principles and procedures of creative problem-solving” by Alex Osborne
• “A Whole New Mind” by Dan Pink
• “The Power of Myth” by Joseph Campbell
• “Principles of Mass and Flow Production” by Frank G. Wollard
• “Irrationality” by Stuart Sutherland

Steve Dover, who leads the beast that is the UC project, stood up and talked about not just the challenges of doing agile development well, but of doing large projects which involved complex operating models, complex hardware such as telephony systems, and the most vulnerable people in society. I thought he spoke with passion and authenticity. Afterwards I talked to some people who said, essentially, “but they’re making this mistake, and surely that’s wrong”. But I think it’s unreasonable for an experienced practitioner to poke holes in another organisation’s genuine attempt to try something so ground-breaking (for that organisation) and so vast.

When I look back on our first attempts to do agile development at the Guardian I’m almost horrified by our naivety. Almost, but not really. Because while we made mistakes, and while we have come a very long way since, what we were doing was a real step forward. Benjamin Mitchell asked me “what if someone had come in and told you what you were doing wrong?” I think that would have helped for some things, but not for everything. Sometimes you have to have experience to be able to apply your knowledge.

By coincidence, earlier in the day I met Tom Loosemore, who leads alpha.gov.uk, the UK government’s other flagship agile project. When Tom talks about alphagov he talks about “Changing by doing”. Alpha.gov.uk might be at the far end of the scale from UC in terms of size and complexity, but that’s one core principle that’s important. You change your system by doing work on it, learning, and feeding back into the next phase of doing. And it’s true for the way you work, too: you do something, feed back, and do more — but this time, better. Just because you might be able to improve it doesn’t mean those first steps are fundamentally wrong.

The Toyota Production System (TPS) tries to eliminate waste, of which the most tangible example is inventory (stuff hanging around the factories waiting to be used). The TPS gave rise to lean manufacturing which focuses on eliminating inventory. And then software developers, impressed with those efficiencies and with an innate desire to be efficient, try to emulate lean manufacturing: they ask “what is inventory in our world?” when they should be asking “what is waste in our world?”

Let’s look again at what’s happened here:

1. A specific, real world problem (waste in Toyota’s car production) gets a specific solution (the Toyota Production System).
2. The solution gets generalised to a reusable framework for manufacturing more widely (lean manufacturing).
3. Another community of people try to derive their own process from the generalised framework by using analogies (“what is our inventory?”)

But when you start picking away at the wrong part of a theory you end up in all sorts of trouble. The wrong part of the theory in this case is the analogy (inventory), whereas the substance is about eliminating waste.

When we focus on the analogy we get confusing results. Traditional lean software development says inventory is undelivered requirements. Michael Feathers and others say it’s code. Alistair Cockburn says it’s unvalidated decisions. We get three different answers because we’re dealing with something which is necessarily removed from reality. (If we were to return from the analogy to the real world then it’s no longer an analogy.)

Similarly, the analogy is difficult to translate in other situations. What is inventory when it comes to, say, the maintenance of social housing?

On the other hand, focusing on the reality gets us real results. The original TPS focused on eliminating waste, one measure of which is reducing lead time. From this perspective we can see that improvements in the maintenance of social housing can be achieved by eliminating waste in the request-to-repair process and measuring success through lead time. In fact, this is one case study John Seddon uses in “Freedom from Command and Control”. This also explains why Seddon says “lean drives me potty” — because lean tends to be based on car production, and people refer to that rather than its underlying principles.

Focusing on eliminating waste (and proving success through measuring cycle time or lead time) also gives us a particular process for software development. This delivers working software very effectively, and given such a system we may then draw analogies with Japanese car production, if we like, and talk about “inventory” and dub our monitoring board a “kanban board”.

Analogies are helpful, but we mustn’t get too hung up on them. The Toyota Production System demonstrated how efficient you can be with a relentless focus on eliminating waste. But it’s easy to get distracted by the abstractions and the generalisations. In the end we must not lose sight of what the actual problem is.

First a disclaimer: I’m really not pretending this is easy. Change is difficult, and change on a large scale is really difficult. So these suggestions are really only small tools in any very large (business process re)engineering project…

1. Focus on business change programmes, not IT projects

Previously I wrote about different departments working to their own agendas which causes inefficiencies and complications. Some readers will recognise this as the premise behind systems thinking, which in this context is the perspective that employees’ behaviour is most significantly influenced by the system in which they operate, including their perceived purpose, targets, and so on. The solution, then, is to re-examine not just how a single department work, but how the entire system operates and focus that around the goal.

I’ll avoid the bigger management consultancy territory and instead stick to technology, because (a) this is a technology blog, and (b) I’ve just set technology up as Lucifer-incarnate, entrenching complicated systems. We technologists must bear responsibility for fixing the problem, and the solution is to examine the system as a whole.

Specifically we should stop delivering “IT projects” and start delivering business change programmes. To me the difference is this: an IT project delivers technology into an existing operation, while a business change programme actually questions and improves the way the business works, independent of departmental boundaries.

Indeed a really successful business change programme should break down boundaries, eliminate bureaucracy, and rewire the operation to focus on the real business goal. Layers of unnecessary interface-translation are removed as real, valuable communication takes place directly.

I can think of one project close to me that’s a good example of this. It involves a lot of complex technology,  and the people leading it on a day-to-day basis have a thorough understanding of that technology. But it’s not an IT project. The real change is in non-technology teams, who are having to reconsider how they work and what they regard as important — now much more recognisable as the purpose of the business.

Technologists are in an unusual position in that we operate across many departments. We need to exploit that to join people up and make things slicker.

2. Put the flexibility in the people, not the technology

That first tactic addressed the first problem, of departmental silos. This one addresses the second problem, of technology that entrenches complicatedness.

The approach here is to reduce the technology to its core purpose, removing the process-specific operations as much as possible and allowing people to do those. People are much, much more flexible than software (yes, software is soft, but people are softer), so when things need to evolve there’s no dependency on technology changes. The way a business works is constantly changing, so it should be easier for people to evolve than people+technology.

The software becomes Brian Prentice, of Gartner’s, conception of simple software: “when the next additional feature has no particular value to the majority of its intended audience”. The interesting stuff — the complexity — moves out of the software and into the people. I would hope this becomes empowering, rather than mechanical, work, and the people feel closer to the real goals of the business and continually thinking about improving it. Certainly, whenever I’ve seen complex processes taken out of technology and into more physical forms — people using index cards to manage requirements, or whiteboards to track progress on something — I also see people at liberty to be continually creative with their working practices.

Full circle

That discussion of simple technology takes us right back to Aaron’s original article. There was enough in that original piece to trigger a year’s worth of blog posts, but for me, most of all, it’s important to understand where organisational complicatedness comes from and how it might be tackled. We technologists might be guilty of creating some of the problems, but we can also lead with the solutions.

Why do organisations become complicated?

Organisations are complicated because they’re split into departments which have to interact with each other. The complications lie less in individual departments, but more in how those departments interact. Because each department has its own priorities and own ways of doing things there need to be translations at the interfaces between departments, and it’s those translations and misaligned priorities which cause the complications.

One place these interface-translations can be seen is in form-filling and template documents. Because different departments work at different speeds (after all, they’re doing different things) it’s common that someone asking for something will be asked to fill in a form. That way the department can queue it up and deal with it when they’re ready. But an impersonal form is a one-way, one-shot communication (rather than a human dialogue) so it has to ask an excess of questions just to cover every eventuality. And despite that plenty of detail will be missed.

As a result of this the system which handles the form needs to deal with an excess of information which, perversely, is still missing key detail. This can lead to exceptions which makes the system more complicated. And this is replicated across the organisation.

Complicated software systems derive from silos

This is the world into which vendors sell so-called “enterprise software”. They call it enterprise software, by the way, because it costs as much as a starship.

When that software is sold it’s typically sold into a department, to solve the department’s problem. And the department’s problem is that it is very complicated. The software addresses this problem by automating the complication.

Complicated software systems entrench silos

Now you can see why this kind of software is expensive: (a) it needs to integrate with data from other places and (b) it’s just complicated. And therefore it is also expensive to change. It’s difficult enough changing the way a group of people (the department and their peers) behave; add to that having to reconfigure a complicated software system designed to match current behaviour and it would be amazing if it ever changed at all.

That’s why complicated software systems solidify complications in the organisation.

Summary

So that’s why organisations buy into complicated software:

1. Because the organisations are divided into departments, each with their own priorities; and
2. The technology is designed to support the status quo;

As a side-effect this makes it near-impossible to simplify the organisation.

In the second part of this article I’ll suggest how things might be tackled differently.