1/27

Mike Cohn’s presentation at:http://www.mountaingoatsoftware.com/system/presentation/file/123/Cohn-Agile-and-Deadly-Sins-of-Project-Management.pdf

Mike raises some interesting questions about applying “agile” to development projects.

His approach, however of replacing bad project management with agile is not new, but it’s also not correct.

Fix the broken process, before replacing it with another.

2/27

3/27

Agile has very useful software development practices.

But the notion that Agile is the answer to bad project management is a common starting point for some agilest.

The problems (the sins) mentioned in Mike’s presentation are just “bad” project management.

Don’t Do Stupid Things on Purpose4/27

“Good” project management is always the first (and many times best) antidote to “Bad” project management.

Failure to apply “Good” project management usually leads to “Bad” projects.

This choice is sometimes made intentionally followed by complaints that the PM method didn’t work.

Don’t Do Stupid Things on Purpose5/27

No matter what project, what project method, what business domain, or what context inside that business domain – there are 5 Immutable Principles of PM

6/27

As Project Managers and Developers, Do we …

Know Where Are We Going?

How Are We Going To Get There?

Have Enough Time, Resources, And Money To Get There?

Know What Impediments Will We Encounter Along The Way?

Know If We Are Making Progress?

If not, we’re doing “bad” Project Management.

7/27

1. Where Are We Going?

Eliciting Requirements Is Domain Dependent

“Design and integrate 18 major weapon systems and platforms simultaneously within strict size and weight limitations, while synchronizing the development, demonstration, and production of as many as 157 complementary systems with the Future Combat System content and schedule.” (This is an actual requirement)

Implement the 8 stories for our new warehouse inventory package tracking system using the existing web site platform as a starting point.

8/27

2. How Do We Get There?

Some problems respond to lightweight approaches, likeScrum, DSDM, Crystal, and XP as product development methods.

Others require more complex approaches, like a System of Systems (SoS) spiral development processes.

In all cases a disciplined approach increases the probability of success – no matter the complexity of the problem or the solution.

This approach works well when we don’t

know what “done” looks like with enough clarity

So Does This!

9/27

3. Do We Have Enough Time, Money, And Resources To Get To DONE?

A Common Problem A Simple Solution

We have undue optimism of our capacity for work

Using the Integrated Master Plan and Integrated master Schedule, construct a network of Work Packages describing the flow of work.

Use documented procedures – no matter the method – for estimating and planning using historical data.

We attempt to avoid risk and uncertainty

Understand and prioritize risks for each critical component empowers management and staff.

Use this knowledge to control your optimism.

We rely too much on intuitive judgment

Simple statistical models are more often correct than the human judgment.

Have this number to back up your intuition.

The Rational Planning of (Software) Projects, Mark C. Paulk, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213–3890

10/27

Risk Management Is How Adults

Manage Projects‒ Tim Lister

4. What Impediments Will We Encounter Along The Way To DONE?

11/27

5. How Do We Know If We Are Making Progress As Planned?

The only measure of progress is the Physical Percent Complete for the planned deliverables.

A

Physical Percent Complete means tangible evidence of the outcomes that were planned – measured at the time they were planned to be delivered.

B

This is the basis for full Earned Value Management with physical percent complete. This is also a natural a fit with the agile approaches to software development.

C

All successful methods measure the evidentiary outcomes in units meaningful to the stakeholders.These units are usually “money” and “time.”

D

12/27

Sins Virtue

Lust Chastity

Gluttony Temperance

Greed Charity

Sloth Diligence

Anger Patience

Envy Kindness

Pride Humility13/27

Sins Virtue

Gluttony Temperance

Lust Chastity

Sloth Diligence

Opaqueness Visibility

Pride Feedback

Wastefulness Conservation

Myopia Foresight14/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Fixing all dimensions – scope, schedule, and quality.

Measures of Effectiveness (MoE) and Measures of Performance (MoP) defined the parameters of Technical Performance Measures (TPM).

Impossible schedules. Probabilistic cost and schedule margins (DID 81650 in the defense business).

Death marches. Pace the work into Work Package and Planning Packages within “rolling waves.”

Always have a defined outcome within the period of performance that has a “sensible” horizon.

Trying to do too much for the resources available.

Resource management plans tied to measures of Physical Percent Complete

Cutting quality to meet other goals.

Quality is a Technical Performance Measure. Make compliance with TPM’s visible to senior

management

15/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Intense or unrestrained cravingfor features.

Defined capabilities, traceable to requirements,traceable to deliverables produced by Work Packages in the Integrated Master Schedule.

Trace requirements to needed capabilities. Answer every request with a mandatory trade-

space assessment. Why do we need this?

Trying to put too many features into a product during the time allowed.

Monetizing each deliverable against the Budgeted Cost for Work Scheduled (BCWS)

Treating all features as “critical.”

Paired Comparison or Borda Ranking of features. Analysis of Alternative (AoA). “Trade Space” analysis of each feature.

Overtime, reduced quality, surprises.

Understanding the “capacity for work.” Managed resource plans based on this capacity

and the feedback from measurable performance

