Tuesday, August 18, 2020

Evolution of Agile Project Management

 Evolution of Agile

TQM: The story of Agile as we know it today begins with Total Quality Management or "TQM," developed by Edward Deming. This was also the origin of the Lean movement that pushed for continuous improvement and appreciation of workers. The core tenants of TQM include:

  • Improving Quality Decreases Costs - lowers costly defects, customer support, and recalls
  • Continuous Improvement - for the systems and people in the systems
  • Pride of Workmanship - the primary driver of knowledge workers and source of quality is joy in good work
  • Plan-Do-Check-Act  (PDCA) - this cycle allows for testing a complex system that can't be modeled easily

 

One of the famous beliefs was that the Knowledge Worker is different from the Manual Laborer, because the Knowledge Worker knows more about the work than their boss does.

 

Proof that TQM Works: Edward Deming turned around Ford Motor Company in 1986 from billions of dollars in losses to its first profits in years using the TQM approach.

 

TPS: The Toyota Production System (TPS) was developed by Taichii Ohno that was the first true Lean system. Focus was on reducing waste, based on lessons from TQM. The focus was on reducing the wastes in a system:

  • Eliminate 7 Wastes - Movement, Inventory, Motion, Waiting, Overproduction, Over-Processing, Defects
  • Small Batches - exposes errors and minimizes waste in the system, by using a "Pull System" using Kanban
    • Kanban - means "billboard" and it is a system to tell upstream processes to send work downstream
    • Kanban boards have at least three columns: To-Do, Doing, Done
    • Kanban boards limit work-in-progress (WIP) by limiting the number of items in the "Doing" column and only pulling in more work once the current work in progress is done
  • Continuous Improvement with Key Performance Indicators (KPIs)

 

Proof that TPS Works: Toyota is a top three (3) manufacturer of cars, with a 70% employee satisfaction rating - that's more than double the satisfaction rating of employees in the USA, which stands at 30%.

 

TOC: The Theory of Constraints (TOC) was developed by Eli Goldratt. It emphasizes that the system is always governed by a bottleneck and there is a competition between local optimization and system (global) optimization. The theory states that Throughput of the system should be the focus of managers, not "Cost Centers" that drive local optimization. His ideas are captured in the famous book The Goal which is read widely and cited as critical to the revolution of management in the 1980s.

  • Throughput drives cost and revenue
  • Throughput is constrained by one process in any system, the constraint
  • To improve the System Throughput one must focus on optimizing around the Constraint
  • To do this, use the 5 Focusing Steps for the Process of Ongoing Improvement (POOGI)
    1. Identify the Constraint - figure out which process is limiting
    2. Exploit the Constraint - try to optimize with existing capacity
    3. Subordinate everything to the Constraint - reduce processes to match capacity of the constraint
    4. Elevate the Constraint - add capacity to the constraint process
    5. Prevent inertia from becoming the Constraint - be vigilant and check if there's a new constraint!

 

Proof that TOC Works: TOC was used by the BP Oil Spill Cleanup initiative to save over $200M and rapidly deploy 10,000 boats after the Gulf Oil Spill to skim and clean oil from the surface.

 

The Waterfall Mistake

  • Waterfall was never intended to be linear in its design
  • Royce, who proposed waterfall as a simple starting point for modeling work, stated all projects should iterate
  • Typical waterfall design:
    • Requirements - product requirements as output
    • Design - architecture as output
    • Implementation - system is produced
    • Verification - testing is conducted to fix the system where needed
    • Maintenance - support for product in use
  • The actual design had at least one iteration going back from verification to implementation to design

 

Only 10% of software projects were successful in the 1970s, and using waterfall we still see that half of those projects fail today.

 

By 1980s the Waterfall Method was being used by DoD (and continued until 1996), which resulted in the Ninety-Ninety Rule:

"The first 90 percent of coding accounts for the first 90 percent of development time,
The last 10 percent of coding accounts for the other 90 percent of development time" - Tom Cargill, Bell Labs

 

Important reference: Waterfall Model Probably the Most Costly Mistake in the World:

http://valueatwork.se/waterfall-model-probably-the-most-costly-mistake-in-the-world/?lang=en

 

The original paper from Winston Royce on Waterfall Methodology: 

Winston W. Royce (1970). "Managing the Development of Large Software Systems" in:
Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA

Iterative Methods

  • Rapid Application Development (RAD) - popular during 1970s and 1980s
    • Upfront requirements
    • Iterate on Design and Development
    • System Cutover
  • Dynamic System Design Methodology (DSDM) - popular in 1980s and 1990s
    • Introduced iteration of requirements (foundation)
    • Included going back to design and development as well
    • Still had a "Feasibility Stage" upfront
  • Extreme Programming (XP) - popular from 1990s to 2000s
    • Iterative across all levels (Pair programming, unit testing, standups, testing, and planning)
    • Required heavy iterations and redundancy in resources to manage risk
    • Continues to be used today

 

