The most important ingredient in a software project is timely user feedback to developers. In order for that to be effective, users and developers need to communicate well with each other. That’s not always easy because users and developers speak different languages, and often come from completely different viewpoints. From a user’s point of view, developers can be defensive and dismissive. From a developer’s point of view, users can be imprecise, incomplete, and arbitrary. This habit helps improve communications and improve feedback.
✓ Critical ❑ Helpful ❑ Experimental
First steps to create this habit:
Was communication successful? Do the developers understand what users are saying, are users able to communicate their wishes to developers successfully? One way to check is like this:
Hello users and stakeholders, now that we’re alone, we have an important bit of information for you:
Developers typically focus on technology and logic.They don’t start with a strong knowledge of your business processes or language. The words you use that have very specific meanings to you may mean nothing to them, or mean something else entirely different.
Developers have invested hours, days, even months to create the software they are showing you now. If it’s not quite right or worse, you are effectively telling them they have wasted all that time.
We want to keep that from happening. And we’re not alone: it’s not easy to give constructive feedback in a highly technical, creative endeavor such as software development. It’s not easy with high-budget films, either. Pixar has long been praised for their working environment as they handle these and other issues. Their rules for feedback include:1
When in doubt as to how to provide feedback, it might be helpful to start with a formulaic approach. Here’s a simple recipe you can follow:
For example, start off by stating what you observed, perhaps “Screen layout doesn’t match data/work flow” and “Too many mouse clicks.” Then explain what that means to you: “I have to learn to shuffle stuff mentally as the incoming data doesn’t match the layout.” Why does that matter, what’s the significance? “It takes me extra time to do my job. There’s a possibility of lost/garbled data. Extra clicking aggravates my carpel tunnel syndrome.” Finally, ask if the developers can make it better—and explain what “better” means in this context. “It would work better for me if…”
It is helpful to consider that developers don’t make software for users, they make software with users. Sometimes we’ll all get it right, and often we won’t. But failure or error is not the end of the world. In fact, it’s just the opposite. Identifying a problem is the critical first step in fixing it. Pixar’s CEO puts it this way:
“To disentangle the good and bad parts of failure, we have to recognize both the reality of the pain and the benefit of the resulting growth. …We need to understand failure not as something to fear or try to avoid, but as a natural part of learning and exploration.”—Ed Catmull, Pixar
The GROWS Method® is all about learning, exploration and growth. That means that discovering an error isn’t about keeping score or proving you’re smarter than someone else, it’s about learning what the software should do in order to be more valuable.
Remember, it’s not that important to get it right the first time. It’s critically important to get it right the last time. Use the MustBePresent habit to help get it right.
←Prev (Must Be Present)(ClearBugReporting.txt) Next→
Cited in [(Edmondson, 2019)] ↩
Follow @growsmethod in the Fediverse, or subscribe to our mailing list:
Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.