The aims of agile software development are beyond reproach: prioritising rapid delivery of working software that does what the user wants. But the application of agile methodologies can leave a lot to be desired – with frequent delivery of code mistaken for progress and users calling the shots but not understanding what they want. Here are five dangers to look out for when following an agile software development methodology.
1. Two steps forward, one step back
Agile, in the case of one of its commonest forms known as Scrum, breaks down projects into iterations that deliver potentially workable software within two to four weeks. The scope of what is being delivered from iteration to iteration can vary dramatically based on feedback from users.
This flexibility is one of the strong suits of agile. The finished software product doesn’t have to be set in stone years in advance and therefore is more likely to be relevant to a business’ needs on completion.
However, being blind to certain future demands can lead to products being developed in a way that doesn’t support those iterations, says Mike Gualtieri, principal analyst with Forrester.
Gualtieri gives the example of business users who ask developers to allow customers to look up their account history during one iteration, and then in the next iteration ask developers to allow customers to combine their account history with that of family members.
Situations such as this one leave the development team frustrated at having to go back to alter previous work, according to Gualtieri, saying, “I wish you told me that before. I didn’t anticipate that when I created the database structure.”
Also, while agile is supposed to control scope creep, there are reports that the iterative design process can lead to users demanding a multitude of changes at each iteration – making it difficult for developers to deliver.
2. Users don’t know what they want
Agile methodologies are designed to produce the software the user wants, after all the stakeholders are involved in the development process from the start.
However, people are not always the best judges of what they want. As Henry Ford supposedly said about his decision to bring the automobile to the mass market: “If I had asked people what they wanted, they would have said faster horses.”
The problem with developers relying too heavily on users to tell them what they want is that users are limited by their understanding of the underlying technology, according to Forrester’s Gualtieri.
“Say there’s a mobile app. A business person can envision the way that mobile app would work but may not be aware there’s an accelerometer and GPS, and how those can be used in combination to do some fabulous things,” he says.
Of course the end product of an agile project is supposed to be the result of a meeting of minds between the developer and the business user, rather than one leading the other.
However, the resulting product is frequently not a joint effort, according to Gualtieri, but instead the result of developers letting the user make the design decisions so they can get on with the coding.
Having business users guide coders is no substitute for a developer with a deep understanding of the business domain, he says.
3. Not ready for automated testing
The rapid delivery cycles under agile make software to automate testing a necessity to keep the quality of the product and the code from slipping.
The cost of adopting automated testing and the hassle in changing ways of working to accommodate it can seem more bother than they’re worth.
But failing to introduce automated testing makes it tricky for manual testing teams to keep on top of bugs during the short delivery times for each iteration of the software – particularly as the overall code grows in size.
4. It’s hard to get buy-in
For businesses with a long history of developing software using alternative methodologies, switching to agile requires a profound change in the way everyone from software maintenance teams to management operate.
Yet people are creatures of habit and getting the maintenance team to drop their demands for a library of documentation isn’t easy.
Getting everyone involved in a project to understand how they and their colleagues can work and mitigate risk without extensive documentation to fall back on will take a long time – for example, in the case of the Wellcome Trust it took 18 months.
Time commitments can also be onerous both for developers and business users. The IT team and the rest of the business will have to be prepared to devote regular blocks of time to discussing project requirements and outcomes, which they need to fit around the daily demands of the job.
5. Agile ignores the creative nature of coding
Critics of the agile movement claim it embodies a wider problem with software development methodologies – that the focus on process ignores the creative nature of programming.
Forrester’s Gualtieri says software development is more akin to making a movie than building cars on an assembly line.
“With these processes and methodologies, people want to take software developers, say they are all created equal, and put them into a process, turn a crank and software will come out,” he says.
“But software is a one-off. It isn’t a product of an assembly line. We need to recognize the design and creativity that goes into it.”
This focus on process ignores how important design decisions are when developing software, he says.
“In software development design decisions determine everything from how long it’s going to take to develop the software, to how good the user experience will be.”
