Extreme Programming Section 2 Chapter 18 & 19

Overview

  • these 2 chapters compare 2 distinctive management strategies. The first is Fedrick Talyor’s “Scientific Management”, the second is Toyota’s Production System.

Chapter 18 Taloryism and Software

The One Best Way

Fedrick Talyor was the first industrial engineer and led the efficiency movement of 1890’s. He wrote the book The Principles of Scientific Management (1911).c To improve factory productivity apply the methods of science: observation, hypothesis, and experimentation. The premise that there is one best way to do any piece of work. He observes a worker, devise alternative ways doing the task, observe these, and pick the best way.

  • Beck points out three critical assumptions made by Taylor.

    • Things usually go according to plan as work moves through a repeatable process.
      • Gant charts
      • project plans
      • Business Requirement Docs
    • Improving individual steps leads optimization of the overall process.

    • People are mostly interchangeable and need to be told what to do.
      • workers work slowly or badly but not so much to be noticed.
      • people are widgets and are there only for the paycheck.

Taylorism in Software Development

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.

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.

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. Beck points out three critical assumptions made by Taylor.

  • Separate Quality control department to ensure workers worked at the right pace and in the specified way in order to achieve the right level of quality.
  • having a separate organization unit or department sends the signal that QA is as important as engineering, or marketing or sales.
  • putting the QA Dept within engineering sends the message engineering and qa are separate and parallel activities.
  • Separating quality from engineering makes the job of quality punitive instead of constructive

Chapter 19 Toyota Production System (TPS)

Widespread recognition of TPS as the model production system grew rapidly with the publication in 1990 of The Machine That Changed the World, the result of five years of research led by the Massachusetts Institute of Technology. The MIT researchers found that TPS was so much more effective and efficient than traditional mass production that it represented a completely new paradigm and coined the term lean production to indicate this radically different approach to production.

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.

Assumptions:

  • going fast doesn’t mean straining workers
  • eliminate waste to move faster.
  • every worker is responsible for the whole production line.
  • defect is found stop work until fixed
  • lower Work In Progress (WIP) allows overall system to go faster
  • Greatest waste is the waste of over production - if you make and dont use it immediately its wasted work.

In the TPS there is less social stratification and less need to perform independent checking. Less independent checking is needed because 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 to 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.

Software development waste examples

  • fat requirement docs that go out of date quickly
  • elaborate architectures that are never used
  • code that is never integrated or deployed to prod

Documentation is needed, instead of all up front more Just in Time - get the requirement, build it, while testing it, and deploy it.

Requirements Gathering isnt bettered by having more of it but by shortening the path between the production of the requirements detail and the deployment of software into production. Requirements ARE NOT a phase, its and activity that produces just in time product detail.

References