Key Tenants of Iterative:

  • Consolidated Up-Front Planning - RAD and DSDM did not refine, but XP does
  • Iterate on Designs - design, build, test, refine
  • Timeboxes - to ensure continuous, on-time delivery
  • User Stories - to describe requirements (introduced as standards in XP)
  • Test-Driven Development (TDD) - enables exploration of designs and refinement before release

 

2013 Cross-industry Study by Ambysoft shows the following (see the details of the survey here http://www.ambysoft.com/surveys/success2013.html):

      • Agile is more successful than Traditional
      • Agile is less challenged than Traditional
      • Agile fails less than half as often as Traditional

Project Measure

Agile

Traditional

Successful

64%

49%

Challenged

28%

33%

Failing

8%

18%

Note: This table is reproduced from the summary graphics of Ambysoft's survey found here: https://clearcode.cc/blog/agile-vs-waterfall-method/

 

Knowledge Check

Question 1

The history of Agile is a total quality revolution. What are the three management revolutions that led to the evolution of Agile?

Question 2

According to the lecture, what are the key tenants of Iterative Development (choose 4 of 6)?

 

 

 

at 2 comments:
Labels:

Basic Concepts of Agile. Why agile is so important?

 

Agile Manifesto was codified in 2001 in Snowbird by Scrum, XP, and DSDM practitioners. Agile Manifesto includes:

  • Individuals and Interactions OVER processes and tools
  • Working software (systems) OVER comprehensive documentation
  • Customer collaboration OVER contract negotiation
  • Responding to change OVER following a plan

These values are at the core of why agile works and continues to be used on projects with high uncertainty today.

Sprint basics include the three parts of a Sprint:

  • Sprint Planning
  • Sprint Development
  • Sprint Retro & Review

A Sprint is a timebox, or a period that is used to contain the time allowed for work to be completed. It can be anywhere from two weeks to a month (although shorter is becoming more popular among advanced practitioners).

Sprint Planning starts with the Product Owner selecting the work to be done from the Product's Backlog. The Product Backlog is the list of work that is prioritized by its importance, either for ongoing improvement or the completion of a new product. The Team reviews the stories and then selects what work they will be able to complete during the sprint. This process is facilitated by the Scrum Master who does not participate in the doing of work, but instead is focuses on enabling the team to move quickly with good processes and best practices. The final set of stories should form a cohesive "product increment" that the team can demonstrate by the end of the sprint.

  • Input: Product Backlog of stories prioritized by the Product Owner
  • Process: Review and select stories for the sprint
  • Output: Sprint Backlog of stories the team commits to complete by the end of the Sprint

Sprint Development begins with the daily standup. Daily standups are self-reporting of the team on what work they will get done that day. This is usually done around a Kanban board, or other big visual information radiator (BVIR). The team opens only a few stories at a time and work story-by-story to analyze, build, and test the work. The result by the end of the Sprint is a shippable increment that can be demonstrated to the product owner. Meetings are facilitated by the Scrum Master, and the Product Owner determines if a Story is complete to meet the stakeholder needs.

  • Input: Sprint Backlog of stories the team commits to complete by the end of the Sprint
  • Process: Daily reporting and execution against a few stories at a time: designing, building, testing and closing
  • Output: A shippable product increment that can be demonstrated

Sprint Retro and Review are ceremonies to gain feedback and drive continuous improvement into the team. The first step is the Sprint Review, where the Product Owner demonstrates the product increment from the Sprint to Stakeholders. This is an opportunity to gain stakeholder buy-in and feedback, so the team knows its on track with the product direction. The Product Owner can also get feedback on what should be in the next Sprint. The Sprint Retrospective or "Retro" is the second ceremony used to close a sprint. The Retro involves the team going into a room to evaluate how the sprint went, and identify opportunities for improvement in the next sprint. The best Sprint Retros are run as games to facilitate input from the whole team and quickly identify improvements.

  • Input: Shippable product increment that can be demonstrated
  • Process: Demonstrations and games to facilitate feedback on the product and team processes
  • Output: Feedback on the product's direction and actions to improve the next sprint

Iron Triangle helps to explain how the different project management methods align. The Iron Triangle includes:

  • Scope - the technical work to be done
  • Schedule - the total calendar time to execute the work
  • Budget - the total cost of the project in dollars

All aspects of the Iron Triangle are constraints and costs to the organization. More schedule means a delay of project benefits and tie-up of capital. More budget means more dollars or capital invested. More scope means a larger product to support or maintain for the organization. These are all forms of cost and constrain how the work can be accomplished when they are fixed.

The three types of project management are Agile, Traditional, and Lean.

  • Agile - varies scope against fixed budget and schedule
  • Traditional - varies budget against fixed scope and schedule
  • Lean - varies schedule (or solution time) against fixed scope and budget

The goals and requirements of each method are essential for understanding the place of each method in the project manager's arsenal:

  • Agile - goal is speed (deliver early versions fast), and requires trust to minimize scope for fast value delivery
  • Traditional - goal is efficiency (best price), and requires efficiency to deliver lowest cost on time and budget
  • Lean - goal is to innovate (solve problems), and requires expertise to minimize time of delivery

False comparisons across types of projects abound. Many times the objections one hears about using Agile is that it's missing critical elements, such as design, testing, or documentation. These are all wrong. In fact, every project must have the following to be successful:

  • Charter
  • Plan
  • Documentation
  • Design
  • Testing

Remember that we vary scope to target just what the customer needs, so we don't waste time or money in the process. That's the power of varying scope. It's fast and limits waste by reducing the work to a minimum viable product (MVP) that meets the project objectives (in the charter). To do this, every Agile project needs:

  • Shared Vision Robust to Change (can vary scope and stay on target)
  • Whole Teams (customer + cross-functional team)
  • Incremental Delivery (learn by doing and using small "sprints")
  • Continuous Integration & Testing (teams test increments to ensure they work)

Scrum, SAFe, or Disciplined Agile are all frameworks that help define roles and processes to scale and implement the methodology of Agile. They provide a shared language. But the method remains the same.

You want proof that Agile Works? Is it worth learning? Why change? Why Agile?

The proof that Agile Works at all scales and across time is written in our nation's history in WWII, in our modern green energy movement, and the launching of spacecraft that literally caught stars and brought them down to earth.

Agile methods built brand new cutting, edge aircraft in less than half a year, developed super computers at 10% the normal cost, and delivered returns on investment magnitudes higher through better decision support systems.

Proof Agile Works Summary Points

There are many stories that capture why and how Agile works. One of the most compelling is the P-80 Shooting Star, the first jet fighter, developed by Lockheed Martin's Skunkworks team:

  • P-80 Shooting Star was the first Jet Fighter
  • Developed in 1943 for use in WWII
  • Led by Kelly Johnson using a colocated team in a tent
  • Completed in 143 days

This is unheard of speed in innovation and delivery. Today similar innovation would take many years, if not a decade. Kelly Johnson did this using principles that align closely with Agile:

  • Small, Strong, Self-Directed and Cross-Functional Teams
  • Owners and Vendors had to collaborate and trust each other
  • Managed and responded to change; any team could update the designs
  • Minimize reports, but record what was important
  • Incremental development by teams that could test their own work

This matches the core tenants of Agile closely:

  • Shared Vision, but no fixed scope (they never built it before!)
  • Whole teams (customer, builders, testers)
  • Incremental delivery (as stated, they had to identify and solve problems one at a time)
  • Continuous integration and testing (teams test increments early and often)

Example 2: Navy Energy Return on Investment

  • Goal: select projects to reduce energy costs and use of "brown power"
  • Process: evaluate and select the best projects delivering the highest "bang for the buck"
  • Project: build a decision support tool quickly to enable support for selection

The scope of this project was to build decisions support systems for projects to identify and select $500M in energy investments.  This project was executed iteratively over four years for about five million dollars. The team makeup included:

  • 2 cross-functional teams
  • 8 contract personnel from Booz Allen Hamilton (BAH)
  • 5 customer personnel from the Navy

Outcomes included a fifty dollars per dollar return on investment (ROI: 50). That means the Navy gained $50M per year because of this project and its decisions support systems it developed. This was achieved through iteratively identifying and building the scope needed in multiple releases:

  • $20M were gained per year in savings, by building a quality management tool for projects
  • $30M were gained per year in benefits, by building systems to better select projects
  • Sustainability was improved by modeling where the next best projects would be with 95% accuracy
  • This enabled BAH to win $10M per year in new contracts at the Navy for renewable energy management

Large Scale Agile Examples:

  • Condor Cluster - result of large amounts of reuse and modular architectures (Agile Engineering Example)
    • One of the most powerful super computers
    • Strung 2 million miles of cable to connect PlayStation 3 gaming consoles (PS3s)
    • Modular enough to be loaded into a spy plane to process images in-flight
    • Reduced aerial imagery processing from days to seconds
  • NASA's Faster Better Cheaper Initiative - reduced scope and size of spacecraft (Lean/Agile Release Designs)
    • Major initiative in the 1990s
    • Costs were one-tenth the current cost of producing spacecraft
    • Achieved unheard of results by reusing old spacecraft designs
    • Stardust Mission - slung shot around the earth and sun to catchup and capture dust from a comet
    • Shoemaker - asteroid surveillance mission that landed on the asteroid to retrieve high-density readings
    • Missions were achieved under budget and on schedule, returning 10X the value of traditional NASA projects

Agile Basics Knowledge Check

Question 1

Which of the following belong to the cornerstones of the Agile manifesto (choose 4 of 6)?

Question 2

Which of the following main roles are defined by Scrum process (choose 3 of 5)

Question 3

The Agile project should______________ to facilitate good communication.

 

Question 4

One of the most compelling stories that capture why and how Agile works is the P-80 Shooting Star, the first jet fighter developed by Lockheed Martin's Skunkworks team. The success of this project exemplifies the core tenants of Agile. What is not a core tenant of Agile?

Question 5

In the project of Navy Energy, the scope was to build decisions support systems for projects to identify and select $500M in energy investments. As a result, this project brought a fifty-dollar/dollar return on investment (ROI 50) to Navy. What is the key to success of this project?
 
 
at No comments:
Labels:
Subscribe to: Posts (Atom)