16   Get Frequent Feedback Using Demos

“It’s not your fault; the problem lies with our customers—those pesky end users and clients. They always come up with so many changes, way past the deadline. They should just figure out what they want once and for all and then give us requirements so we can implement the system to their satisfaction. That’s how it ought to work.”

Oftentimes you might hear that people want to “freeze” requirements.^[17] It turns out that real-world requirements are as fluid as ink itself. You can’t freeze requirements any more than you can freeze markets, competition, learning, evolution, or growth. And even if you tried, you’d almost certainly freeze the wrong ones. If you mistakenly expect your customers to give you solid, well-defined requirements before the start of your project, be prepared for major disappointment.

Nobody’s minds or perspectives are frozen in time, especially not your project’s customers. Even after they tell you what they want, their ideas and their expectations continue to evolve—especially once they begin to use portions of the new system and start to realize its impact and possibilities. That’s just human nature.

As humans, we get better at what we do—whatever that is—slowly and incrementally. So your customers, after giving you the requirements, will be constantly figuring out ways to get better at using the features they asked you to implement. If all you do is take their initial requirements and implement them, you will certainly not be anywhere close to satisfying their requirements by the time of delivery—the requirements will have changed. You’re exposing yourself to one of the biggest risks in software development: you’ve produced what they asked for, not what they’ve come to want. The result? Surprise, shock, and disappointment, instead of satisfaction.

---

Figure 1. Computed trajectory of a spacecraft

Years ago in a numerical analysis course, Venkat was asked to simulate the trajectory of a spacecraft using some partial differential equations. The program worked by figuring out the position at time t+δ based on the position at time t. The program’s plotted trajectory looked something like the dashed line shown in Figure 1, ​Computed trajectory of a spacecraft​.

Notice the estimated position of the spacecraft was a long way away from where it was in reality; gravitational effects on the spacecraft’s velocity did not just happen at each of the positions we decided to calculate. Instead, the effects of gravity happened all the time; it was continuous, rather than discrete. By ignoring the effects between the points, we kept adding errors to the calculation, and our spacecraft ended up in the wrong place.

Reducing the iteration interval (the value of δ) and running the calculations again reduced the overall error. This time the estimated position (shown by the solid line) was much closer to the actual position.

Imagine your customer’s expectations are like the actual position of the spacecraft. Your success in software development is based on how close you end up to your customer’s expectations. The discrete positions you calculate are opportunities to show the customer what you have done so far. These are the times when you get their input and feedback. This feedback then changes the direction you take when you set off on the next leg of the journey.

It’s pretty easy to see that the larger the gap between when you get their requirements and the time you show them what you’ve done, the further off course you’ll be.

At regular, consistent intervals, such as at the end of an iteration, meet with your customers, and demonstrate the features and functionality you’ve completed so far.

If you consult with your customers frequently, getting their input as you develop, everyone benefits. Your customers are more aware of the progress you’re making. As a result, they are able to refine the requirements, first in their minds and then, by giving feedback, in yours. They are able to steer you based on their evolving understanding and expectations, and you are able to program closer to their actual needs. The customer can prioritize the tasks in the context of the progress you’ve made and the available time and budget.

Is there downside to seeking frequent feedback in shorter iteration cycles? In the spacecraft trajectory program, it took longer for the program to run when δ was decreased. You may be wondering if using shorter iterations will slow things down and delay your project.

Think of it this way: imagine getting all the way to the end of a two-year project only to realize that you and your customer had a fundamental disconnect when it came to a key requirement. You thought back orders were handled one way, but your customer meant something totally different. Now, two years later, you’ve produced a system that’s a million lines of code away from the one the customer wanted. Undoing a goodly portion of two years worth of effort is going to be expensive, to say the least.

Instead, imagine you had shown them demonstrations of the system as you went along. Two months into the project they say, “Wait a minute; that’s not what a back order is supposed to do.” This triggers a panic meeting: you review the requirements and assess the changes needed. It’s a small price to pay to avoid a disaster.

Andy says:

Keep a Project Glossary

Inconsistent terminology is a major cause of requirements misunderstandings. Businesses have a tendency to attach very specific, important meaning to what appears to be common, innocent-sounding words.

I’ve seen this happen quite often: programmers on the team will use different terminology than the users or businesspeople, and the resulting “impedance mismatch” causes bugs and design errors.

To avoid these sorts of issues, keep a project glossary. It should be publicly accessible, perhaps on an intranet website or Wiki. It almost sounds trivial—it’s just a list of terms and their definitions. But it helps to make sure you are actually communicating with the users.

Throughout the project, choose appropriate names for program constructs—classes, methods, modules, variables, and so on—from the glossary, and check to make sure the definitions continue to match the users’ expectations.

Get feedback often. If your iteration cycle is quarterly or annually (which is too long), reduce it to weekly or biweekly. Proactively get customer feedback on the features and functionality you are implementing.

Develop in plain sight. Keep your application in sight (and in the customers’ mind) during development. Bring customers together and proactively seek their feedback using demos every week or two.

What It Feels Like

After some start-up period, you should settle into a comfortable groove where the team and the customer enjoy a healthy, creative relationship. Surprises should become rare, and the customer should feel they have an appropriate level of control over the direction of the project.

Keeping Your Balance

• When you first propose this method of working with the customer, they may balk at the thought of so many “releases.” It’s important that they understand these are internal releases (demos) for their own benefit and aren’t necessarily targeted for distribution to the entire user community.

• Some clients may feel that daily, weekly, or even biweekly sessions are too much for them to handle. After all, they already have full-time jobs.

  Be respectful of their time. If the customer is comfortable with only monthly sessions, then monthly it is.

• Some customer’s staff may be assigned to participate in your demo sessions as their full-time job. They’d like nothing better than hourly feedback and demos. While that may work out great, you might find that’s too much for you to handle and still produce any code for them to see! Scale it back so that you meet when you’re really done and have something to show.

• The demo is intended for customers to give you feedback and help steer the project. It is not supposed to agitate or annoy them because of lack of functionality or stability. If it’s not stable, don’t show it. Set the expectations about functionality early and clearly: let the customers know that they are looking at an application under development, not a final, finished product.