Author Archives: 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.