Dennis Stevens provides a presentation on Agile Foundation, Promises, and Myths. Dennis almost always has good things to say about agile and its application to business environments. But this time his post misses the mark and starts down the slippery slope of unsubstantiated claims right out of the gate.
He begins with the classic comparison between agile and something else, he's compelled to title it "predictive," not realizing that ALL good project management methods are based on the underlying probabilistic nature of project work.Managing in the presence of uncertainty actually requires predictive skills. Dennis uses the term predictive against a method rather than for it.
Even our beloved DoD 5000.02 (The DoD procurement standard) mandates statistical risk analysis of cost and schedule, and the System Engineering standards do the same.
I'll got through a couple of the slides to make the point in the "predictive versus agile" argument.
The Predictive Approach to Software Development
To improve software delivery we need to:
- Standardize processes
- Optimize resource utilization
- Perform rigorous upfront design
- Produce comprehensive documentation
- Get commitment for definitive Scope, Cost, and Schedule
- Enforce strict adherence to the detailed plan
Let's look at some details
- If we don't have a standardized process, it is a challenge to syndicate the work effort beyond the current group
- What happens when a new project comes in the door and the current team is occupied?
- Wat happens when the current team moves on a a new team starts a project?
- Direct labor is usually a major portion of any software project. Fingers on keyboards costy money.
- Optimizing the absorption of direct labor costs (plus G&A, Fringe, ODC to run up the actual cash flow to 25% to 35% of salary) is a concern for any business
- Optimizing this cost is simply good business
- Even the Federal Government - strange at it may seem - is critically concerned about "run rates" on programs
- The myth that rigorous design up front is done these days seems uninforme, and a bit long in the tooth.
- Iterative and incremental design is part of any large project management governance process
- This is one of those "red herrings" that agilest love to use.
- It's actually prevented in DoD 5000.02 procurements. Rolling waves, incremental milestones are mandated.
- Anyone doing rigorous design up front beyond the ability of the project to verify and validate that design is of course wasting time and money.
- Stop doing stupid things on purpose. This is not the unique venue of Agile, NASA, DoD, and DOE do all have incremental and iterative design process.
- Producing the documentation requested by the customer is usually a good management choice.
- Classical red herring
- Getting commitment for Scope, Cost, and Schedule is usually a good thing to do when you're spending other peoples money.
- Spending your own money, who cares, it's your money
- Spending the share holders money, they may like to know what you're going to do with their money.
Predictive Approach Underlying Assumptions
Scope and Variation
- All Requirements are knowable initially
- This is simply nonsense.
- We work multi billion dollar programs (software intensive) that have emergent requirements at all levels of the program
- Our manned space flight program has changed its mission 3 times in the last 4 years. Major and I mean major impacts on software, hardware, firmware.
- Requirements can be documented completely up front to guide development
- I'm calling BS on this notion.
- Even the formal Systems Engineering guidelines applicable to our program for NASA know better.
- Tasks required to deliver requirements can be precisely known and estimated
- BS again, this is simply bad systems engineering.
- Only the currently active work packages have "definitized" work scope and durations.
The Presentation goes on to say
- Software engineering is linear in nature - really where does it say that. I was a contributing author to the Software Engineering Body of Knowledge and I sure don't remember writing someting like that.
- Manufacturing-centric practices apply directly to software engineering. "Got any references?" Maybe a look at CMMI-DEV 1.3 would inform the conversation a bit more.
The Dennis moves into the Apples and Oranges Comparison Mode
- In the predictive approach - the best way to finish projects faster is to dictate that all tasks finish on time.
- Hate to say this Dennis, but if task don't start on time, they aren't going to finish on time.
- That's a fundamental law of physics for projects.
- If you can find a way to start late and finish on time, you've got one of two things.
- A magic wand
- Sand bagged estimates to complete
- The flaw, Dennis suggests is there is natural variation in estimates
- Yes, read DID 81650, all the Monte Carlo estimating processes used for cost and schedule estimating in CMMI and the GAO, NASA, Air Force, ITIL, NAVAIR and everyone else's estimating guidance.
- The highest ROI depends on maximum resource utilization
- Uh, That's be a NO.
- Show me the math and stop BS'ing us.
- Planning every detail up front results in stable projects
- Ever hear of "rolling waves," "progressive development," Milestone Decision Authorities?
- These are mandated in complex project domains.
- The frequent delivery notion is NOT, I repeat NOT unique to agile. In fact agile did not even discover this, they just revealed it to those working outside the defense and space business.
- Study the problem till you everything
- Now I'm understanding Dennis is making this stuff up...
- That is also mandated to NOT happen in any credible procurement process.
- Even our simple Deliverables Based Planning® method is incremental and iterative Project Management
I stopped reading after that
Why do these types of presentation make it to the light of day. No credible program manager in space and defense would do these things. If an uninformed IT manager does, then she gets what's coming to her - a failed project.
Don't do Stupid Things On Purpose
Was a Poster hanging in the lobby of a nuclear weapons reclamation project, Golden Colorado.
Please do not buy into the notion that project management processes not labeled as agile are somehow flawed. That is a false argument at best and at worse deceptive. Seek out how to apply the 5 immutable principles of project management to your project - be it a traditional project or an agile project.
Then maybe you can recognize "smoke and mirrors" when it arrives in your in box.
