Chapter
5
Agile Feedback
One test is worth a thousand expert opinions.
In an agile project, we’re always seeking feedback in order to make many small, continuous adjustments. But where does all this feedback come from?
In the previous chapter, we talked about working closely with users—getting good feedback from them and acting on it. In this chapter, we’ll talk primarily about getting feedback in other ways. As Bill Nye observes, tests of any sort are definitive; we’ll implement that idea to ensure that you always know the state of your project’s health and don’t have to guess.
Many projects get into trouble when the code base gets out of hand. Bug fixes beget more bugs, which beget more bug fixes, and the whole pile of cards comes crashing down. What we need is a constant monitor—a constant source of feedback to make sure the code base hasn’t deteriorated and continues to work at least as well as it did yesterday, if not even better. We’ll see how to Put Angels on Your Shoulders to watch out for your code starting here.
But that won’t stop you from designing an interface or an API that’s cumbersome or hard to use correctly. For that, you’ll need to Use It Before You Build It (which starts here).
But of course, just because it works for one unit test on your machine doesn’t automatically mean it will work the same on any other machine. See why Different Makes a Difference, starting here.
Now that you have decent APIs and clean code, it might be a good idea to ensure that code actually produces the results the users expect. You can Automate Acceptance Testing to make sure the code is correct—and stays that way. We’ll take a look at that here.
Everyone wants to see progress on a project, but it’s easy to go astray by watching misleading indicators or to fall prey to the false authority of a pretty Gantt or PERT chart or a nice calendaring tool. Instead, you want to Measure Real Progress, and we’ll show you how here.
Although we talked about working with users to get feedback during development, there’s another time—long after the product has been released—when you need to once again Listen to Users, and we’ll explain starting here.