Skip to content

Achieving high velocity

Sprint to the lead in your industry – and stay there!

So says the back of the dust cover on Chasing The Rabbit: How market leaders outdistance the competition and how great companies can catch up and win by Steven J Spear (McGraw Hill, New York, 2009). I referenced this book last week in my post ‘Let it fail then learn to succeed’ which is about using failure as a signal for process improvement.

It’s a great book. Obviously it is not addressed directly to software development, and as I said, Spear covers its application in a range of different settings, including engineering and health-care as well as manufacturing. There’s a distinct lack of focus on the buzzwords kanban, kaizen, and just-in-time, all of which Spear says are merely artifacts of a deeper underlying approach that he proceeds to illustrate extremely well in the course of the book.

The approach might be illustrated by the asking of some fairly simple questions: ‘What did you do?’, ‘What happened then?’, ‘What did you expect to see?’, ‘Was it successful?’, ‘What did you do to correct it?’, ‘What did you learn?’ (my list is not exhaustive). Spears characterises it as:

… a systematic approach to designing and operating systems, a simple set of rules for problem solving and improvement, a clear way to share learning, and a well-defined role as a manager. (p 358)

More formally, the organisation exhibiting these qualities shows two characteristics and four capabilities.

Two characteristics:

  1. Managing the functions as parts of the process. A high-velocity organisation orientates its processes away from functional ‘silos’ (without ignoring the necessary competency of individual functions), and towards “the way the work of individuals, teams and technologies will contribute to (or impede) the process of which they are part” (p 20). For example, Spear describes his own experience while at Toyota: he is asked what a particular factory he is being trained at makes. At first he interviews the management of the factory, and returns with a list, only to be told he doesn’t really know. Then he looks at invoices of the shipped items, which is still said to be wrong. In response to this, he examines what the receiving factory actually paid for, but he is still told he doesn’t know what the factory makes. Finally, he stands at the shipping dock, as as each shipment was sent out, ignoring the shipping label, took a note of the part number stamped onto the part. Then he checked that the factory actually possessed the die for stamping the part number. In response, he was told; “Well, that’s probably not wrong. But I have another question: How are these parts made?” (p 280).
  2. Continually improve the pieces and the process. High-velocity organisations are always learning about all the work they do. Workarounds, tolerating problems, putting out fires, and heroic efforts are simply not tolerated. Every time you have to put out a fire, or devise a workaround, or engage in a heroic measure to get work done, you’ve found a process problem that should be eliminated. Your highest priority isn’t engaging in the workaround, or performing heroic efforts of late-night last-minute production delivery effort. Your highest priority, and that of your management, is swarming the problem to fix the process that led to the situation. Doug South described it to me as “not tolerating things”. Instead you should fix their causes rather than developing a workaround to the immediate problem.

Four capabilities:

  1. Specifying design to capture existing knowledge and building in tests to reveal problems. Make explicit the most effective approach currently known to you to successfully achieve the task. Make sure that the approach has the capacity to detect failure as soon as it occurs. You need to be sure what outcomes you expect, not from a “perverse Taylorism” (p 23) but as an investment. By specifying expectations, you can more easily capture when something unexpected happens – that is, what the gaps in your current knowledge are. Go out of your way to build in these tests. Alcoa for example, focused exclusively on improving safety – with the goal of zero injuries, because this “meant perfect processes based on perfect knowledge of how to do work” (p 94). The test therefore, was the occurrence of workplace accidents. When an accident occurred, it highlighted a dangerous ignorance, and had to be rectified.
  2. Swarming and solving problems to build new knowledge. When you encounter problems, at the time and place of the encounter, the problem should be swarmed. Contain the problem to prevent it from spreading. Diagnose and treat the cause so the problem cannot reoccur. Problem-solving skills are built by solving actual problems, and those doing the work are responsible for improving the process by which the work is done. Doing this will allow you to “build ever-deeper knowledge about how to manage the systems for doing [your] work, converting inevitable up-front ignorance into knowledge” (p 24). For example, at Alcoa, it was made a rule that business-unit presidents had to not only inform the Alcoa CEO within 24 hours of an injury or injury near-miss, “but within two days they had to report what the initial investigation had revealed about its causes and what was being done to prevent the problem from recurring” (p 96). This ensured a discipline, a warp-speed cycle involving real-time problem recognition, diagnosis and treatment.
  3. Sharing new knowledge throughout the organisation. It’s not just that you learn. It’s that the entire organisation learns. Toyota did this for a joint-venture plant it created with General Motors. Toyota’s approach was a one-variable-at-a-time tuning. The American plant would make an existing model and not an all-new car. Rather than creating an entirely new plant, or swarming the old GM plant with Toyota managers, it took newly hired American managers and coached them in the Toyota way. They didn’t just drop them into the plant. They first made similar products (Corollas) at a Toyota plant. Then they went back to the American plant and Toyota gave the new managers continuous support from Japanese experts. The joint-venture plant was far more successful than the old General Motors plant it replaced. In 2003, in order to be abale to accelerate organisational learning, Toyota created the Global Production Center, which was staffed with experienced cadres of trainers in areas identified as critical to production success. They developed standardised practice equipment and had other groups test the new equipment to identify problems with it. And because these practices are orientated around the discovery of solutions via practical experimentation, and rapid cycles of concepts and validaty testing, they can “smoothly converge on solutions that were agreeable across disciplines” (p 253). Having done all this, it shared it’s newfound knowledge with representatives from factories around the world, and trained managers and group-leaders who were setting up a similar centre for Toyota’s North American operations. Just as important as creating new knowledge and sharing information about particular capabilities, it’s just as critical to spread problem-solving capability throughout the organisation.
  4. Leading by developing the first three capabilities. Managers are not there to measure, berate, and exhort their workers in a command-and-control environment. The role of management is to ensure their organisation becomes “ever more self-diagnosing and self-improving, skilled at detecting problems, solving them, and multiplying the effect by making the solutions available throughout the organisation” (p 26). The process of finding out what the plant made which I outlined above was part of learning this fourth capability by observing a system at four levels – output, pathways, connections and activities.

At the end of the book is an illuminating conversation about golf. Now personally I can’t stand golf but I suppose lots of middle-aged businessmen do, and the conversation was about the simplicity of the game. Despite protestations about bunkers, traps, and hazards, roughs and fast greens, and how difficult it really is, in the end it’s actually a simple game with very simple rules. Keep hitting the ball with a club until you get it into the hole. Simple rules that require a lot of practice to do it right. And like golf, making your organisation high-velocity might run with a fairly simple set of rules, but they require a great deal of practice at the various skills needed to make it happen.

That gives a general overview of the content of the book. It’s written in a very accessible style which communicates the essential concepts very well without trivialising them. If you are a software developer who is interested in thinking about development process, and general business process, then I definitely recommend this book. Sometime in the next few weeks I will try to produce a further post relating some of these specific concepts that Spear has identified and apply them to software development process. In the meantime, buy and read this book.