Coffee | Coding | Computers | Church | What does it all mean?
I'll be speaking at the International Association of Software Architects UK Summit in April, together with Alan Gawthorpe.
Our subject is "Doing architecture with agile teams" and in a short session we'll be covering both the 'human' angle of working with agile teams and the more technical question of what kind of architecture might count as agile (and is it any better than non-agile architecture).
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.
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.
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