16/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Failing to do high quality work at all times.

Measures of Effectiveness and Performance connected to Technical Performance Measures defined as part of the “narrative” of the work.

Testing quality at the end.

Technical Performance Measures for each major deliverable.

Measure compliance with these. Adjust forecast of future performance based on

past performance.Use only tangible evidentiary materials to measure

performance.

Instability during development.

Use what ever method you need to confirm working product on a daily, weekly, or no more that every other week basis.

Big delays. Provide cost, schedule, and technical margins.

Unpredictable schedules. Execute according to plan.

17/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Obscuring progress, quality, or other attributes of a project.

Measures of physical percent complete based on planned physical percent complete establish the “credibility” of progress.

Measuring actuals against plan on fine grained boundaries keeps every one honest

Not knowing the true state of the project.

The true state of the project is comparison of actuals with the plan for cost, schedule, and technical performance

Cost, Schedule, and Technical performance measures on fine grained boundaries.

Surprises Ask “How Long Are You Willing To Wait BeforeYou

Find Out You’re Late? Measure at least at ½ that duration.

Poor decisions Start making decisions on actionable information

from the performance measures.

18/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Believing that we know everything to build the product.

No one knows everything - period. Stop trying. This is why there are rolling waves, spirals, drops in

large complex programs. Realistic development is part of all “good” project

management.

A lack of stakeholder and user involvement.

This is a “business management” issue.Why would you spend someone else's money and

not have them involved in that process?

Failure to solicit feedback.

Feedback comes at least monthly on large government programs.

Feedback is always measured in units meaningful to the participants.

To do otherwise is not allowed in DoD, DOE, NHS –why do IT projects continue to put up with this?

Failure to learn. Learned orgs survive, others don’t – find better

projects to work on.19/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Misuse of critical resources

Failure to manage resources violates at least 4 Chapters and dozens of sections of PMBOK.

Why is this allowed – it’s “bad” project management.

Losses of creativity, motivation, and time

Management is a verb. Do good management. Stop doing stupid things on purpose.

Project malaise The role of management is to lead. Start leading. The Marines can figure this out, why can’t you?

Delays Plan the work – work the plan. Late starts = Late Finishes.

Doing it the same way (again) Be a manager, stop being stupid. Come on folks “nut up or shut up”.

20/27

Mike’s Agile Counter Example Virtue of Deliverables Based Planning®

Not seeing beyond your own work

Integrated Master Plan

Teams who don’t see the big picture

Integrated Master Schedule

Individuals who work only within their roles.

Integrated Master Schedule, with “giver/receiver” links, traceable vertical and horizontal paths to the deliverables

Unsuccessful products.

Design to, Build to, Test to specification.Use “Test as you Fly” paradigm. This means full

fidelity test environment. 100% evaluation of all deliverables.

Delays. There is a fundamental law of physics for projects –

Late Starts = Late Finishes.

21/27

22/27

23/27

24/27

Developing software based products is not the same as managing the development of software based products.A good example of why is found in the CMMI DEV 1.2 table.

25/27

Why is Software Development not the

Same as Project Management?

Process Management Acronym Level 2 Level 3 Level 4 Level 5Organization Process Focus OPF

Organization Process Definition OPD

Organization Training OT

Organization Process Performance OPP

Organizational Innovation and Deployment OID

Project Management Level 2 Level 3 Level 4 Level 5Project Planning PP

Project Monitoring and Control PMC

Supplier Agreement Management SAM

Integrated Project Management IPM

Risk Management RSKM

Quantitative Project Management QPM

Engineering Level 2 Level 3 Level 4 Level 5Requirements Management RM

Requirements Development RD

Technical Solution TS

Product Integration PI

Verification VER

Validation VAL

Support Level 2 Level 3 Level 4 Level 5Configuration Management CM

Process and Product Quality Assurance PPQA

Measurement and Analysis MA

Decision Analysis and Resolution DAR

Causal Analysis and Resolution CAR

CMMI-DEV 1.2

Separates

“Engineering”

from the

management

of Engineering

for a simple

reason …

“Doing, is not

the same as

management

of the Doing”

26/27

Agile methods include a few process areas outside “Engineering.”

But there remains many other PA’s not included in Agile, that are part of developing software based products.

Process Management Acronym Level 2 Level 3 Level 4 Level 5

Organization Process Focus OPF

Organization Process Definition OPD

Organization Training OT

Organization Process Performance OPP

Organizational Innovation and Deployment OID

Project Management Level 2 Level 3 Level 4 Level 5

Project Planning PP

Project Monitoring and Control PMC

Supplier Agreement Management SAM

Integrated Project Management IPM

Risk Management RSKM

Quantitative Project Management QPM

Engineering Level 2 Level 3 Level 4 Level 5

Requirements Management RM

Requirements Development RD

Technical Solution TS

Product Integration PI

Verification VER

Validation VAL

Support Level 2 Level 3 Level 4 Level 5

Configuration Management CM

Process and Product Quality Assurance PPQA

Measurement and Analysis MA

Decision Analysis and Resolution DAR

Causal Analysis and Resolution CAR 27/27