AGILE PROJECT MANAGEMENT

AGILE BASICS:

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 it’s 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.
PROOF AGILE WORKS:
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 collocated 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 principle 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 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)
o One of the most powerful super computers
o Strung 2 million miles of cable to connect PlayStation 3 gaming consoles (PS3s)
o Modular enough to be loaded into a spy plane to process images in-flight
o Reduced aerial imagery processing from days to seconds
 NASA's Faster Better Cheaper Initiative - reduced scope and size of spacecraft (Lean/Agile
Release Designs)
o Major initiative in the 1990s
o Costs were one-tenth the current cost of producing spacecraft
o Achieved unheard of results by reusing old spacecraft designs
o Stardust Mission - slung shot around the earth and sun to catchup and capture dust
from a comet
o Shoemaker - asteroid surveillance mission that landed on the asteroid to retrieve
high-density readings
o Missions were achieved under budget and on schedule, returning 10X the value of
traditional NASA projects
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
o Kanban - means "billboard" and it is a system to tell upstream processes to send
work downstream
o Kanban boards have at least three columns: To-Do, Doing, Done
o 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:
o Requirements - product requirements as output
o Design - architecture as output
o Implementation - system is produced
o Verification - testing is conducted to fix the system where needed
o 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
o Upfront requirements
o Iterate on Design and Development
o System Cutover
 Dynamic System Design Methodology (DSDM) - popular in 1980s and 1990s
o Introduced iteration of requirements (foundation)
o Included going back to design and development as well
o Still had a "Feasibility Stage" upfront
 Extreme Programming (XP) - popular from 1990s to 2000s
o Iterative across all levels (Pair programming, unit testing, standups, testing, and
planning)
o Required heavy iterations and redundancy in resources to manage risk
o 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:

 Agile is more successful than Traditional

 Agile is less challenged than Traditional

 Agile fails less than half as often as Traditional

Netflix Case Study:

Netflix was not always a streaming company. It moved from mail-based delivery of movies to
one of streaming videos online. To achieve the foundational paradigm that would deliver
seamless video streaming. These ideas are still aspirational for many companies today, trying to
catchup to this modern model of management:

 Culture of Innovation - ability to respond to opportunities as they presented themselves

 Data Analytics - this allows for comparing changes and determining if it works through
real data (truth)

 Decentralized Decisions - the empowerment of employees to procure resources on-

demand as needed

 Agile and Self-Service Deployment - the ability for developers to deploy but also be
responsible for their code

This led to what was called a culture of "Freedom and Responsibility." By empowering
employees and holding them responsible, and through incredible innovations in cloud and
deployment technologies, Netflix was able to achieve unheard of responsiveness to customers.
As a result, Netflix continues to be a market driver and the standard in movie streaming
experiences.

What all these ideas have at their core is an understanding of one core belief: Speed Wins!

When comparing the efficiency of managing the volume of material and delivery of content, or
the velocity of delivering changes to those systems at scale - Speed always wins because at
scale you can't expect efficient, perfect solutions. Things will always break at scale and you'll
need to respond quickly to fix and correct those issues in your system. Therefore, all best
efforts for perfect designs up-front and efficiency models in delivery lose, and only speed (for
responsiveness to customers and infrastructure issues) can drive sustainability into the system.
 Have you ever wondered - where did my project come from?

This lesson will give you the high-level understanding to know the source and reasoning for
projects across each Project Management method. If there was one course that captured the
"cheat sheet" of Project Management, it would be this one.

As you go through this next lesson, think about:

 Which of these processes are you involved in?

 Does your organization get involved in the full project lifecycle?

 Are you aware of how your project is paid for, and the benefits that spur the investment?

 What happens when your project is done? What is done?

The project lifecycle is similar to all project types, but there are some clear differences that are
apparent right away when you consider each method and its goals:

 Traditional aims for Predictability

 Agile aims for Speed

 Lean aims for Innovation

Which aim would suit you best in your workplace?

PM Methods:

This lesson is all about understanding the high-level components for each Project Management
Method:

 Traditional
 Agile
 Lean

