What do you wish your CEO knew about Agile?

Esther Schindler has been posting on a number of different Agile-related groups & forums asking participants the question:

If you could get the boss to understand one thing, just ONE THING, related to Agile development... what would it be? Why that?

When she posted this to the Agile CM forum at cmcrossroads.com, my reply was as follows ...

My "one thing" would be a bit more basic than either CM or "Agile" (IMHO), and culled from Steve McConnell's talks on "Critical Insights for C-level Executives" and "The 10 Most Powerful ideas in Software Engineering" both of which are available online from Construx (unfortunately you have to register to download them, although registration is free and they promise not to spam you)

McConnell starts off with what he says are 5 insights that C-level Executives already know:

• Software projects are late
• Software projects are out of control
• Answers from software staff are often incomprehensible
• Answers from software staff often seem evasive
• Software is the most unpredictable part of the business

Then he goes on to describe what he calls the 7 Critical insights about software development that C-level executives need to know:

• Typical Budgeting Processes Undermine Effective Development (and don't acknowledge the "cone of uncertainty")
  
• Stage-Gate Processes Are Prevalent In Leading Companies
• Low Quality Is The Single Largest Cost Driver
• People (Staff) Exert The Largest Impact On Project Outcomes
• Software Improvement Works Best When Supported at the Organizational Level
• The Tradeoffs Between Cost, Schedule, And Quality Might Not Be What You Think They Are
• Improved Software Practices Offer Exceptionally High ROIs

McConnell describes the 10 most important/powerful ideas in software development as follows:

• Software Development Work is Performed by Human Beings (people are the single biggest influence factor for success)
• Incrementalism is Essential
• Iteration is Essential
• The Cost To Fix A Defect Increases Over Time, Throughout the Development Lifecycle (even when using iterative/incremental/agile development)
  

• There’s an Important Kernel of Truth in the Waterfall Model
• Ability to Create Useful Software Estimates Can be Improved Over Time (The Cone Of Uncertainty)
• The Most Powerful Form of Reuse is Full Reuse
  
• Risk Management Provides Critical Insights into Many Core Software Development Issues
• Different Kinds of Software Call For Different Kinds of Software Development - The “Toolbox” (there is no single best best practice or method across all software projects/products)
• Software Engineering Body of Knowledge - SWEBOK (existing body of knowledge provides a wide spectrum of support for software development practices, especially CM, PM, RM, QM, Testing, Design, Construction, Management, Maintenance, Methods and Tools)
  

So how would I distill all of that into a single statement to communicate to C-level executives? Tom Gilb get's an honorable mention for his "The Ten Most Powerful Principles for Quality in [Software and] Software Organizations", which he summarizes as a single principle saying:

"Motivate people
towards real results
by giving them numeric feedback frequently
and the ability to change anything for success."

For me, the gist of all the above is that most corporate planning, estimation and management "systems" for software are badly broken because they utterly fail to acknowledge the inherent uncertainty and variation that cannot be removed by "up front" attempts at perfectly stable project plans and/or product requirements (see my article on "The Unchangeable Rules of Software Change"):

• The solution is not going to come about by striving ever harder for perfectly stable plans and requirements earlier in the project!
  
• The only successful way to manage that is through effective and continuous management of risk and change!
  
• And the most effective means of doing that is through the use of iterative and incremental techniques that put people first in order to give frequent feedback and reflection on real-results throughout the course of the project (while still leveraging the existing body of knowledge to serve those people so they can best serve the business).

Many companies seem to behave as if merely identifying risks and having mitigation plans is sufficiently effective, and they just need to do that "up front" and then monitor the risk-list without having to spend much time adjusting, adapting, and refining it throughout the project.

Similarly, many companies seem to behave as if they can effective manage change is they basically strive to prevent changes once the project/requirements is (are) initially baselined.

All that is poppycock! Effective risk and change management comes about only by taking a continuous approach to manage them that use regular increments and iterations to achieve frequent feedback on tangible, valued results. Even that by itself is not enough, because if you do not enable and empower your people to act on those results, collaboratively, throughout the entire lifecycle, then you won't be very effective or efficient at reaching your goals. Your process has to leverage the power of your people rather than being an obstacle that overly constrains/controls them.

That all goes for CM and managing change just as much as it goes for development and managing projects! Stop thinking it is feasible to drive out 100% of the variation and uncertainty early in the project, and rechannel that energy instead on managing risk and change continuously, utilizing iterative/incremental means to attain frequent & regular feedback. Then make sure you empower your people to act on that information by effecting necessary changes as quickly as possible, and using processes that regularly embrace such changes instead of stalling or preventing them.