Talking about agile – Dan North
Agile. Has a word had more interpretations, more connotations, more expectations? When the pioneering souls first wrote down the Agile Manifesto – a simple but deceptively subtle definition of what agile means – little could they have realised how the concept would be used and sometimes misused over the subsequent years.
Dan North is a consultant, a teacher and a writer blogging with the byeline “faster organisations, faster software”. He cut his teeth at the renowned software house Thoughtworks and with his trademark cap he looks like the tech world’s Angus Young (of AC/DC). But make no mistake he is super smart and perhaps the clearest thinker on modern agile software delivery I’ve seen or heard. Here are some of his insights that I particularly like:
There are no best practices. That’s quite a startling thing for a consultant to say. I worked in consultancy for 13 years and I saw how partners would sell the on notion of delivering best practice and how clients would lap it up. However, as he rightly says best practice implies absolute definitions of behaviour, without reference to context, and that stifles a creative environment and will likely frustrate your best people. He argues that at best, so called best practices enable a person or a team or an organisation get to “advanced beginner” level – not much for anyone to aspire to.
Look for the opportunity cost / beware the art of misdirection. There are many techniques associated with agile – e.g. stand-ups, pair programming, behaviour or test driven development (TDD or BDD), burn down charts, iterations, build automation and any number more. The temptation is to try to adopt them like so many baubles on a Christmas tree. It is better to consider each on their own merits and with a view of what else may be done instead (i.e. the opportunity cost). So, TDD may be perfectly laudable if the end goal is well established and you are looking to build repeatable quality, but if you are still teasing out a product or customer concept putting it in place will likely divert attention from getting a clear view of “the why” (hello Simon Sinek!)
Spike and stabilise. I believe that perhaps the most important thing programme leadership can do is to be thoughtful about the uncertainties (aka risks or unknowns) their programme faces. Maybe the product concept is unproven, maybe the technology is new, maybe the business change is unknown, maybe the cutover is fraught with risk, maybe the operational requirements are especially demanding. Sequencing programme activity with these in mind gets the right questions asked at the right time. “Spike and stabilise” is the idea that instead of deciding at the start whether to build production grade code or to prototype, to go through a series of discovery “spikes”, each followed – depending on the results – with a period of refactoring and stabilisation. I like this as the spikes can be set up with any of the risks in mind, allowing course correction as assumptions are either proven or disproven.