Feedback is an important ingredient to successful projects. One reason teams use iterative approaches, either time boxed sprints or single piece flow, is that they have the opportunity to get frequent and rapid feedback. A few recent experiences have inspired me to think a bit about how helpful feedback can be and some subtle aspects of feedback that are important to keep in mind.
Feedback tells you if you are heading down the right path
The need for feedback is rarely questioned these days, and has been suggested as far back as Winston Royce’s paper on Managing the Development of Large Software Systems (hint, look at Figure 3 on the third page). You want to get feedback early and often so that you can quickly identify if you are not heading down a path that will satisfy your stakeholder’s needs. Compare this to using a printed set of directions from google maps with navigating using a GPS that includes information on road construction and current traffic.
A list of directions is certainly helpful for getting from where you are to your desired destination, and they can be even more helpful when you are not familiar with the destination or the space in between. Directions printed from a Google maps, Mapquest, or similar application take advantage of the best information available at the time you print them, but they do not take advantage of current information while you drive. You may follow the directions exactly and still find yourself staring at a road that was closed after you printed your directions because a bridge got knocked out by a semi truck that was too tall. A set of printed directions is similar to projects that start with the assumption that you can do all of your planning at the beginning (establish the list of directions) and rely on those directions throughout. The directions provide a good picture based on what you knew when you printed the directions (created the plan), but events that place in the meantime reduce the usefulness of those directions.
Driving with a GPS provides you with the most current information because the GPS continuously collects information (feedback) about current road construction and traffic levels between you and your destination. GPS also responds (some more insistent than others) when you happen to take a wrong turn and get you back on track. You may not end up taking your originally planned path to get to your destination, but you will get there. Driving with a GPS resembles iterative approaches that regularly provide new information and allow you to revise your approach. Both the GPS and feedback in iterative approaches provide you up to date information you can use to decide whether changes in your approach are necessary to get your ultimate definition.
Frequent feedback can be very helpful, and there are some subtleties involved with how you get that feedback that I wanted to mention.
Feedback from those who disagree with you is important.
I’m in the final stages of a project I’ve been working on for several years. My second book Beyond Requirements: Analysis with an Agile Mindset is scheduled to be available September 21. One step in the process of writing a book is to send a draft of the book to several experts to review the content. I went through that step earlier this year and received some very helpful feedback from five individuals who graciously read through the manuscript and provided feedback. This is an important step because getting their feedback before the book is finalized helped me get a reading on whether the book was on target.
Some of most helpful feedback was from someone I’ll call Bob the Book Reviewer. It was immediately apparent that my outlook on the world of IT Projects and Bob’s were quite different. While there were many aspects of the book he liked, there were a few things that he was adamantly opposed to. I was all set to disregard most of his comments, but before I did, I ran them by one of my mentors Todd. I was hoping that he was going to tell me that I was right to ignore the feedback, but instead, he said in several cases that Bob had a good point.
I’m not proud that I was about to discount feedback that didn’t agree with my world view, but I am glad that I got a second opinion before I did so. Thoughtfully considering Bob’s feedback helped me to explain some of the concepts covered in the book in a way that (hopefully) makes sense to those who don’t necessarily hold the same assumptions that I do. I believe the book is stronger and a more useful resource as a result.
The lesson here is that you need to pay attention to feedback from those who disagree with you or that are not completely in support of your project or product. Their feedback often identifies weaknesses in your work that people who share the same beliefs as you do may not point out, or may not see themselves. That’s not to say that you are going to follow all of their advice, you can’t do that with anyone, but you should at least consider all the feedback they provide and think about where it’s coming from. Understanding the inspiration for their comments may help you determine weaknesses in your efforts.
Don’t overlook different sources of feedback.
There are some stakeholders that you may ignore because they disagree with you. There may be other stakeholders you just don’t think of as having actionable feedback. Don’t discount these stakeholders because they may have unique relationships with your ultimate users or customers that can generate some very helpful information.
I had the opportunity to work with the tech support area in a software product company. Tech support wanted to understand agile software development better so that they could interact more effective with engineering and product management. During the discussions I realized that tech support had a lot of great information about how users actually used their product, and the problems users often ran into. Engineering invited tech support to their demos to get feedback on new functionality being built, but did not engage with tech support about what features to deliver in the first place. To be fair, tech support was not providing that type of information to Product Management and engineering either. This was a case that everyone involved didn’t realize that information from tech support could be useful for making roadmap and priority decisions.
The lesson here is to look for feedback from different parts of your organization, keeping in mind the relationship those different parts of your organization have with your customers and users. It’s also important to remember that as you expand the sources of your feedback to properly consider all of that information in relation to each other. That can also include information that you get from sources other than people.
Feedback does not always have to come from people.
I helped another organization with their inception planning efforts in order to determine their main focus for the next three months. We used a variation of impact mapping to determine the most valuable features to work on based on their key objectives. One feature that rose to the top of the list was one that did not appear anywhere on any of the existing product management roadmaps. The team realized that they needed to collect information about how (or whether) their customers were using functionality of their product. This is a kind of feedback, and it’s an important kind to supplement feedback that the team gets from their customers. It provided them with a way to validate assumptions they had and to confirm or question what their customers were telling them. This kind of information is important because even when you have a good relationship with your customers, you should always be a little skeptical about what they tell you. This is the idea Brandon Carlson discussed in his Agile2012 session Stop Listening to Your Customers. Don’t take this to mean that you shouldn’t listen to your customers at all. It’s best to practice the idea of “all things in moderation” where you balance talking with your customers with analyzing hard data on usage.
As with the organization that wanted to collect more usage information, you may find that some extra work is required to record that information. That work may not initially be very high on the priority list of features, it’s still very important to do for the long term health and success of the product. Think of it as an investment to aid future planning.
Set the expectations of those giving you feedback.
One final subtlety that is important to remember is to set the proper expectations with those who are providing the feedback. There’s a good chance that you will get a lot of feedback, some of which contradicts each other. That is to be expected and is fine. However, in order to make sure that you can continue to get feedback from those people whom you asked, it’s important to let them know that you appreciate their feedback and will consider it seriously, but you may not use all (or any of it). Without setting those expectations, you run the risk of not being able to get feedback from those individuals in the future.
Now it’s your turn.
Do you have some feedback for me on this article? Please leave a comment. I can’t promise that I’ll make every change you recommend, but I’ll sure listen and consider your feedback carefully.