Built for Endurance
You just need to take a look at a crocodile, to see that this species goes back to prehistoric times. Same goes for the Komodo Dragon.
Source: http://en.wikipedia.org/wiki/Komodo_dragon
How come these creatures have endured so many thousands of generations? This will be part of the talk I will lecture on at the Agile Practitioners 2012 conference. I believe that the reason for the success of these creatures is that they are built (so to speak) for endurance. The single value, if you can call it that, that unconsciously guides these lizards to propagate, is to create successive generations that will succeed to produce further successive generations. A pretty Darwinist view, no doubt.
What has this to do with software organizations and agile, you might ask?
Many organizations declare mission statements, and values, and vision. This may come as a paragraph of text, a few bullets, or words:
“Our goal is to dominate the <Paste-Your-Business-Here> market”
“Provide superb customer experience”
“Low prices always”
What would be an adequate value for a software organization? In my view, Built for Endurance” is a worthy goal. Something that can permeate throughout the company.
A few examples:
What would be the effect of adding a 4th question to the SCRUM daily standup: “Is this sprint Built for Endurance”? What would that do to the team’s quality targets? Will surrendering to external pressure to deliver bring the team closer or farther from this value?
What would requirements look like, if the Definition of Done will include the statement: “Built for Endurance”? Will this guide the Product Manager/Owner to require better tests in the criteria?
What would the sales organization sell to customers, if they sell solutions that are “Built for Endurance?”
How about Human Resources? What would attrition rate be, if HR is called to support a work force that is “Built for Endurance”?
In my view, quality is very much about endurance, and very little about testing. If your quality organization relies on testing, you are probably trying to prove where your product and process is not endurable. If, however, you wish your products to be endurable, try thinking about the earliest point in the process to take this into consideration.
Where would you start? I will share some more insight about my talk in the coming few weeks. I will also be happy to hear from you about your ideas.
Becoming agile 
I don’t understand how the PM methodology/framework will have anything to do with the endurance of the product. It all comes down to the quality of the underlying code pumped out by the programmers.
I always remember this saying: “If houses are built the same way that software is built then the first woodpecker to come along would destroy civilization.”
It’s not about Agile, it’s about the code itself…
Agile is much about quality. XP (eXtreme Programming), for example, is considered an agile practice. As such, introducing testing as a development practice (TDD), building continuously with automation (CI) are part of the wholistic view of project management.
Put simply – if you consider yourselves professionals, get quality sorted out as part of you project management!
Sounds delicious 🙂 Looking forward to hearing this talk.
🙂 thanks!
Pingback: Spot the Differences « Becoming agile