This document critiques presentations that use "red herrings" to argue for agile over traditional project management approaches. It asserts that many criticisms of traditional approaches actually represent examples of bad project management practices, not limitations of the approach. The document recommends focusing on established processes for areas like problem detection, continuous improvement, and lessons learned rather than presented conjectures. It concludes that for agile to be taken seriously by business leaders, it needs to demonstrate how it improves established processes and show value in quantifiable business terms rather than anecdotal experiences.

1. YET ANOTHER AGILE
PRESENTATION WITH RED
HERRINGS
How to confuse BAD Management with BAD process

2. The Red Herring
 An expression referring to the rhetorical or literary
tactic of diverting attention away from an item of
significance.
 The diversion is examples Agilest use for moving the
Agile are simply BAD Project Management
 If many of the processes in GOOD project
management were applied properly, there would
be discussion about making improvements, rather
than replacing processes.
 “Waterfall” to usually the starting point for the Red
Herring discussion.

3. Value Driven Delivery
The notion of “value” in agile has no units of
measure. Engineering Economics does. The unit of
measure is $’s.
Monetizing all decisions and actions is called
Project Management.
The lack of any process to monetize actions
disconnects the real value to the business from
the perceived value of agile.
SHOW ME THE MONEY

4. Value Driven Delivery
Agile Traditional
Deliver value by understanding and  Define the project up front.
prioritizing what is important to the  Use robust change management to
customer and the business, continually protect against / prevent change.
refining the smallest and simplest thing
that might possible work, delivering
quality results incrementally, and
obtaining feedback to improve the
result.
The suggested “traditional” approach is just BAD PM.
Managing projects in this manner is simply BAD Project Management.
No PM guidance suggests this is the correct approach. Progressive elaboration
has been in the PM literature since the early 80’s.

5. Value Driven Delivery
Counter Discussion
The Conjecture The Facts
 Define the project up front.  No credible PM processes says to
do this.
 This is another “red herring” built
around BAD project management.
 “waterfall” is no longer allowed in
DoD.
 Spiral is being replaced in DoD IT
projects with progressive
development in Rolling Waves.
 Use robust change management to  Yes, someone has to control the
protect against / prevent change. scope if you’re spending other
people’s money.
 Spending your own money – no one
cares how your do it.

6. Value Driven Delivery
Recommended Best Practice
 Start with an Integrated Master Plan to define the
“value assessment points” in the project
 SignificantAccomplishments for each of these
assessment points,
 Accomplishment Criteria for the work efforts needed to
produce the planned maturity.
 Define “value” in terms of “Engineering Economics”
to remove the hand waving and replace it with
tangible measures of performance.
 Units of measure must be $’s

7. Value Driven Delivery
Recommended Best Practice
 Maintaining the mechanisms for the interested
parties are participants is necessary, but far from
sufficient to success.
 What does DONE look like in units meaningful to
these interested parties?
 What are the Measures of Effectiveness (MoE)?
 These are measures in business units.
 What are the Measures of Performance (MoP)?
 These are measures in technical units.

8. Value Driven Delivery
Recommended Best Practice
 For example MoE might be :
 92 out of 100 of pilots satisfactorily completing
primary training per unit of time
 Decrease by 15% the cost of training the 100 pilots
per unit of time.
 An example of MoP might be:
 Assure the flight test article dry weight is 29kg or less
by Critical Design Review (CDR)
 Measure and confirm the throughput of the transaction
processor can meet or exceed the maximum demand
rate of 1,200 transactions / second.

9. Stakeholder Engagement
Physical engaging stakeholders is highly domain
sensitive.
The term “appropriate” is meaningless, since
there is no unity of measure of “appropriate”
Appropriate to Who? Appropriate for what
purpose?
These engagements must be defined during the
project charting process – then we’ll know what
“appropriate” means.

10. Stakeholder Engagement
Agile Traditional
Establish and maintain mechanisms that  Throw projects over the wall across
ensure that all current and future Analysis, Design, Development, QA,
interested parties are appropriately and Production.
participating throughout the lifecycle  Engage end-users at the end.
of the project.  Leave significant strategic decisions
to the interpretation of the
development organization while the
project is in the black-box of
development.
The suggested "traditional" approach is of course BAD PM. Don't so this in any
domain or context. This was known decades ago. Those continuing to "throw
things over the wall," need to look for new work.

