Use Demos to Build Trust

In our first article — Stay Agile with Discovery” (May 11, 2016)— we discussed how to use a discovery project to show a non-agile customer or sponsor the benefits of going agile. Now we will focus on building trust with a client who is ready to consider agile approaches.

After the discovery project, Martha was ready to use AgileSoft again for more development. (Recall: Cindy is the Product Owner for AgileSoft’s clients, and Bob is Cindy’s contact at Acme, representing Martha’s interests.) As Martha reviewed the first set of deliverables, she realized she had to define requirements for many small projects to get “everything” she wanted. She now realizes that “everything” changed over the course of all the little projects. She liked the idea of release criteria guiding their decisions. But what if she wants to change the release criteria?

Martha also thought about all the time (and money) Cindy’s team spent to estimate each monthly release. Martha wondered if it was possible to not estimate so often and still have a good idea of what Cindy could deliver. Martha realized she had asked Cindy’s team to estimate because of the way she wanted to work. She also realized she wanted more flexibility about what Cindy’s team would deliver on a regular basis.

Martha felt safe when her vendors committed to an estimate, even though they often submitted change-orders. She hopes that taking a risk to partner with Cindy more closely might pay off, and she felt she could trust Cindy to deliver what she needs.

Martha has a new, approved requirements document. How can she work with AgileSoft now?


Now that your client are open to an agile approach, you can use demos to build trust, deliver working product, check to see that the project continues in the right direction, and give the customer something to give new feedback about.

At the first demonstration (two weeks into the project), Cindy walks through each story and demonstrates the feature or fix.  After each story Cindy asks Martha and Bob, “Is that what you expected to see?” She gave them space to discuss the feature, and noted changes or new ideas which were generated from the discussion.

Bob and Martha enjoyed the process, and felt free to give “change-focused” and “reinforcing” feedback (what’s not working and what’s working). Cindy watched Bob and Martha’s faces closely, noting either delight or disappointment, and asking them to explain what they were thinking. At first she had to draw out their thoughts, but her continued interest helped them feel comfortable giving their honest feedback.

Each demonstration built trust between Cindy, Bob and Martha. Their discussions become more open, and less guarded. Martha appreciated that Cindy wanted to deliver an excellent product, not simply fulfill a contract.


In the third iteration, Cindy had questions from the team. She walked Martha and Bob through a paper version of the user interface. Martha asked, “Why didn’t you mock this up as we would see it on the web site?”

Cindy answered, “In my experience, you would be disappointed, because you wouldn’t have the back-end to use. You would see the front, but not be able to use the feature. When we started the project I promised I would only show you working product, and I want to keep that promise to you. We might develop each feature incrementally, such as your secure login. We have stories for login-as-known-user, change-password-as-known-user, add-a-user, right? We have more stories, but that’s what we started in the first iteration.”

Martha and Bob agreed. Cindy continued, “We implement each of those separately, because they are all stories. There are more stories, and we don’t know which ones you want first. With this transaction processing, we need enough information about the user interface so you and I can work together to define which stories come first, so we can build incrementally. But, I can show you the user interface flow on paper to get your feedback to validate the stories. And, as we build the stories, we can show you how we are building the entire transaction.”

Just as a mechanic wouldn’t let you take your car for a drive without brakes, Cindy knows when saying “No” is best for the client.

It is acceptable — and a  good idea — to demo prototypes. When you demo a prototype, even a paper prototype, you have the chance to received feedback and check that the project is going in the right direction.


The demo provides you an opportunity to check that everyone is happy with the product direction. The demo will often spark new ideas in your customer’s mind — ideas for refinements or improvements that they had missed before.

At the next demo, Cindy walked Martha and Bob through the implementation of the previous demo’s paper prototype. Martha and Bob were happy at first. Bob wanted a minute to review the flow.

“Cindy, now that I’ve seen this in implementation, I think we need to present the search results differently,” Bob pointed to the screen.

“Okay. What do you want to see instead?” Cindy took out her paper prototype from the previous demo.

“I’d like to see this data bunched together in some way, and that data in a list,” Bob said.

Martha sat up and said, “No, I don’t want that. That won’t work for me or the people in marketing.”

Cindy said, “Okay. I’ve seen this problem before. Let’s go back to why you want this feature at all. Who are all the users? What benefit do they receive? Once you both understand that, I’ll know if we are looking at separate stories or the same story. Please write down all the users and all their benefits. Then we’ll decide what to do.”

Bob and Martha wrote for a couple of minutes and realized they were thinking about different users. They needed different stories to deliver the necessary value.

Cindy knew it was Bob and Martha’s decision to come to an agreement about the direction, and that she shouldn’t rush to try and figure it out. Too often she’d see teams promise that all stakeholders would get what they wanted, and delivered something that no one wanted.


Bob and Martha work for a few minutes before coming to agreement. What they decide on is different from what was originally estimated, but it is the right way for the project to proceed.

Martha asked, “How does this change affect the project budget?”

Cindy remembers a time when she would have given an estimate on the spot, to try and reassure Martha that she was “professional.” Instead, she builds trust by being honest about what she knows, and gives Martha choices.

Cindy replied, “I don’t know yet, but I can ask the team to estimate those changes. You have a couple of choices. You can say, “Do this now,” and we will drop something lower on the backlog and do this instead. You might ask us to estimate it and put it somewhere in the roadmap. Or, we can add it into the project and let you know when we can get to it. This is why I like to work off a product roadmap for the project.”

Martha decides that this change in direction is important, and prioritizes the change for the next iteration. She also decided what she can drop from the project, because she wants to manage her costs.


Martha realized she could get what she wanted. She also realized she could manage her project costs because Cindy checked with her and Bob every two weeks.

Martha realized she didn’t have to know everything perfectly in advance. She liked the idea of adding and re-ranking stories as she discovered their relative value. She also appreciated that Cindy was not upset when she changed her mind, which made her trust Cindy more.

Martha also appreciated that Cindy was able to facilitate Martha’s and Bob’s disagreement on stories.  Some vendors promise that everyone will be happy, but Cindy seemed to understand that Bob and Martha must come to an agreement to move forward. It was their decision, and Cindy gave them time and tools to make it.

The demos built the trust needed for Cindy, Martha and Bob to partner and create a great solution.

PreviouslyStay Agile with Discovery

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.