Traditional Project

 Idea - Traditional projects start with an Idea by the owner or team

 Business cases - Business Cases are performed for each concept; often a qualitative and
quantitative process
 Bid & Proposal - Project scopes of work are written and competed amongst teams
o External vendors will submit bids and proposals to win work against a Request for
Proposals
o Internal teams will submit budgets and proposals to win allocated funding from a
PMO or Portfolio function
 Waterfall Development - each stage is executed sequentially, with limited iteration or
"going backward" in stages
o Requirements - the process of defining high, medium, and low-level needs of the end
users and stakeholders
o Design - the process of architecting the solution to meet those requirements within
the project contraints
o Implementation - the building of the product to specification
o Verification - the testing and product to ensure it meets specifications and the
requirements' intent
o Maintenance - the design of and support of deploying and maintaining the product
in operations
 Operations - the use of the product to produce benefits to the organization
 Disposal - the retirement of the project according to regulations and sustainability
practices

Often the Traditional Process is controlled further with Stage Gates, where stakeholders agree
the project is ready to move from one Waterfall Development Stage to the next. This can help
give executives clear points of approving or disapproving the work; as well as inform
stakeholders of the high-level progress of development.
 Standard Stage Gates:

Idea Readiness Review (IRR) precedes Business Cases

Concept Readiness Review (CRR) precedes Bid & Proposal Stages

Planning Readiness Review (PRR) precedes Requirements phase

Requirements Readiness Review (RRR) precedes Design phase, exits Requirements phase

Design Readiness Review (DRR) precedes Implementation phase, exits Design phase

Implementation Readiness Review (IRR) precedes Verification phase, exits Implementation phase

Operational Readiness Review (ORR) precedes Maintenance (O&M) phase, exits Verification phase

Operations and Maintenance Review (OMR) Precedes Disposal phase, exits Operations (O&M)

