Chapter 4
Delivering What Users Want

Your customer gives you the requirements and expects you to deliver an application in a few years. You go off and build the system based on those requirements and eventually deliver it on time. The customer looks at it and says it is good. You move on to the next project with a very happy and loyal customer on your résumé. That’s how your projects usually go, right?

That’s not the case for most folks. It’s more common to see users act shocked and/or unhappy. They don’t like what they see, and they want many changes. They demand features that weren’t in the requirements they originally gave you. Does that sound more like a typical project?

“No plan survives contact with the enemy,” said von Moltke. The enemy in this case isn’t the customer, the users, your teammates or management. The necessary enemy is change. In warfare, as in software development, the situation can change quickly and drastically. Sticking to yesterday’s plan despite a change in circumstances is a recipe for disaster. You can’t “defeat” change—whether it’s the design, architecture, or your understanding of the user requirements. Agility—and successful development—hinges on your ability to identify and adapt to changes. Only then will we be able to develop on time and within budget, creating a system that actually meets the users’ needs.

In this chapter we’ll examine practices that lead toward these agile goals. To begin, we’ll see why it’s important to keep users and customers involved and ​Let Customers Make Decisions​ (starting here). Design is a fundamental part of software development. You can’t develop well without it, but you can’t let it become a straitjacket either. See how to ​Let Design Guide, Not Dictate​, beginning here. And speaking of straitjackets, you’ll want to make sure the technology you introduce on a project is appropriate. You’ll need to ​Justify Technology Use​ (see how here).

In order to keep your software accessible to users, it needs to be ready—always. To minimize disruptive changes from integrating new source, you’ll ​Integrate Early, Integrate Often​ (that’s here). And it almost goes without saying that you don’t want to break existing code; you want to always ​Keep It Releasable​ (that starts here).

You can’t waste any precious development time getting new features ready for users to look at over and over again, so you’ll ​Automate Deployment Early​ (see how here). By having code always ready to go and easy to deploy to users, you can ​Get Frequent Feedback Using Demos​ (it’s here). That allows you to release to the world at large on a more regular basis. You want to ​Use Short Iterations, Release in Increments​ to help stay fresh and close to the evolving user base (we’ll start talking about that here).

Finally, it can sometimes be difficult to get customers on board with the agile approach, especially if they demand a fixed-price contract up front. But the reality is that ​Fixed Prices Are Broken Promises​, and we’ll see how to work around that starting here.