The IT industry is constantly searching for ways to bridge the communication gap between user and developers.
Methods to achieve this started to emerge in the 90s (RAD, DSDM,Scrum etc) and have blossomed, if that’s the right word, into a family of techniques referred to as Agile. Essentially all these methods try to ensure that developed software is shown to users as early and often as possible so that misunderstandings or omissions can be spotted and dealt with early on.
As often happens in IT, Agile became the buzzword of the early 21st century and no self-respecting supplier could admit to using any other technique, regardless of how well they understood it or whether the technique was a good fit to the project in hand. Unsurprisingly “Agile” projects have become a regular feature of my expert practice in the last 5 years.
On the positive side, one project I reviewed was a Salesforce based development conducted by a smallish supplier for a start up. The project manager was effective and had implemented simple but effective Agile ritual. This meant they could supply me with recordings of “show and tell” sessions and most usefully a Google doc in which the customer had recorded his acceptance of each sprint. A great example of simple tools used effectively and providing cast iron evidence that the client’s complaints were largely unjustified.
In contrast, I’ve witnessed several suppliers who seem to think that being Agile simply means chewing your way through a list of features with little or no interaction with users.
The biggest problem though is that Agile is often used as a synonym for ‘fast’. As in ‘your required timescales are very challenging but we’ll use Agile methods to bring the project in on time‘. Given that Agile fundamentally requires the project to change direction if the results of a sprint don’t meet user’s requirements this is an approach that is doomed to failure.
Either the project does apply Agile properly and there are inevitable delays as the direction is tweaked after each sprint, or more commonly in disputes arriving on my desk, Agile is abandoned altogether, replaced with a variety of approaches varying from the ‘we’ve developed it so you’ll have to put up with it’ approach to a random walk through a sea of functional specifications and change requests.
It can be difficult for clients, particularly at management level, to work out if a supplier really understands Agile , so here are some questions that may help flush out the bluffers;
- How will you make sure the software conforms to an overall technical, database and user interface design?
- How have you estimated how long this project is going to take?
- How much testing effort does your plan include?
- How are you going to monitor progress and tell me whether we’re on track or not?
- Who are your scrum masters and can I meet them?
If any of these questions are met with blank looks, ‘we don’t need that‘ or ‘trust us, we know how to do Agile‘ you’d be well advised to look elsewhere, or at least delve further into how exactly your supplier plans to deliver.