Showing Your Customers the Respect They Deserve
Agile teams must lead the way in valuing and respecting their customers.
Customer engagement is often touted as one of the essential elements of a successful Agile project. You cut down on communication overhead, make quick trade-off decisions as needed and deliver the software faster to the customer.
A common quote I've heard is: "The customer must be engaged on a regular basis to ensure success." This sentiment is cartoon-ified in a YouTube video entitled "I Want to Run an Agile Project." This is a funny video put out by a consulting company. It tells the tale of a fellow who wants to run an Agile project in an old-fashioned bureaucratic organization. In the video, the Agile manager is trying to get the customer more involved in the project.
The Agile manager tells the customer his team will deliver software to him faster if the customer is involved on a daily basis. The customer tells the Agile manager that he's a very important and busy person and can't do that. In the end, the customer doesn't get involved and doesn't get the software he wanted. I would call the story a comedic tragedy.
The video is well done and worth a watch. Several scenes in the video ring of truth. However, the video does reflect an attitude I want to take exception with: Agile teams expect a customer can and should be involved in the project on a daily basis -- so if the customer isn't involved, and the Agile project fails, it's the customer's fault.
Construx CEO and Chief Software Engineer (and software development thought leader) Steve McConnell gave a keynote ("The Journey to Organization-Wide Scrum") at a Scrum Alliance gathering. In it he described how development organizations tried to implement Scrum and failed. What was the common failure point? Those implementing Scrum expected everyone else to change to meet their needs.
This attitude is wrong and disrespectful. It's not collaborative and it's sometimes used as a standard excuse if the Agile project fails: "If the customer were only more involved …"
Instead, I believe the following to be true: Successful Agile teams actively engage their customers. Not the other way around.
Customers are very busy and important people. The successful Agile team finds a way to engage customers on the customer's turf, rather than waiting for the customer to come to theirs.
Who Is the Customer?
The word "customer," of course, is really a proxy for any project stakeholder. It can be your project sponsor, a product manager, an end user or an actual customer who pays for your product. It could represent one customer or many.
So, how should an Agile team engage customers?
Start with the Correct Attitude
The team's attitude should be one of respect toward the customer. I've worked in too many organizations -- including my college days as a fast-food employee -- where customers become the enemy. This is a very easy trap in which to fall. Some recreational complaining is fun, of course. However, the team must strive to have this attitude: "The customer is valuable and we depend on them, not the other way around."
This attitude should drive every interaction with the customer. When I was a consultant, I tried to give my customers what I called a "compelling sense of security." That is, I wanted them to feel so taken care of that they were compelled to trust me. With any assignment, my goal was to manage it in such a way that they could relax and know it was being handled. When they trusted me, they gave me more of their time, because they felt their time was valued.
The team should be more prepared and have better follow-through than the customer. Thorough preparation and strong follow-through earn the customer's trust. When a customer trusts you, they'll open up to you. They'll become invested themselves, because they see you're working to invest in them.
Pictures, Not Words
Here's how to damage the relationship with your customer in three easy steps:
1. Create a lengthy document for them to review.
2. Give them a deadline, chosen by you, by which they need to review it.
3. Tell them if they miss the deadline, the project is held up.
Ouch. I hate to admit that I've actually done that. Reviewing a lengthy text document is a taxing process. It requires both time and mental energy. Most customers have little of either left over after working their day job.
Storyboarding is a technique that uses a series of pictures to tell a story. For example, if you had a new feature, "register for a new account," the storyboard would show what each step in the process would look like. This allows the customer to experience the new functionality as they watch the story unfold. Storyboarding has its origin in film production. A serious of pictures tells the story of what the film will eventually depict. People can experience what the film will be like and make adjustments before filming starts. Storyboarding for software works the same way.
A human's brain reacts very differently to pictures than to text or speech. When reading text or listening to speech, the brain expends a great deal of energy converting the data into a picture in their mind. When they give feedback, it's based on the picture they've created.
This conversion is performed by your prefrontal cortex, which is the part of your brain used for intensive problem solving. The prefrontal cortex requires a lot of energy and is a limited resource. With storyboarding, the user spends less energy translating ideas into a picture -- leaving them with more energy to evaluate the solution and compare it to what they need.
Storyboarding is a great example of "meeting the customer on their turf." The pictures don't have to be polished, but the storyboard must be complete enough to tell a full story, and that takes effort. By creating the storyboard, the team has done all the mental heavy lifting. The customer gets to experience the story and provide their reactions. It tells the customer: "Your time is valuable, we want to respect it."
PowerPoint is a great tool for this, because it's fairly ubiquitous and a simple yet powerful drawing tool. Visual Studio offers a storyboarding add-in for PowerPoint, which provides some rich functionality to enable you to create a storyboard. I can speak from experience and say this add-in is quite useful. (Full disclosure: I work on the Visual Studio team.) Tools such as Balsamiq are great solutions as well.
Form Your Inner Circle
I formed a customer advisory council late last year, recruiting people who were actively dealing with the problem my new feature was trying to solve. The goal of the council was to provide real-world feedback on the proposed design, to make sure it solved a real-world problem.
We met every two to three weeks for one hour using online meeting software. Often I presented to them a storyboard, depicting what the feature would be like. Sometimes I presented an important question I needed answering. We always had a great discussion, and I found the hour to be extremely valuable. I would take the feedback, rework my design and present the updated design at the next meeting.
There was no prep work required for those serving on the council. They could just show up, see the storyboard and provide their feedback. I invested time in each storyboard so the council could quickly absorb the ideas and provide their feedback. In other words, I saw their time as extremely valuable, and I tried to be as prepared as possible.
I've done a couple of these councils and I'm about to start a third. I can say that this is by far the most valuable practice I've ever implemented in designing a feature. Having a group of customers highly invested in solving the problem with me is amazing. I really came to appreciate the people on the council and, through that, the "customer" got a face. The seven people on the council went from being "customers" to being people I wanted to help. I wanted to make their life better. I was sad when my design didn't work. I was happy when they said it did. I became emotionally invested in their happiness.
In addition to that, something unexpected happened. The customers really appreciated being involved. They found the meetings enjoyable and if I didn't schedule one, they would ask me when the next meeting was planned.
I believe that everyone wants to be part of something bigger than themselves. If they can see how their input is making a real difference, that's rewarding and fun. I tried to take every opportunity to tell these customers how much they were helping me. Not only because it was true, but because I wanted them to know how valuable they were.
In this article, I've listed three approaches to becoming better engaged with your customer. It's not an exhaustive list, of course. However, I hope you're seeing the underlying theme. Respect your customers, value their time and treat them as people (not stakeholders). Just like any relationship, you need to invest in your customers, and then they'll invest in you.
Gregg Boer is a Principal Program Manager at Microsoft with 25 years of experience in software. Over his career, Gregg has worked as a Project Manager, Program Manager, Requirements Lead, Software Engineer, Analyst, QA Lead, and Software Designer. Gregg joined Microsoft in 2005 because he believed in the vision of Team Foundation Server. Currently, Gregg is working on the team developing a set of world-class Agile Tools built on top of the TFS Platform.