Tech & Work

Agile development: Five ways it can trip you up

Agile software development is often praised for helping combat scope creep and late projects. But making the transition to agile delivery is fraught with potential pitfalls. Here are five to look out for.

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 recognise 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."


Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.


My finding is that people tend to talk forever (almost religiously) about which framework has problems, and which is best etc etc. To make things work you need strong leaders, a good vision, and to make space for creativity from your people. I work in a mixture of Agile and Waterfall environments, and can see strengths and weaknesses in each... My advice for leaders : focus on your people, and use your project management toolbox! Don't obsess on any one framework! Jeff -


Agile Software Development isn't focused on the business or application but on making the customer/user "happy". This is its fatal flaw. Any project should be based on a process model. In the case of a business, the Business Model is a broad range of informal and formal descriptions to represent core aspects of the business, including purpose, offerings, strategies, infrastructure, organizational structures, trading practices, and operational processes and policies. A business model is the method of doing business by which a company can sustain itself. That is, generate revenue. The business model spells-out how a company makes money by specifying where it is positioned in the value chain of its market(s). A business process is a collection of related, structured activities or tasks that produce a specific service or product (serve a particular goal) for a particular customer or customers. There are three main types of business processes: 1. Management processes, the processes that govern the operation of a system. Typical management processes include "Corporate Governance" and "Strategic Management". 2. Operational processes, processes that constitute the core business and create the primary value stream. Typical operational processes are Purchasing, Manufacturing, Marketing, and Sales. 3. Supporting processes, which support the core processes. Examples include Accounting, Recruitment, Technical support. A business process can be decomposed into several sub-processes, which have their own attributes, but also contribute to achieving the goal of the over-all business process. The analysis of business processes typically includes the mapping of processes and sub-processes down to activity level. A business process model is a model of one or more business processes, and defines the ways in which operations are carried out to accomplish the intended objectives of an organization. Such a model remains an abstraction and depends on the intended use of the model. It can describe the workflow or the integration between business processes. It can be constructed in multiple levels. A workflow is a depiction of a sequence of operations, declared as work of a person, work of a simple or complex mechanism, work of a group of persons, work of an organization of staff, or machines. Workflow may be seen as any abstraction of real work, segregated into work shares or units, work components and their process and/or order of assembly. For control purposes, workflow may be a view of the methods of real work employed to complete them.

Tony Hopkinson
Tony Hopkinson

Not in practice it isn't, because in the main our customers are not flexible, they just expect us to be...


Whether agile or other methodology, projects cannot help but creep when they start by defining the product to be built, which is a form of design. Creep largely results from the product not meeting the REAL business requirements deliverable _whats_ that provide value by achieving objectives when satisfied by the product _hows_, which occurs because the REAL business requirements have not been defined adequately, in turn largely because people think the product feature requirements are _the_ requirements. Discovering the REAL business requirements takes more and different skills and knowledge than even many experienced analysts have. Agile relies on the user representive/product owner, who seldom has any analysis skills or knowledge, to define requirements as brief user stories which the team translates directly into product features that the project will implement with programming. Although not product features themselves and presumably preceding definition of the product, user stories often actually are derived from a prior conception of the product the project should produce. Ironically, by calling resulting rework 'refactoring' and considering it a virtue, agile masks its issues and prevents meaningful truly agile improvement.

Tony Hopkinson
Tony Hopkinson

In that the customer doesn't end up waiting 90% to 120% of the project lifetime to discover the project doesn't meet their needs in a useful way, it's an absolute boon. That was the problem agile was invented to address. Unfortunately while there are several different flavours , all sorts of BS, hype and pseudo competent consultants about writing reams of drivel about how to do it, the why got lost somewhere in the dogma. The problem can be encapsulated in one statement. Agile is what, then when. If the answer to that is everything, yesterday, all you have is waterfall with no discipline, disguised with pre-adolescent jargon. The thing we have to remember as IT pros, is our customers don't want to expend any more resources than funding us to get what they eventually realise they should have wanted then, now... Until that changes, we are high tech scapegoats.

Editor's Picks