YET ANOTHER AGILE PRESENTATION WITH RED HERRINGS

How to confuse BAD Management with BAD process

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.

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

Value Driven Delivery

Value Driven Delivery

Agile Traditional

Deliver value by understanding and

prioritizing what is important to the

customer and the business, continually

refining the smallest and simplest thing

that might possible work, delivering

quality results incrementally, and

obtaining feedback to improve the

result.

Define the project up front.

Use robust change management to

protect against / prevent change.

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.

Value Driven DeliveryCounter 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

protect against / prevent change.

Yes, someone has to control the

scope if you’re spending other

people’s money.

Spending your own money – no one

cares how your do it.

Value Driven DeliveryRecommended Best Practice

Start with an Integrated Master Plan to define the

“value assessment points” in the project

Significant Accomplishments 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

Value Driven DeliveryRecommended 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.

Value Driven DeliveryRecommended 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.

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.

Stakeholder Engagement

Stakeholder Engagement

Agile Traditional

Establish and maintain mechanisms that

ensure that all current and future

interested parties are appropriately

participating throughout the lifecycle

of the project.

Throw projects over the wall across

Analysis, Design, Development, QA,

and Production.

Engage end-users at the end.

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.

Stakeholder EngagementRecommended 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.

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.

Boost Team Performance

Boost Team Performance

Agile Conjectured Traditional

Boost team performance through

creating an environment of trust,

learning, collaborative decision

making, commitment and conflict

resolution, thereby enhancing

relationships amongst individual team

members.

Focus on resource optimization.

Form teams around projects.

Share resources across multiple

projects simultaneously.

Take power away so people just do

what they are told according to the

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.

Boost Team PerformanceCounter 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

projects simultaneously.

Multitasking reduces effectiveness.

But the reality of project work must

deal with this at times.

Take power away so people just do

what they are told according to the

standards.

This is simply BAD management.

Any intellectual property

development manager knows better.

If this happens fire that manager

and get a better one.

Put all decision making into the

hands of few key managers.

This is another “red herring.”

Fire that manager, get another one.

Boost Team PerformanceRecommended 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.

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.

Adaptive Planning

Adaptive Planning

Agile Traditional

Work with the team and the

stakeholders to produce and maintain

an evolving plan from initiation to

close based on goals, business values,

risks, constraints, and stakeholder

feedback.

Plan the work and work the plan.

Stick to the Gantt Chart.

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.

Adaptive Planning Counter Discussion

The Conjecture The Facts

Plan the work and work

the plan.

Yes, all projects have Plans.

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

Chart.

The Gantt chart can show dependencies in ways

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

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.

Adaptive PlanningRecommended Best Practice

The "value" is defined in units meaningful to the

stakeholders.

This value 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.

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.

Problem Detection and Resolution

Problem Detection and Resolution

Agile Traditional

The team identifies problems,

impediments, and risks; determines

strategies for dealing with them; and

executes the strategy.

Management identifies problems,

impediments, and risks; determines

strategies for dealing with them; and

executes the strategy.

Current Lessons Learned professionals mandate the approach of 360˚ problem

detection and resolution and have done so for decades.

Problem Detection and Resolution Counter Discussion

The Conjecture The Facts

Management identifies problems,

impediments, and risks; determines

strategies for dealing with them;

and executes the strategy.

How can management identify a

problem if they are not embedded

in the development?

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.

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

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.

Continuous Improvement

Continuous Improvement

Agile Traditional

Improve the quality, effectiveness, and

flexibility of the product, process and

team and influence the organization in

order to better deliver value now and

in the future.

Perform lessons learned at the end

of the project.

Use those to update organizational

processes and standards.

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.

Continuous Improvement Counter Discussion

The Conjecture The Facts

Perform lessons learned at the end

of the project.

This is not the recommend guidance

for any credible Lessons Learned

process.

Who does this?

Stop doing stupid things on purpose

Use those to update organizational

processes and standards.

Yes the lessons learned are used to

update process and standards –

that’s one of the points of LL.

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.

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.

Lessons Learned

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.

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.