11. Stakeholder Engagement
Recommended Best Practice
 Using the DoD 5000.02 acquisition process,
establish monthly Technical Interface Meetings (TIM),
monthly Program Management Reviews (PMR), and
COTR and Program System Engineering
representative connections.
 Provide weekly Earned Value in a Digital
Integrated Environment, so the customer can "see"
weekly performance of the program.
 Establish an Integration Laboratory to verify proper
(to specification) operational capabilities of each
Rolling Wave deliverable.

12. Boost Team Performance
All the principles of agile are also present in any
modern, successful team.
These attributes have been in place John
Katzenberg's The Wisdom of Teams.
Falling to put these ideas to work is not the
problem of traditional management, it’s the
problem of BAD Managers.
The best Red Herring so far.

13. Boost Team Performance
Agile Conjectured Traditional
Boost team performance through  Focus on resource optimization.
creating an environment of trust,  Form teams around projects.
learning, collaborative decision  Share resources across multiple
making, commitment and conflict projects simultaneously.
resolution, thereby enhancing  Take power away so people just do
relationships amongst individual team what they are told according to the
members. standards.
Put all decision making into the
hands of few key managers.
The traditional and agile approach is highly sensitive to the business
environment. For internal IT the focus of projects may be less than in a "contract"
based engagement. It is critical to establish Domain and Context. In all domains,
the "team" is the source of success.

14. Boost Team Performance
Counter Discussion
The Conjecture The Facts
 Focus on resource optimization.  This may be necessary depending
on the domain and context.
 Form teams around projects.  This is also domain and context
dependent.
 Share resources across multiple  Multitasking reduces effectiveness.
projects simultaneously. But the reality of project work must
deal with this at times.
 Take power away so people just do  This is simply BAD management.
what they are told according to the  Any intellectual property
standards. development manager knows better.
If this happens fire that manager
and get a better one.
 Put all decision making into the  This is another “red herring.”
hands of few key managers.  Fire that manager, get another one.

15. Boost Team Performance
Recommended Best Practice
 Establish Work Package teams in a matrixed
environment.
 Hold the Work Package team accountable for the
delivery of the funded work.
 Enable these teams to work within their budget and
schedule to produce complaint products.
 Flow this accountability to the lowest reasonable
level of the organization (Work Package) and roll
up the reporting of "progress to plan" from those
accountable to the work.

16. Adaptive Planning
Plans are Strategies for success. Planning by its
very nature is adaptive.
To suggest that Plans are fixed is to restate that
those who have fixed plans are BAD Project
Managers – Again.

17. Adaptive Planning
Agile Traditional
Work with the team and the  Plan the work and work the plan.
stakeholders to produce and maintain  Stick to the Gantt Chart.
an evolving plan from initiation to
close based on goals, business values,
risks, constraints, and stakeholder
feedback.
Without some form of a Plan you cannot know what DONE looks like. To
suggest otherwise is not only naive, it is irresponsible when you're spending
other peoples money.
The Gantt Chart has been replaced with newer forms to visualize the
dependencies and sequencing of work.
Small or trivial projects can get by with “lists of sticky notes,” lack of visibility to
the interdependencies are root cause of schedule slips and budget overruns.

18. Adaptive Planning Counter Discussion
The Conjecture The Facts
 Plan the work and work  Yes, all projects have Plans.
the plan.  An agile project’s plan is developed during the
planning sessions for the iteration.
The outcomes from that plan are posted on the
wall for Stories or Features to be implemented
during the iteration.
 This is called a Plan
 Stick to the Gantt  The Gantt chart can show dependencies in ways
Chart. no agile method can.
 If there are no dependencies, then don’t use this
chart.
 If there are dependencies ask how they will be
shown – it may look like a Gantt

19. Adaptive Planning
Recommended Best Practice
 Establish the Integrated Master Plan for the
"program architecture."
 Do this with Systems Engineering process to define the
"value stream" of the increasing maturity flow.
 The Plan is the strategy, the Schedule is the work
sequence and duration (Work Package duration) for
produce the elements of the "value stream."
 This
