Is it Time to Amend the Agile Manifesto?

I recently had lunch with a CIO friend of mine.  We were talking about his new job, and he said, “you know, my software teams are using Scrum, but I’m frustrated.  I think I’m really more of a waterfall guy.”  I was surprised, but when I dug a little further, his reasoning made sense.  Here are his basic points:

• I don’t know if the work my teams are doing is contributing to my objectives.
• I can’t get a reliable status on any of my projects.
• Each team is on its own schedule and I don’t really know how they’re doing.
• I’m constantly being told not to ask about schedules and costs because it’s “not agile.”

#NoEstimates?

My CIO friend and many other executives have been conditioned that expecting some level of predictability is somehow “not agile.”  I hear some agile coaches talk about the evils of estimating and the danger in seeking any sort of conformity.  “It’s all about the team” is the common mantra.  Executives stay quiet for fear of being shamed as “old-school.”

Imagine hiring a team of professionals to do anything else for your home or business, and to be told that asking for a timeline or cost estimate “isn’t agile.”  Sounds ridiculous, doesn’t it?

The truth is, most executives don’t care about agile.  They care about creating value for their stakeholders while sticking to a budget.  They have always held their teams accountable for three major items:

• What is the scope of the work we are doing?
• When will it be done?
• How much is it going to cost?

If we in the agile community can’t (or won’t) produce reasonable answers to these questions, senior leaders will intervene.  They will add Gantt charts, hours tracking and status meetings on top of our agile practice in an attempt to answer these basic questions.  We end up losing most of the benefits (flexibility, reduced waste, higher quality) that agile methods promise.  I’m seeing this happen more and more.

#FactsAndData

Many of the ideas we now call “agile” originated with Walter Shewart, W. Edwards Deming, Joseph Juran, Eli Goldratt and other manufacturing quality pioneers.  The “Plan-Do-Check-Act” model, created by Shewart and refined by Deming, was a precursor to the Scrum cycle.  These statisticians, mathematicians and engineers showed us how to improve quality by using facts and data to make the manufacturing process more predictable.  In fact, Deming changed PDCA to PDSA, “Plan-Do-Study-Act” to emphasize analysis over inspection.

Iterative agile methods such as Scrum, when done well, produce a wealth of information that can help teams become more predictable.  Velocity is a powerful metric when it is used correctly.  It measures how much a team can actually deliver in a set time based on the real experience of that team.  Other process metrics such as production defect rates, work added to sprints, and work carried over from sprint to sprint can help teams learn to execute more effectively.  I believe that measuring and analyzing this data, rather than just inspecting, should be the realm of QA.

(Software QA: Time to pull the goalie?)

The Manifesto

Perhaps it’s time to add an amendment to the Agile Manifesto:

Facts and data over intuition and feelings

(that is, while there is value in the item on the right, we value the item on the left more)

I believe in the agile movement, and I like Scrum in particular as a great way to develop software.  But if we don’t embrace facts and data as a means to improve, “Agile” begins to feel more like a religion than a science.