There’s a good post from a recent acquaintance Colin MacAndrew that I read this morning that challenges what appears to be the currently held world view that the only way to develop software is in an agile framework, and any agile project that fails is down to the execution, not the method. Colin talks about different dimensions of projects in terms of complexity and predictability, and then extends out to a concept of almost an anti-methodology, “liteness”.
Colin’s article has crystallized something that has been banging around my head for a while about context for agile methods, and it’s to do with the people factors…
In a gross oversimplification, software development methodologies have generally been about finding a process to be able to take a set of requirements from some people, translate those into the architecture of a computer system, and then build that system. Waterfall methods of old (SSADM, like what I was taught at University, and all) generally start from the principal of wanting to document every thing possible in terms of requirements, and then start the work to translate those into software. Agile methods (remember, still in gross oversimplification) tend to start building as soon as the requirements gathering starts, and the two processes run more in parallel rather than in sequence. This addresses a couple of common issues with waterfall approaches: by the time you’ve finished documenting, the world has moved on and the requirements have changed, and it’s not until you start building stuff that peoplereallyunderstand what their requirements are.
The challenge with both of these approaches that strikes me is that it is based on the idea that there are a group of people (“stakeholders”) who not only know what they want, but are the right people to ask in the first place. In a commercial software product (or online software service), you find out whether the product managers made the right calls in development by whether the software is commercially successful. The problems can arise when the software is being developed within an organisation, particularly when it is being developed to provide extension of a service delivered by a cost centre like HR, Finance, IT or Legal. What’s the issue? The internal monopoly…
Imagine an HR operations manager wants a new system to be able to help them provide a service within an organisation. They do the business case, pull together the budget, get their management support, and get the green light to go. They now become the software commissioners – the “customer” of the software development organisation. They make decisions about what is right or wrong, and they may or may not be doing that from the perspective of them themselves being a service provider to the business in which they work. My experience says that too often they do not take account of their service-providing role, and the end result can be a system that pushes work onto people who have little or no involvement in the decision-making processes that led to that work being generated (“self-service” is the euphemism often used at this stage – “DIY” might be a more appropriate term).
Don’t get me wrong – I’m not saying that this always happens – but it’s not infrequent. Bring agile into the equation, and if you have the wrong stakeholders involved in the game, then what you get is stupider, faster. At least with waterfall methods the long gestation period could sometimes kill off a bad idea.
Avoiding this pitfall? Careful and measured analysis of who needs to be involved in a project up front before any of the work starts (if it’s left, as often is the case, to a “Communications” strand of work then it’ll all be too late: stakeholder buy-in comes from getting them involved, not just developing an elaborate marketing plan for roll out). The “Rich Picture” technique from Soft Systems Methodology is an exercise that takes maybe little more than an hour, but can often drive out a whole deep understanding of who needs to be really involved in a project for the project to be a success. I’ll write a bit about my experience of Rich Pictures in a few days’ time.