Agile Lifecycle Management, Thinking Fast and Slow and Who Knows What Else

The thing that I wanted to get to in the original post about design is that there's too much emphasis on ex-nihilo creation (creation from nothing) and insufficient emphasis on continuing to maintain a platform. Once you've thought through the things that I was talking about in the "unintelligent design" article,  you realise that having code that's testable and maintainable isn't a nice to have  - it's the absolute bedrock.  If you’re not paying attention to that all the time when you’re developing, you’re heading for unmaintainable legacy code.

I wish I could remember which William Boyd book it is.  But one of his novels has a character whose father is a surgeon at the point where the entire profession is starting to realise the importance of cleanliness and anti-septic practices.  But some of the profession – some of the senior members of the profession are still operating in blood-soaked frock coats and refuse to accept that they should sterilise their instruments, wear specially laundered clothes and wash their hands.  I think there’s something of that about software at the moment. Lots and lots of excuses about why writing automated tests is a waste of time. It’s the movement clockwise around the cynefin (http://en.wikipedia.org/wiki/Cynefin)  framework away from chaos and through the complex space towards the “merely” complicated. It sorts the mavericks into visionaries and idiots and maybe that’s a harsh and unfair classification but it has to happen.

And what I’m thinking now, with the work I’m currently doing – is it even worth coaching on methods when there’s such resistance to the “hygiene” of test-driven development and automated testing?  Was it worth pioneering surgical techniques when 90% of the patients died of shock and the rest succumbed to sepsis?  I don’t know those figures – I’m guessing. But now, I suppose the answer is yes.  Wouldn’t it have been even more tragic if we’d had hygiene but no surgical skill?  But isn’t it interesting the order that things came in.  I read a book called “The Bluffer’s Guide to Management Consultancy” and it reminded me that surgeons were called consultants at the point where they basically new *nothing* about medicine.  Consultant is what you call yourself when you’re firmly rooted in the top left-hand corner of the Cynefin framework.

I thought of cognitive dimensions almost the first instant that I started this coaching engagement. And it’s coupled to the whole thinking fast and slow thing. You want to arrange all of the artefacts and data that you’re dealing with in a development project so that they have the right cognitive dimensions – which is another way of saying that you want to foster/afford the right kind of fast thinking.  For example, it would be really good to be able to visualise the backlog on a project in some way other than as a line graph.  Visualising the backlog seems to one of the things that the issues tracking systems that are supposed to be Agile Lifecycle Management systems are worst at.  You also need to visualise velocity in some kind of way that hampers them doing the WRONG kind of “fast thinking” about it.  The minute people here velocity they want to compare it to the velocity of another team – and simultaneously double it.

In my experience, Agile Lifecycle Management tools on their own are very difficult to use. Nothing beats a card wall for tracking the stuff that you’re actually working on at the moment. And a card wall actually works as a pretty good index into the ALM.

One of the areas where I’ve seen loads of projects get snarled is around metrics.  In my experience, people behave very strangely around numbers.  For example, when someone senior at a previous company I worked for heard that the velocity of a ten person team was 30 ideal days for an iteration, their “fast thinking” response was to tell everybody who would hear that the team only worked three days a week and be outraged. The thing about my boss finding prime numbers more persuasive than numbers that have factors is absolutely true.  And the sad truth is that you’re not going to stop these random “fast thinking” reactions to the numbers that a project produces. It’s also very dangerous and counterproductive to point out how stupid these reactions are.  Likewise it’s dangerous to act on these stupid reactions.

That’s the main thing you’re fighting when you’re trying to get people to adopt an Agile approach – their “common sense” fast thinking.

What I think you need to do is fight fire with fire.  You simply can’t fight fast thinking with slow thinking .  You need to fight it with fast thinking. People can process visuals and charts better than they can process numbers.  So what you need to do is to give them charts which “encourage” the right kind of fast thinking.  I’m not sure I know the answer to what those are.

On the few occasions that people ask my advice on what they can do to improve their project management, I’m tempted to say “hire a fine art undergrad and get them to produce lots of visualisations of your project data.”

One thing I’m certain of – a burn-down is nearly as useless as a table of numbers.

Posted via email from The Ginger Mumbly