XP Explained Cover

This week we continue with the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) with two more chapters in Section Two.  Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

Chapter 18: Taylorism and Software

Somewhere in the dark ages when I was a senior in high school, I worked for Firestone Tire and Rubber. During my stint as a tire sorter and mold cleaner the time and motion people terrorized me and almost everyone at the plant.  They lurked behind the machines with clipboards and stopwatches to ensure all workers were following ‘the right way’ to do work. Cut to approximately four years later when I was a senior at Louisiana State University, I took several courses in industrial engineering.  Between both sets of experiences, I learned a lot about industrial engineering, scientific management, and Taylorism. Some of what I learned made sense for highly structured manufacturing plants, but very little makes sense for organizations writing and delivering software (although many people still try to apply these concepts).

Frederick Taylor led the efficiency movement of the 1890’s, culminating in his book The Principles of Scientific Management (1911). Scientific management suggests that there is ‘one best way’ that can be identified and measured to do any piece of work (hence the stopwatches). Scientific management continues to be used by many organizations from manufacturing to hospitals (at least according to my sister-in-law who is a nurse). It is hard to resist something named scientific management, even though scientific management tends to clash with the less regimented concepts found in the Agile and lean frameworks used in knowledge work.

Side Note: Beck points out the brilliance in naming “scientific management,” who would be in favor of the opposite, “unscientific management”? (The book notes that when picking descriptive names, it helps to pick a name whose opposite is unappealing, for example, the Patriot Act.)

Why the clash?  Scientific management was born in a manufacturing environment not software development environment. Taylor was focused on getting the most out workers that he felt had to lead and controlled closely.  In Taylor’s world, making steel or assembling cars were repeatable and predictable processes and the workers were cogs in the machine. Time and motion studies, which are a common tool in scientific management, run into problems based on several simplifying assumptions when applied to many types of work, including software development.  Beck points out three critical assumptions made by Taylor.

  1.   Things usually go according to plan as work moves through a repeatable process.
  2.   Improving individual steps leads optimization of the overall process.
  3.   People are mostly interchangeable and need to be told what to do.

Take a few minutes while you consider the simplifying assumptions as they are applied to writing, testing and delivering functionality, and then stop laughing.

While very few enlightened CIOs would admit to being adherents of Taylor, many would describe their “shop” as a software factory and actively leverage at least some of the tenets of scientific management.  The practice of social engineering developed by Taylor and his followers is built into the role specialization model of IT that is nearly ubiquitous. One form of social engineering practiced on the factory floor even today is the separation of workers from planners, which translates into software development as separating estimators and project managers from developers and testers in today’s IT organization. The planners and estimators decide how and how long the workers will take to deliver and a piece of work. Developers are considered the 21st-century cogs in the machine that work at the pace specified by the planners and estimators.  Every software development framework decries this practice and yet it still exists.  Similarly, Beck points out that creating a separate quality department is another form of social engineering.  The separation of the quality function ensures the workers are working to the correct quality by checking at specific points in the process flow.  In every case, separating activities generates bottlenecks and constraints, and potentially makes each group the enemy of each other. Once upon a time I heard a group of developers mention that they had completed development, but the testers caused the project to be late.  This is a reflection of Taylorism and social engineering.

Chapter 19: Toyota

The Toyota Production System (TPS) is an alternative to Taylorism.  Much has been written about TPS, including several books by Tom and Mary Poppendiech that pioneered applying TPS to software development and maintenance. In TPS, each worker is responsible for the whole production line rather than a single function. One of the goals of each step in the process is to make the quality of the production line high enough that downstream quality assurance is not needed.

In the TPS there is less social stratification and less need to perform independent checking. Less independent checking is needed becasue workers feel accountable for their work because it will immediately used by the next step process. In software development, a developer writes code and tests code that forms the basis for the future stories. A developer in an organization using the TPS can’t hide if they deliver poor quality and will be subject to peer pressure clean up their act and deliver good quality.

Beck caps the chapter with a reminder of the time value of money.  Making anything and then not using it immediately so that you generate feedback causes the informational value to evaporate. Quick feedback is one of the reasons why short iterations and quick feedback generates more value than classic waterfall.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 – 3

Week 3, Chapters 4 – 5

Week 4, Chapters 6 – 7  

Week 5, Chapters 8 – 9

Week 6, Chapters 10 – 11

Week 7, Chapters 12 – 13

Week 8, Chapters 14 – 15

Week 9, Chapters 16 – 17

A few quick notes. We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), not a re-read!  Steven Adams suggested the book and it has been on my list for a few years! Click the link (The Five Dysfunctions of a Team), buy a copy and in a few weeks, we will begin to read the book together.