1 / 10

Case Studies Motivating Efficiency as a Spendable Quantity

Case Studies Motivating Efficiency as a Spendable Quantity. Alistair Cockburn Humans and Technology http: // Alistair.Cockburn.us. Purpose of the talk. Update you on non-manufacturing “agile” work Convince you that purposefully allowing rework can be a winning strategy;

thalia
Télécharger la présentation

Case Studies Motivating Efficiency as a Spendable Quantity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Case Studies Motivating Efficiencyas a Spendable Quantity Alistair Cockburn Humans and Technology http: // Alistair.Cockburn.us

  2. Purpose of the talk • Update you on non-manufacturing “agile” work • Convince you that purposefully allowing reworkcanbe a winning strategy; • ... that efficiency can be traded for improved overall schedule. • These are known to work in design activities.Do they work in any manufacturing situations?

  3. Agile in Software Development :History 1991 + • 1991: Alistair Cockburn assigned to develop an effective software development methodology. • He interviewed and studied project teams for 5 years, applied his results to $15M fixed-price, fixed-scope software project (which succeeded). • Emphasis on “process-light” methodologies to improve software development efficiency. • Emphasis on tracking “Running Tested Functions” (RTF) to improve visibility into project progress. • Emphasis on “concurrent development” to shorten delivery times (this talk). • ... Other people were producing similar results.

  4. 2001: The Manifesto for AgileSoftware Development • “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: • Individuals and interactions over Processes and Tools • Working software over Comprehensive documentation • Customer collaboration over Contract negotiation • Responding to change over Following a plan • That is, while there is value in the items on the right, we value the items on the left more.”

  5. 2005: The Declaration of Inter-dependencefor agile-adaptive project management • “We increase return on investment by making continuous flow of value our focus; • ...deliver reliable results by engaging customers in frequent interactions and shared ownership; • ...manage for uncertainty through iterations, anticipation and adaptation; • ...unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference; • ...boost performance through group accountability for results and shared responsibility for team effectiveness; • ...improve effectiveness and reliability through situationally specific strategies, processes and practices."

  6. Question: You have isolated the bottleneck station. ... Now what do you do with the OTHER stations? • Have them --- • 1. Sit idle (creates buffer and warning signal) • 2. Do the work of the bottleneck station (increases the output of the bottleneck station) • 3. Do work that simplifies the work at the bottleneck station (increases the output of the bottleneck station) • 4. Rework material to improve quality going into, or reduce rework required at, the bottleneck station(speed meeting “quality” standards at bottleneck station) • 5. Create multiple alternatives for the bottleneck workers to choose from(increases the output of the bottleneck station)

  7. Strategy: Start downstream work early, accept limited rework penalty, deliver earlier than otherwise. Requirements Serial Development Design Program Test Requirements Concurrent Development Design Program Test IncreasedReworkCost ScheduleGain

  8. Principle: Choose the handover point according to the allowable rework penalty at the non-bottleneck Project Winifred case study Requirements RequirementsGatherer RequirementsGatherer Designer/Programmer Stability DP DP DP DP DP Database Analyst (DBA) DBA These designer/programmers have spare capacity (can do rework) Time These DBAs are the bottleneck (little rework capacity)

  9. The strategy works because of (and with careful attention to) relativespare capacities • Fundamental Tension: • Starting a downstream station early ... • ...increases its rework ( lengthens its task time ) • ...shortens (maybe) the overall schedule • The balance point depends on the relative spare capacity of the two stations. • The strategy also works when the upstream station is the bottleneck and the downstream station has spare capacity ! (the downstream station creates multiple solutions for the upstream to choose from)

  10. End: Purposefully allowing reworkcanbe a winning strategy ... • ... and efficiency can be traded to improve overall schedule • These are known to work in design activities.Do they work in any manufacturing situations? • referenced web sites: • http:// AgileManifesto.org • http:// PmDeclarationOfInterdependence.org • http:// Alistair.Cockburn.us

More Related