IMP/IMS approach is the mandated process for
DoD 5000.02 programs.

20. Adaptive Planning
Recommended Best Practice
 The "value" is defined in units meaningful to the
stakeholders.
 Thisvalue definition process is called “Engineering
Economics.”
 In our domain that means confirmation that the
needed capabilities are available as planned and
these capabilities can be verified through MoE and
MoP assessments.

21. Problem Detection and Resolution
This is a core process of CMMI DEV V1.3. to
suggest Traditional project management doesn’t
deal with this is to ignore established guidance.

22. Problem Detection and Resolution
Agile Traditional
The team identifies problems, Management identifies problems,
impediments, and risks; determines impediments, and risks; determines
strategies for dealing with them; and strategies for dealing with them; and
executes the strategy. executes the strategy.
Current Lessons Learned professionals mandate the approach of 360˚ problem
detection and resolution and have done so for decades.

23. Problem Detection and Resolution
Counter Discussion
The Conjecture The Facts
 Management identifies problems,  How can management identify a
impediments, and risks; determines problem if they are not embedded
strategies for dealing with them; in the development?
and executes the strategy.  This is one of those “nonsense”
statements.
 The strategy for dealing with the
problem may certainty involve
management, that’s their role.
 How can management execute the
strategy if it requires engineering
participation? – another nonsense
statement.
 Read CMMI DEV V1.2 Process Areas
for how to handle this.

24. Problem Detection and Resolution
Recommended Best Practice
 All problems are detected, notified, and addressed
from all facets of the project – this 360˚ process is
at the heart of TQM, Lean, and 6 Sigma for
decades
 This is the basis of all “risk management processes.”
 It is also the basis of:
 ITIL
 CobiT
 CMMI DEV v1.3

25. Continuous Improvement
Continuous improvement process have been in
place for decades.
The granularity of when to stop and assess
performance improvement opportunities is a
business and project governance decision.
Guidance for this process is found in Six Sigma,
Lean, TQM and other quality processes.

26. Continuous Improvement
Agile Traditional
Improve the quality, effectiveness, and  Perform lessons learned at the end
flexibility of the product, process and of the project.
team and influence the organization in  Use those to update organizational
order to better deliver value now and processes and standards.
in the future.
The agile suggestion while correct provides no units of measure or actionable
processes to cause quality, effectiveness, and flexibility to appear. Initiatives
like LM21 as examples of how to put the words into practice. The Lean
Aerospace initiatives of MIT established this approach long before Agile
discovered the words.

27. Continuous Improvement
Counter Discussion
The Conjecture The Facts
 Perform lessons learned at the end  This is not the recommend guidance
of the project. for any credible Lessons Learned
process.
 Who does this?
 Stop doing stupid things on purpose
 Use those to update organizational  Yes the lessons learned are used to
processes and standards. update process and standards –
that’s one of the points of LL.

28. Continuous Improvement
Recommended Best Practice
 Formal Lessons Learned processes are in place for
all agencies (DoD, DOE, DHS, FAA). These LL are
guided by formal (professional) LL paradigms.

29. Lessons Learned
Agile has tremendous value in the development of
software intensive systems. But this approach of starting
with “Red Herrings,” making unsubstantiated statements,
and using simple BAD Management practices as the
counter point to Agile serves no purpose.
When Agile “thought leaders” start to address to “value”
of Agile in the context of the business process
improvement and abandon the anecdotal experiences,
then business leaders will start to listen.
This is the lesson from deploying Balanced Scorecard,
Lean Manufacturing, and other quality and process
improvement processes.

30. Lessons Learned From the Presentation
 Without properly applying the traditional processes
- and holding managers accountable for this proper
application – the "new" processes will be seen as
"paving the cow path."
 That is – trying to apply new methods to an
environment that has yet to address the systemic
problems with using the traditional methods.

31. Lessons Learned From the Presentation
 The agile methods used in developing software
(Scrum, XP, DSDM Crystal, RUP) address the
development of products.
 They do not address the issues of "managing" the
development of those products from the Business
Governance paradigm.
 One example of this is the 21 Process Areas of
CMMI Dev V1.2. 5 Process Areas are applicable to
the development of the actual product.
 The other 16 deal with the business and operational
aspects of a software development projects.