How many times do we complete an agile user story or backlog item and end up with something like this?
Holes in the wall from where we changed the requirements 10 times during the sprint; picture is crooked because that is what the final requirement said; picture is not centered on the wall because we already put too many holes in the sheet rock there.
Let's be honest here. If you hired someone to come to your house to hang a picture on your wall, and he ended up doing a job like the one above, you wouldn't think it's your fault. Neither do your users or your business people. They look for the guy with the cheesy grin holding the hammer.
From his perspective it makes sense. Before he even looked at your wall, he asked you to draw a picture of your living room. He asked you to give him the exact dimensions of the picture you wanted to be hung. He even asked you for the exact height and horizontal distance to hang the picture. You couldn't provide him with any of those things, so instead you gave him the best description of your living room, the size of the painting and where to hang it. With that he did the best he could and hung the painting on the wall. You didn't hear from him again until he was “done.” (Some strange person from his company even came by and did a bunch of measurements with a tape measure, checked the strength of the nail and a bunch of other tests, and finally also stated it was done.)
You take a look at the work. Nicely anchored to the wall, as level as possible, exactly in the wrong place. You quibble over the work for a bit. He pulls out his tape recorder and plays back your exact description of the site and how you wanted the picture hung. As he plays it back he points out how he did exactly what you asked. And he is right, sort of. What he did matches what you said, the only problem is what you said could be interpreted several ways. The way he interpreted it wasn't what you intended; he should have asked more questions. As you look at the placement of the painting, you realize the original height, which he actually did get right, is not what you want anymore, now that you can see the painting on the wall.
You try again, trying to be more specific with your requirements this time. He asks a lot more questions, you have a hard time answering without seeing the project. Finally, after some time you agree on how it should be done, and he sets out to tear down the old painting and re-hang it again. You don't hear from him again until it is “done.” The process repeats, more holes in the wall, more playing back your words. He's honestly trying to do a good job, you're honestly trying to tell him what you think you want, but it is hard upfront.
Finally, you end up with the picture above. Lots of holes in your wall and a crooked painting hung in the wrong place. It is not what you wanted, but rather than go through this process again, you decide you can “just make it work.”
Can you see the problem yet?
If you're exclusively blaming either party here, you're not looking hard enough.
The problem is, you would never hang a painting like this. If you were going to hire someone to hang a painting, you would stand there in the living room while they held the painting at various levels and locations against the wall. Someone listening nearby might hear:
“Higher, higher… ok now stop. Wait back lower again. How about a little to the left? Hmm, I don't think it is quite straight. Ok, now it is. Yeah that looks good. Honey, what do you think?”
What about you?
So, how are you developing your backlog items or user stories? Are you doing them like the first example, where you are asking for all the requirements upfront and then building what you think the business person wanted? Or, are you doing like the second example where you are working with the customer as you build the solution, not putting nails in the wall until you know you have built what the user wanted?
As developers, especially if we have come from a waterfall background, we have the tendency to want to get all the requirements upfront. It is often difficult to figure out how to work with the customer to build the solution instead of simply gathering the requirements and then doing the work. There may also be barriers in your organization which prevent you from doing so.
Here are some tips to help get the customer involved:
- Co-locate. The best way to communicate is face to face. If you have to email, message, or call your business person or customer, you are adding overhead which makes it less likely to happen and more difficult.
- Keep the story about the business problem, not about the solution. This will force you to talk to the customer about the solution later.
- Don't try to do one upfront design for the story. Instead have mini-design sessions as you go.
- As soon as you have something to show to the customer, show it to the customer, even if it is on your own development work-station, even if it is a picture you drew with a marker.
- Have the customer develop or co-develop the test cases with the team or person doing the testing. Developers should be building the thing that passes these test cases.
- Figure out who the real customer is. You may not be able to control this much, but sometimes the person pretending to be the customer isn't the person who will actually use the product. If this is the case, you have to find a way to solve this problem or have a good representation of the real customer.