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.

4 thoughts on “Avoiding “stupider, faster”…

  1. Hi Matt,

    Apologies if I’m a little late to the party in commenting on this one – I’m trying to catch up 😉

    I’m going to read up a little more on the “Rich Picture” technique before suggesting I know too much about it, but I thought one of your other points was worthy of comment. In your example, the HR manager becomes the “customer” of the software development organisation. This is touching upon something that I’ve experienced all too often: people internal to an organisation being labelled as the customer. Having done some research in this area, I believe this notion is based on a misinterpretation of Joseph Juran’s work in defining the Internal Customer. The misunderstanding surrounding this has been one of the main contributors to the silo based behaviours seen in organisations today (how many times for example have you heard an IT department refer to ‘the business’ ?) in my opinion. So the question for me, like you, is how do we start recognising that customers are not within the organisation but outside of it, and adjust our delivery functions accordingly?

    We both seem to agree that the customer doesn’t actually know what they want. I tend to assume that there are a lot of assumptions that need to be tested as a result. My favoured approach to that is to do lots of small experiments to test these assumptions. Those experiments take many forms and I will defer the commitment that is writing software for as long as is sensible, but I’ll confess that I tend also to deferring writing documents to capture requirements for an even longer time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.