Some thoughts after getting the chance to lead a retrospective at Aptivate, a super non-profit doing IT for NGOs and other charities:
It can very hard to explain agile development to customers. Even if your immediate contact understands and accepts the notion of an optional-scope contract, their superiors may not. And those who accept the idea of participatory development and appear to commit to regular interaction with developers may not actually deliver when the time comes. Aptivate are developing project and contract blueprints that should help them avoid this kind of problem in future. (Nice to see how they are working on this – rather than trying to allocate a block of time to write the document from scratch, they are adding to it as they find problems. A little effort at a time, proportional to current problems, is much more effective, we’ve found.)
Reflective processes like five whys and retrospectives are really important to the success of an agile team. Aptivate already have very autonomous and highly motivated developers, thanks to the great work they’re doing, but I expect providing processes that help those developers to analyse and improve their work regularly will make a big difference in making their team really self-organising.
Even in tiny organisations, you can get subgroups who don’t understand what others are doing. Just within our seven retrospective participants, I counted five project teams who were missing information about what the other teams were doing! One group was particularly isolated because of a language barrier, a challenge most of us don’t have (at least when we have co-located teams). Aptivate are using video to promote their work externally, and are thinking now that they can use it also to document and share what they are doing internally. I’ll be interested to see how they get on with this!
Paper Workers, 1934, oil on canvas by Douglass Crockwell.
Two thoughts on a talk on Software Craftsmanship by Corey Haines and Chris Parsons at the London Ruby User Group (LRUG):
- An important group was (probably) missing at LRUG: non-developers. You need to explain to and bring along customers, management, product owners, operations, testers, and executives if you want to start adopting the craftsmanship principles. For instance, it’s quite understandable that business people could hear “Not only working software, but also well-crafted software” and think “Oh no, more gold-plating and fewer features”. They need to understand – and more importantly, to measure and observe – that better-crafted software means sustainable pace, fewer bugs, and better features. Chris appears to be trying to do this with his marketing for Eden Development.
- It was good to see Corey and others acknowledging that there may be value in code that isn’t well-crafted – it can make sense in lower-risk projects or as a stepping-stone to better code (e.g. a prototype). By analogy, Corey says he sometimes buys off-the-shelf furniture and used in the right place (say, a utility room) it can be more effective, though less attractive and long-lived, than a beautifully-crafted heirloom piece. We should remember too that it takes a different, perhaps more sophisticated craft to produce a machine that cranks out a hundred flat-pack beds an hour in an Ikea factory – I remember Rasmus saying that by design, “any idiot can write a PHP script”, and that designing PHP to allow this while keeping said idiots relatively safe required some very sophisticated techniques!