Author: Chris F Carroll

When Agile isn’t Agile

Reading I Fear Our Mobile Group Being Forced To Follow Scrum crystallised in my mind what can go wrong when you treat Agile as a methodology. It describes a team successfully using kanban which is to potentially be required to use scrum — because that's becoming the company standard.

Making a team follow an agile methodology is exactly *not* Agile.

Agile is "Individuals and interactions" being valued more highly than processes. Imposing Scrum looks like valuing the process more than the team.

Agile is "self-organising teams" and letting "the team [reflect] on how to become more effective, then tune and adjust accordingly." Imposing conformity on a team that has already adjusted is a backwards step; you're asking a team that has optimised somewhat for the individuals in the team to de-optimise again.

This doesn't mean that you can't teach an agile team anything. The manifest starts with "We are uncovering better ways of developing software by doing it and helping others do it." A team that can't be corrected, or won't learn better ways, isn't agile. For that matter, a team that won't learn in any walk of life has started the downhill path to decline.

For what it's worth, I'm sure that a competent lean team that tries Scrum for a while will learn from it, even if they end up optimising back to something more fluid.

Susan Atkinson – Features of an Agile Contract for Software Delivery

I first saw Susan Atkinson present on Agile contracts at a Rational User Group event a couple of years ago. A lawyer talking about contracts turned out to be the most well received talk of the day.
There are various slide sets for her presentations on the web but for those of you who can skip the explanation of what is agile/what is waterfall here are her key points on what makes a good agile contract:

edit — Susan kindly dropped by to give an update in the comment below

Eight Features Of An Agile Contract

  1. A Contract For The Supply Of Services Not Goods
  2. A Framework Agreement
    • Comprises multiple packages of work known as ‘releases’
    • Releases called off under a framework
    • The aim of a release is to develop the ‘Minimum Marketable Features’ (MMF)
    • Release completion date is agreed
    • NOTE: A committed start‐up phase may be necessary
  3. Iterations And Methodology
    • Methodology for an iterative process agreed at the outset of the project
    • Each iteration comprises a design/development loop of “plan it, do it, test it, measure it”
    • At the end of each iteration there should be fully tested software that is ready to be deployed
  4. Capacity Trumps Features
    • For each release the supplier commits to deliver a certain amount of capacity by the date on which the release is to be completed
    • At the start of each iteration the parties agree which features are to be worked on for that iteration
    • Features for the current iteration are a firm commitment at a project level BUT not in the contract
    • Features for all future iterations may ‐ and probably will ‐ be further refined
    • No need for contract change mechanism
  5. Customer Involvement is a Contractual Requirement
    • Fully empowered ‘Product Owner’ available on a daily basis
    • Roles of the Product Owner: Prioritise, Clarify, Validate, Feedback
  6. Charging Mechanisms
    • Charges should not drive unwanted behavioural patterns
    • Various mechanisms
  7. Contractual Certainty
    • For each release, commitment to : Capacity, Completion Date, Charges
  8. Key Indicators
    • Metrics of productivity: Velocity (Rate of progress), Feature cycle time (Speed of delivery) Development payload (proportion of 'value' delivered)
    • Metrics of the working software: Defect density, test coverage, other quality or analysis measures.

Refs

IT Success and Failure — the Standish Group CHAOS Report Success Factors

The Standish Group have been famously (notoriously) publishing their CHAOS Report with IT project success/failure/challenged rates since 1994. "XXX% of all IT projects fail!" headlines are doubtless responsible for their fortuitous fame but they have also attempted to analyse 'success factors' over the years:

1994 1999 2001 2004 2010, 2012
1. User Involvement
2. Executive Management Support
3. Clear Statement Of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision And Objectives
10. Hard-Working, Focused Staff 		1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Competent Staff
5. Ownership 		1. Executive Management Support
2. User Involvement
3. Competent Staff
4. Smaller Project Milestones
5. Clear Vision And Objectives 		1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Hard-Working, Focused Staff
5. Clear Vision And Objectives 		1. Executive Support
2. User Involvement
3. Clear Business Objectives
4. Emotional Maturity
5. Optimizing Scope
6. Agile Process
7. Project Management Expertise
8. Skilled Resources
9. Execution
10. Tools & Infrastructure

Little changes at the top. Executive support & user involvement were noted in the 1970s as 2 main success/fail factors. 'Agile Process' is an evolution of 'Smaller Project Milestones' (the bit of agile that's actually about process is "deliver working software frequently", which is "smaller project milestones" in olde 1990s language). 'Clear Vision and Objectives' is re-branded as 'Clear Business Objectives'

But note the varying evaluation of the importance of the people. At one level technical stuff will get done if and only if you have competent people actually doing it — it's make or break. But so are all the factors above "Skilled resource" or "Competent staff", albeit less obviously so.

Emotional Maturity is new. The cynic may note that the Standish group will sell you an Emotional Maturity Test Kit (the less cynical may say Standish are attempting to address a problem). Actually their analysis of emotional maturity is largely about character and behaviour which may be a sign that the English word 'emotion' has grown in what it means compared to 20 years ago. They include arrogance and fraudulence; I can see arrogance as a symptom of emotional immaturity, but fraudulence may mean "I've considered what counts as getting ahead in our society and it seems to me that taking the company for everything I can get before they take me for everything they can get is the way to go". Fraudulence is wrong, but ain't always emotional. I think "personal maturity" — or just maturity — is the idea they're grasping at. It's about having good people.

Scarcity of essential success factors

But the top factors are not prioritisable. I think they are all essential. Rating one above the other says more about relative scarcity than relative importance. When it's really hard to get competent, skilled, hard-working staff then that will be your top success factor. As it is, good executive support is harder to come by than competent staff. Apparently.

I'd summarise as follows:

  • Good people
    • who know what they are trying to achieve
    • with good involvement & communication with who they're achieving it for
    • when well-supported

will succeed, if success is possible.

More serious researchers point out all that is wrong with the Chaos report, most notably:

  • unlike published academic research, the data we'd need to evaluate the claims is kept private so we can't verify their data or methods.
  • Their definition of success is very narrow and doesn't mean success. It means "cost, time and content were accurately estimated up front". Which isn't at all the same as success except in areas which are so well understood that there really is nothing at all you can learn as you are doing it. That's not so common in technology projects.

For an alternative and probably more balanced view of the 'state of IT projects' I'd look at Scott Ambler's annnual surveys: http://www.ambysoft.com/surveys/