Julio Santos

Just finished reading Mary and Tom Poppendieck’s “Lean Software Development - An Agile Toolkit”, a book on agile development. This is an *incredibly good book*. As a so-called “agile enthusiast”, I had never read it and that was a shame. I’m glad I did now as I learned many new things, or reinforced things I already knew or suspected.

The book basically debunks two commonly accepted (and often repeated) ideas:

a) Software is a different type of engineering. Agilists argue that we should not try to learn lessons from manufacturing, since software is not the assembly line (which is true) and the way things are done in the manufacturing world, only make sense there (which is not true, as it turns out).

b) Manufacturing is still using the same scientific management technique Frederick Taylor invented almost a century ago. As it turns out, manufacturing came a long way, and it has been demonstrated that Lean Manufacturing works better than you thought. Okay, better than *I* thought.

The book is laid out as toolkit (the book’s subtitle really makes a lot of sense) taking ideas from Lean Manufacturing, and adapt those ideas to Software Development. I’m a big believer in “agile is not just for software” so whenever I come across examples where agility is used elsewhere, I tend to get very excited about it.

With this book you will not only learn that manufacturing is not the sequential and predictive process you thought it was, but you will also learn that software development can borrow from many of the lean manufacturing ideas (as opposed to borrowing from more traditional ways, and therefore getting stuck with waterfall)

Toyota has a long history of using “Lean Manufacturing”, or agile ways for making their cars. GM and Detroit in general, were adepts of predictive manufacturing. Because the later you fix a problem, the more expensive it is, Detroit chose the Big Design Up-Front strategy, where’s Toyota went with with the Embrace Change approach. Though Detroit now understands how the Japanese do it, and they’ve been using more agile ways since the nineties, I can’t help but think that Lean has something to do with better and cheaper cars they make, and therefore with the problems GM is having.

The authors identify seven lean principles and suggest 22 tools for applying the principles. Each principle has its own chapter, where the authors explain what the principle really means, how it’s used in the real world (not software), how it can and should be adapted by software. The biggest chunk on each chapter/principle, is the part where they provide the reader with the “tools” for applying the principle.

Here are the tools for each practice, with one of my favorite quotes for each tool:

Eliminate waste
1- Seeing Waste

Beloging to multiple teams causes more interruptions and thus more task switching. This task switching is waste.

2- Value Stream Mapping

First and foremost, our mission is to provide customer value

3- Amplify learning

Deterministic control simply does not work when there is variability in the terrain

4- Iterations

A Standish Group study found that 45 percent of features in a typical system are never used and 19 percent are rarely used.

5- Synchronization

The general principle is that if builds and test suites take too long, they will not be used, so invest in making them fast.

6- Set-base Development

…communicate constraints, not solutions.

Decide as late as possible
7- Options Thinking

a plan should not prespecify detailed actions based on speculation

8- The Last Responsible Moment

Amateurs try to get everything right the first time and so overload their problem-solving capacity

9- Making Decisions

Marines plan, but they do not predict

Deliver as fast as possible
10- Pull Systems

Telling developers what to do, does not generate much motivation

11- Queuing Theory

Just as a highway cannot provide acceptable service without some slack in capacity, so you probably are not providing your customers with the highest level of service if you have no slack in your organization

12- Cost of Delay

have the accountant work with the team to develop a simple economic model showing the cost of delay, the cost of reduced features, the cost of maintenance, and so on.

Empower the team
13- Self-Determination

Treat people like volunteers

14- Motivation

People suffer when they lack purpose

15- Leadership

sharp distinction between managers and leaders

16- Expertise

In companies with successful matrix management, functional managers view their jobs as mentors and teachers.

Build integrity in

17- Perceived Integrity

Model driven-design is a valuable approach for complex systems, as it lets everyone speak the same language

18- Conceptual Integrity

It should be possible to test each leayer independently from other layers by simulating the behavior of other layers. Layers provide high cohesion within the layer and separation of concerns between the layers, two fundamental architectural patterns in software design.

19- Refactoring

Where do people get the idea that all good design happens at the beginning of a project? Many people involved in developing products understand that great designs evolve over time.

20- Testing

Testing does not cost, it pays, both during development and over the system’s lifecycle

See the whole

21- Measurements

When you try to measure performance, particularly the performance of knowledge workers, you’re positivelty courting dysfunction. [...] Our culture is adverse to this conclusion; performance measurements seem to fundamental to the way we do business [...] Measurements are important for tracking the progress of software development. [...] However, information measurements, not performance measurements, should be used for this purpose.

22- Contracts

a fixed-price contract with a vendor hoping to profit from changes, combined with rigorous change approval mechanisms to contain cost, may approximately double the cost and time it takes to develop the software, while producing a lower quality result [...] The process of selecting of selecting a vendor for a fixed-price contract has a tendency to favor the most optimistic - or the most desperate - vendor. [...] This, fixed-price contracts tend to select tehj vendor most likely to get in trouble

–

In addition to these fine principles and tools, the authors teach how to apply these in big companies, small companies, and almost as importantly, when to use or not use a given practice, how to apply those for different types of project, etc. If you have any time of authority in your organization, want to improve things, and never read this book, you should be going here now.

I’m going to file this book under: No Lead Should Be Allowed To Practice Without First Reading This (TM).