Challenges of Being Agile

Often, introducing agility into your project can involve a trade-off. For example, certain levels of documentation and modeling may be scrapped so that the team can “travel light.” Striking the right balance can be difficult.

Here, in our view, are the top 10 challenges of being agile.

10. Sticking to the Path

Many agile processes, though low ceremony, are high discipline and require consistent effort from the whole team to keep the project on track. You may well find that you start to do certain practices less (e.g., if you’re using pair programming, team members might start to pair up less). Agile processes put various safety nets in place to lessen the impact when you fall. (Of course, some processes have more safety nets than others, as we discuss in Extreme Programming Refactored: The Case Against XP.)

If you’re finding it increasingly difficult to maintain certain practices, it’s time to review the process. Perhaps a particular practice is too difficult because it simply doesn’t fit your project. There may be an equivalent practice (or group of practices)—something easier—that you could do instead and that your team is more likely to stick to.

9. Keeping Releases Short

Short releases (i.e., releasing working code to the customer on a rapid turnaround) can be difficult to keep on doing, for a number of reasons. Examples include interface changes, database changes, user retraining, and help file rewriting.

Similarly, it’s tempting to stop doing short releases simply because they’re so difficult. Funnily enough, the answer in many cases is to release more often (a similar solution to difficulties associated with continuous integration; see the section titled “Continuous Integration” later in this chapter for more information).

8. Keeping Entropy at Bay

Even in nonagile projects, software designs degrade over time because new requirements emerge, and the software needs to be made to do things it wasn’t originally supposed to. In agile projects the risk is higher, because requirements are analyzed in smaller groups; releases and iterations are smaller, so the team isn’t looking ahead quite as far.

While this approach solves many problems, it does mean that agile practitioners must keep a closer eye on the design, regularly refactoring to keep it in trim. In short, unit test your code and have a realistic strategy to manage change, or watch your project “decompose” in all the wrong ways!

7. Doing Less Without Increasing Risk

Cutting down on the wrong things increases risk (e.g., design, testing, and drawing certain types of diagrams). So it’s important to know which practices you can safely do less of (see Figure 1-2). These practices can also vary from project to project.

Reducing contingency (i.e., removing safety-net practices such as testing and code inspections) can save time in the short term, but it also increases risk. Make sure your agile process gives you more options for when things go wrong, not fewer.

6. Discovering Your True Master

Always remember that the “customer” is not one person—not even one role—but is usually several people covering the roles of end user, domain expert, decision maker, and project sponsor. Similarly for product development, different groups of people will try to pull the project in different directions: the marketing department, customers, the QA department, the company directors, and so on.

Losing track of this important fact increases the risk of project failure, because requirements can be flung at you from unexpected quarters, or a key project stakeholder might become disgruntled because her interests aren’t being upheld in the project.

5. Keeping the Customer Involved

Increasing the customer’s involvement may not seem like a challenge, but it certainly can be. Active stakeholder participation is a key principle in agile development, and it can greatly increase the chances of your project succeeding. However, not all customers want the additional responsibility that certain agile processes give them. They might prefer to “rule from afar,” signing off on requirements and waiting for the finished project to be delivered. Your team might interpret this as aloofness, but it’s more likely that the customer, like most people, is just incredibly busy. Even agile projects (or should that be especially agile projects) need to tailor their process to suit the customer.

While there’s no silver bullet solution to this difficult situation, ICONIX Process can help because of its emphasis on requirements exploration and disambiguation.

4. Managing Change

While some agile processes positively encourage change (rightly seeing a change in requirements as an increased business opportunity for the customer), it’s easy to lose sight of the risks and expense that change can cause. Without controlling change, we forget to do our utmost to get the requirements right early in the project, and the result may be requirements churn.

3. Training

Introduction of a new way of developing software can potentially cause misunderstandings (e.g., programmers who wrongly see agility as an invitation to hack: “Woo hoo—no design!”). In some sense, the way that some agile approaches have been marketed makes this problem worse than it should be. (For example, telling programmers that they can skip documentation is a bit like selling catnip to cats.)

2. Avoiding the Other Extreme

Agility brings with it many promises and possibilities. There may be a temptation to throw the whole organization onto the agile bandwagon. Transitioning to an entirely agile process just can’t be done overnight—it must be taken in stages (depending on how deeply ingrained the “big monolithic high-ceremony development” culture is in the company).

1. Facing Resistance to Change

Speaking of development culture, you may find that your organization is stuck in high-ceremony gear: every “i” must be dotted and every “t” crossed. This deeply ingrained attitude is possibly the single biggest challenge to running an agile project.

In organizations that are traditionally high-ceremony, ICONIX Process should be a more acceptable agile process than others because of its core emphasis on requirements gathering, UML, and up-front design. Enterprising developers or managers may see ICONIX Process as a “way in” for agile processes in such organizations.