Tag: agile

Can a Contract Cope with Changing Requirements?

It's been decades since software people started to think about how to cope with requirements changing during the course of an engagement, though other areas of endeavour have surely been doing it since the stone age. Literally.

The state of the art for software, and increasingly for other areas of IT, is Agile. Yet the recognition of agile in contractual relationships has lagged behind, which is odd given that a large part of IT is done by contracting someone.

When all is sunshine and daises this doesn't matter. The time you really really want your written agreements to be right is when things go awry. If you're doing business even with friends & family, it can help to have something in writing.

But how to write a contract for something when you know it's going to change?

This problem came up in a linked-in architects' discussion and I immediately reached for google to find my notes from Susan Atkinson's presentation on Agile Contracts (I saw her present at a Rational User Group conference a couple of years ago). I reduced it to bullet points in /p1201/susan-atkinson-features-of-an-agile-contract, and she was good enough to drop by to correct & update it. She's been developing an Evolve Contract Model with Gabrielle Benefield and the website should be up soon. Meanwhile there is a recent presentation on slide-share at Contract Metrics For Agile.

For those not yet convinced that there's anything wrong with a waterfall-style contract and project, you can read the IEEE 2013 conference paper at http://www.slideshare.net/SusanAtkinson2/ieee-2013-the-flaws-in-the-traditional-contract-for-software-development. nb Open it full-page mode for easy reading.

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.