Agile Project Management

 Idea - (see Traditional above, it's the same)

 Business Case - (see Traditional above, it's the same)
 Bid & Proposal - (see Traditional above, it's the same mostly, except the contract type
may differ)
 Early Agile Development (Pre-Release of first version)
o Sprints - use the Scrum Method to deliver increments of working product iteratively
until release ready
 Sprint Planning - Product Owner and Team plan work for the sprint
 Sprint Development - Team designs, builds, and tests increments of work in a
fixed time period
 Sprint Retro & Review - Customer reviews the work and team review the sprint
for improvement
 o Deploy First Version to Production - this first version is often called the minimum
viable product (MVP)
 Continuous Delivery (Post-Release of first version)
o The same team(s) supports development and operations or "DevOps"
o These are still executed using the Sprint model, only the team must account for
supporting Operations
o Development
 Create - try something new or build fixes
 Verify - ensure that it works
 Package - get it ready for release
o Operations
 Release - deploy the new features/enhancements/bug fixes
 Configure - ensure operations and test features on/off
 Monitor - monitor performance of functionality
 Plan - prioritize the next improvement or fix
 Disposal - (see Traditional above, it's the same)

Lean Project Management

 Issue - could be an idea, major problem, or series of problems the client or owner
foresees for the business
 Work Concept - work is formed as either a series of small challenges or one big challenge
o Issue Backlog - for support contracts, there needs to be total or sample backlog of
work to support
o Technical Challenge - for technical solutions, there is a challenge set with clear
performance objectives
 Bid & Proposal - (see Traditional above, it's the same; although contract types will differ)
 Work Definition
o Dispose Issues - issues are classified in urgency and impact to define the priority and
who should respond
o Define Work Breakdown - team evaluates and decomposes the Technical Challenge
into a work breakdown structure or "WBS."
 Continuous Delivery
o Value streams - support for solving lots of small problems goes through a series of
predefined steps to ensure quality and drive customer satisfaction the issue is
addressed.
 This is often supported using a defined workflow
  The issues are routed based on priority and impact to different team members
 Only the client or customer or their representative can accept it as done
o Incremental Delivery - a team will incrementally work through the WBS to solve a
major problem
 Often use a Kanban board to solve highest priority/most uncertain work
 Delivery is continuous and incremental to explore solution sets that COULD
work
 Operations - solutions are deployed into operations where customers receive benefits
o Example issue solution - solving someone being locked out of their system
o Example Technical Challenge solution - deploying a new upgraded machine for
manufacturing a car
 Disposal - (see Traditional above, it's the same)
Triple Cost Constraint:
Understanding who uses Agile also requires understanding the methods employed to control a
project's constraints. This brings us back to the Iron Triangle for the Triple Cost Constraint:

 Scope - controlling the work done

 Schedule - controlling the calendar time for doing the work
 Budget - controlling capital expenditures

Controlling Scope

 Traditional
o Work Breakdown Structure (WBS) - controls work by concretely defining its
components
 Often has three levels: Product, Major Features, Feature Components
 Used to define what will and will not be in a project
o Change Control Board (CCB) - controls changes to the WBS by committee review
 Includes all major stakeholders
 Must be organized and often slows changes to a project
 Lean
o Tickets - identify work items and their priority for response (urgency and impact)
o Requests - these are informal or semi-formal requests that could be tickets
o Notes
 Both tickets and requests go into a queue for work, and are executed through
a value stream
 Value streams are steps to complete work (e.g. define, analyze, build, test).
 Agile
o Product Backlogs - the list of work to be done for the entire project. It's an ordered
list of work increments.
o Sprint Backlog - the work that will get done during the sprint.

Note that Backlogs are used for Tickets in Lean and Stories in Agile. You can also have what's
often called the "Kanban Sandwich" where Lean processes are used to set Sprint Goals, Agile is
used to manage a Product and Sprint Backlog, and then work during a sprint is managed in a
Lean process.

Controlling Schedule

 Traditional
o Estimated Tasks and Schedules - work is estimated and modeled for precedence
 o Program Evaluation and Review Technique (PERT) - adds stochastic modeling of task
completion
o Critical Path Method (CPM) - uses deterministic modeling to identify critical tasks for
on-time delivery
o Notes
 Determining the critical series of tasks helps to focus managers in traditional
on the important tasks
 This does not necessarily align with business importance
 Schedule and scope are fixed, however, scope modeling comes before
scheduling to define estimates and dependencies in the work
 A schedule is considered the primary tool in Traditional Management for
controlling delivery
 Lean
o Kanban & Queues - work is managed in a list and executed based on priority
o Service Agreements - sets the priority of work by defining what is critical, major, or
minor
o Notes
 Together the Kanban & Queue techniques, along with the Service Agreements,
allow for Lean projects to adjust when delivery will occur for each work item.
 This is intended since schedule is varied in Lean projects
 Agile
o Timeboxes - a set period of time in which the most important work is done first
o Releases and Roadmaps - sets goals for major features to be release together
o Notes
 Timeboxes are used at all levels of the project to set deadlines
 Sprints are given a fixed time to drive improvement
 Any work not done in the timebox goes back into the backlogs
 Releases and Roadmaps set objects for multiple sprints that can be met at
varying quality levels
 This allows for the most important work to achieve an objective to get done
first
 This aligns the business importance with what work actually gets done on time
Controlling Budget

 Traditional
o Earned Value Management (EVM) - compares current performance to the plan
 Planned Value (PV) - shows the cost over time expected to complete the work
on schedule
 Earned Value (EV) - shows how much work is completed to date
 Actual Cost (AC) - shows the cost so far to complete the work
o Cost Centers
 Evaluates the differences in performance by cost center
 Cost Performance Index (CPI) is the factor EV / AC, where above 1.0 means
good performance
 Schedule Performance Index (SPI) is the factor (EV / PV), where above 1.0
means good performance
 This allows you to estimate the costs or savings expected for on-time delivery
of total scope
 Lean
o Service and Severity Levels - sets the level at which the company reaps benefits from
the solutions
 Service Levels set the Goal
 Severity Levels set the Impact of meeting or not the goal for different problem
types
o Key Performance Indicators (KPIs) - evaluate performance against goals for set time
periods
 If the KPI is meeting or exceeding the Service Level Goal, then you're making
money
 KPIs will often vary over time, so it's important to look at trending
 Agile
o Return on Investment (ROI) - the net income as a ratio to total investment
 Positive ROIs should be expected after the first or second release of a product
 Allows for selecting and refining the backlogs
o Burndown Charts - shows progress in achieving the backlog over time
 Used for projects that haven't yet released the project, or cannot easily
estimate ROI
 Projects often start with a set of stories and story points estimated
 The expectation is a linear burndown - meaning a linear decrease in total
remaining work to be done
  Teams often are slow at the beginning and speed up over time, or hit snags
that stall backlog burn

The central part of this lesson is understanding this table below on Size and PM Method:

Traditional Agile

Project Size Large Medium

Industries Construction Information Technology

Military Product Development

Government / Policy Consulting

Relocation Operations

Planning* Master Schedules Releases

Sourcing Efficiency Trust

Goals Predictable (Low Cost) Speed (Maximize ROI)

Traditional

 Typically, Large
 Many connections between stakeholders
 Impact many stakeholders
o Many departments
o Many technologies and concerns
 Good Examples are
o Large building construction
o Military platform acquisition
 o Government civil works projects
 Planning is done using a Master Schedule
 Goal is to be predictable and efficient (low cost)

Agile

 Typically, Medium in size

 Good examples are
o Building new products
o Ex. SpaceX used modular designs to launch many types of rockets
o Ex. Apple Operating Systems with regular releases over time (incrementally better)
 Planning is done in Releases
o Goal is to get out to market
o Each cycle builds on what came before in releases
 Goal is to be fast and make money (maximize return on investment, ROI)

Lean

 Typically Small
 Good examples
o Building a new solar panel
o Selling or closing a deal
o How we manage ourselves
 To Do: Get the dog from the vet
 Doing: Pick up kids from school
 Done: Bought the presents for the kids' party
 Planning Uses Value streams and Lists
o Setting up a process (e.g. To-Do, Doing, Done)
o Establishing a backlog of work to go through that process
 Goal is to be responsive and innovate (problem solve)

A key question we should ask after considering is why do these groups form around size? Why
are the Traditional projects large? The Agile projects medium in size? The Lean projects small?
Asking these questions drives us to the next lessons on key concerns: Customers and
Engineering.

The central part of this lesson is understanding this table below on Size and PM Method:

Traditional Agile

Project Size Large Medium

Industries Construction Information Technology

Military Product Development

Government / Policy Consulting

Relocation Operations

Planning* Master Schedules Releases

Sourcing Efficiency Trust

Goals Predictable (Low Cost) Speed (Maximize ROI)

Traditional

 Typically Large
 Many connections between stakeholders
 Impact many stakeholders
o Many departments
o Many technologies and concerns
 Good Examples are
o Large building construction
o Military platform acquisition
 o Government civil works projects
 Planning is done using a Master Schedule
 Goal is to be predictable and efficient (low cost)

Agile

 Typically Medium in size

 Good examples are
o Building new products
o Ex. SpaceX used modular designs to launch many types of rockets
o Ex. Apple Operating Systems with regular releases over time (incrementally better)
 Planning is done in Releases
o Goal is to get out to market
o Each cycle builds on what came before in releases
 Goal is to be fast and make money (maximize return on investment, ROI)

Lean

 Typically Small
 Good examples
o Building a new solar panel
o Selling or closing a deal
o How we manage ourselves
 To Do: Get the dog from the vet
 Doing: Pick up kids from school
 Done: Bought the presents for the kids' party
 Planning Uses Value streams and Lists
o Setting up a process (e.g. To-Do, Doing, Done)
o Establishing a backlog of work to go through that process
 Goal is to be responsive and innovate (problem solve)

A key question we should ask after considering is why do these groups form around size? Why
are the Traditional projects large? The Agile projects medium in size? The Lean projects small?

Asking these questions drives us to the next lessons on key concerns: Customers and
Engineering.