Feedback: victim or beneficiary?

Feedback takes many forms, some is explicit and some can be inferred, even the absence of interaction is a form of feedback. Some if obviously well-intentioned, and some less so, some is invited and some is thrust upon us.

When you accidentally cut someone off in traffic, the feedback they give may be in the form of a horn and a hand gesture. There is no question this is feedback, it may even be useful when you have stripped away the anger and your defensive response – I did after all miss something, they are helping me see something I didn’t see myself and now I will at least have the option of improving my behavior in similar situations in the future.

Improvement is MY choice

Please note the word ‘option’, the decision to change my behavior is mine, I can choose whether I respond or how I respond, giving a peer feedback does not compel them to change the way you want them to, regardless of how forcefully you may give the feedback.

Many times you will receive conflicting feedback, or sometimes you just disagree with it. When someone gives you feedback and they are asking you to change behavior remember it is you that needs to change and there is no one Youer than You. It is up to you, you can choose what or whether to change.

A Feedback Culture

I work in an organization where there is a very strong culture of self-improvement and professional development, but there is also a distinct absence of management, we therefore rely heavily on feedback from our peers. Our internal processes encourage formal and informal peer feedback.

In an Agile community we rely heavily on feedback loops for improving our processes, stand-ups, demos retrospectives, not to mention the metrics we encourage in our development practices. These are all opportunities to respond to the feedback as a team to help us improve.

Peer Feedback

However, individual feedback from peers is much less structured and much less objective so it becomes much harder for the giver or receiver to be objective in the way they give or receive the feedback. Peer feedback is by nature personal and when things get personal the stakes get higher. We give feedback in a subjective way, and we receive and we respond to feedback in a subjective way, both are cursed with perspective.

Ostensibly the goal of feedback from the perspective of the giver is to affirm behavior we approve of (e.g. clapping and cheering) and to discourage behavior we dislike or disapprove of (booing). Context is also a factor we may be motivated personally or professionally.

For the receiver of feedback it is ostensibly to aid us in seeing things we are unable to see, to gain another person’s perspective on something. We may get to see things we can’t or don’t see for ourselves e.g. Am I speaking too quietly.

Whether the feedback is invited (“Can you hear me?”) or not (“Speak up!”) we are benefiting from another’s perspective on a situation.

Attitude

Sound’s great! But the attitude of the giver and receiver play a much more significant role in peer to peer feedback, and in how effective or valuable that feedback is, and what the consequences on the relationship are.

Let’s go back to the person I accidentally cut-off in traffic. Whilst there is benefit in being reminded that I need to pay more attention to my blind-spots I doubt very much the person cut-off and is giving me hand-gestures was overly concerned with my personal development or in helping me become a better driver. The reality is that their goal was not to help me improve, it was to vent their frustration, to express anger and to feel better in themselves by ranting at me, my welfare was not even remotely the concern.

And so it is with peer feedback, there are times when I really want to express my opinion, I don’t care whether the person improves, what matters to me is that I get my say and I can express MY feelings. This can come off as spiteful rather than supportive. and leave the person feeling a victim.

Victim or Beneficiary

The “feedback culture” has created an opportunity for some people to express a desire to ask to “give feedback” when really they are taking an opportunity to give someone a piece of their mind in a situation where the ‘victim’ feels they cannot respond. By calling it feedback we get a free punch and if they react badly or refuse to be verbally punched we can claim they are not acting in the spirit of feedback. I worry this is damaging our culture and is a misappropriation of feedback, the result is the artificial harmony we were trying to get away from. Dressing an attack up as feedback does not change it.

Before giving another person ‘feedback’ we need to reflect on it ourselves and consider whether our true desire is to help the person improve. Do we truly desire the subject to be the beneficiary of our feedback or is the act of giving feedback more about satisfying your own need for satisfaction and they are just the victim of your feedback.

Spirit of improvement

Please understand that I am not saying that the horn and the hand gesture are not feedback – clearly they are. Nor that I can’t respond to the feedback and improve. It is a question of the spirit of the feedback as much as the message itself. If I feel the feedback is given in the spirit of helping me I am far more likely to respond favorably, if I see the feedback as a veiled attack I am as likely to resent the message and in some extreme cases I may retaliate – I am less likely to see it as an opportunity for improvement.

Is your true desire is to help the person improve or do you want to make them feel bad? Do you want a good relationship in future? Then perhaps be more considerate of your approach. We all make mistakes, and we can all improve so let’s make the effort to be kinder in our delivery of the message – not necessarily the subject. Feedback needs to be clear and should not shy from difficult issues but the delivery can make all the difference.

TRUNK Test

When we rely so heavily on relationships and on feedback it is important to apply the TRUNK test for offering feedback:

Is what you are about to say TRue, Useful, Necessary, and Kind?

How do I know I am delivering Value?

Many of us are relatively familiar with the notion that stories should be expressed in terms of value delivered (Why) and how important the “Why” is for being able to maximize the outcome for the customer–

Who: As a …

What: I want to :

Why: So that …

When we talk of good stories we refer to INVEST as a means of helping validate that our stories are well written, I think this is a great tool for helping write user stories, we may even include Acceptance Criteria to help the team identify that the story has been completed in such a way that the value is best able to be realized, but I’d like to propose going a step further.

Expected Vs Actual

Whichever way the story is written the assumption is that the PO has determined the value of the story and prioritized it accordingly, but value is a very nebulous term and encapsulates all sorts of things many of which are assumptions or just plain guesses or personal preferences. We are also making the assumption that the story will successfully deliver the value we intend. Rather than accepting that it is a hypothesis that it will achieve our goal.

Up to this point we are assuming that the Product Owner is always making the right decisions, and their assumptions of the value delivered by a story are infallible. Speaking as a Product Owner, that is a rather hopeful assumption, often value judgements are little more than educated guesses, certainly they are very subjective opinions on value. Even market research is guesswork to some extent and particularly with new products or internal systems there is little opportunity for effective predictions of value. I don’t want to take anything away from the PO and their authority on making these judgements that is after all their role. But as a PO I would very much value a feedback loop which would enable me to validate that my decisions were right or wrong and give me the opportunity to course correct accordingly.

In other words it is necessary for us to make judgement calls but getting feedback on the accuracy or otherwise of those decisions would be hugely beneficial.

So what can we do?

We could add to the Acceptance Criteria to include some additional validation. Our Acceptance Criteria helps us validate that a story is implemented the way we intend it to be implemented, it does not however always enable us to measure whether the value is fully realized.

For example:

Assumption: We believe that adding a picture to listings on a product website will increase sales by 10% (our market research says so).

As an online customer,

I want like to see pictures of products

So that I can make more informed buying decisions (and thus buy more products) –

(Business Value: Marketing estimates sales increase of 10%)

Our Acceptance Criteria may stipulate positioning of the picture, the size and what to display if a picture is not available. We may even add some performance Acceptance Criteria such as average page load time. But that is not enough to validate that the value was achieved.

How do we validate that a story delivers Value

But how do we validate that this story does actually deliver the value we expect – whilst we can be confident that having a picture fulfils some aspects of the value – the better informed decisions, it might be that we are missing out by not having the ability to zoom on the picture, or it may be that our users are not bothered by the picture at all and would prefer another feature such as the “lead time” or “quantity in stock”

Validation Criteria

What if as part of this story we not only implement the feature to show the picture but we also include analytic measurements on the page load times, and even a measurement for the number of sales of a product or products per day and then evaluate 50% of users with the new feature and 50% without the pictures and compared the results. Or we could conduct focus groups on this feature or usability studies to get more subjective but detailed feedback.

As part of the story we could add an additional layer of Validation Criteria, this would be similar to Acceptance Criteria but would be a way to measure the value actually realized by the user

What do we gain?

Would including functionality or activities that enable us to measure that we have delivered the value we are expecting make the stories better? Would that information help shape our product and build a better product? Would it help us prioritize our backlog as we get a better understanding of value actually delivered vs value expected to be delivered?

We could either add stories for these measurements or consider these to be encapsulated in the delivery of this story.

Essentially we are asking whether feedback is valuable and if it is – how valuable is it to us.

Return on Investment:

When discussing this with a colleague the first response was that this is putting more upfront work and that is a challenge for the ‘lazy’. In Agile ‘Lazy’ is a virtue so this is important feedback.

Naturally there is an overhead in this but as with all feedback loops the information is valuable, knowledge is power and we just need to tune our efforts – our feedback volume to the right level to get valuable information with the minimum necessary effort. Another example of an Andon Cord where if the effort is too much and producing either too much information or nothing of value then we need to retune our feedback loops to give us enough valuable feedback to act.

Also many of these measurements will be applicable to multiple stories so the investment may end up being very limited but the feedback may be far reaching, and once automated the ongoing feedback can be tweaked to add extra sensors to give us more and more valuable information.

Some examples of value assessing measurements:

Website analytics: hit rates, click through rates, hot spots etc. The cost of these is minimal and is often something that can be applied even after development.
We could write stories to build into our application measurement for how our product is used, or the performance of our product,
We could add usability testing or focus groups, surveys of users
By using feature flags we could set up effective A-B testing to get feedback on structured hypothesis validation.

Please note that not all measurements need to be software driven – increased subscribers say may be measured entirely independently of your application.

Vision

But ultimately the biggest change would be in your initial vision creation, do you know your product goals and do you have a way to measure success.

Is your goal increased sales, or time saved, or efficiency improvements, or increased users or cost saving and regardless of your goals do you have a plan for measuring whether your product is achieving your goals.

This may seem like stating the obvious but I cannot count the number of projects I have been on where the stated aims were cost-saving or revenue generating and numbers were stated and yet after the project was authorized no one ever went back and assessed whether the project was a success or achieved any of it’s aims. Having an aim was enough to get the project started. Claiming a 10% increase in sales or reduction in costs should be something you can measure so measure it.

Ironically being able to map a story to one of your stated goals for the product could be another way to filter unnecessary stories if the expected impact is not one of your product goals.

Summary

This is a very simple change to your story writing process – an extra little consideration that could have significant implications to the success of your product, the addition of a very valuable feedback loop on value delivered (rather than value expected)

As a …

I want to …

So that …

And I can verify this by …

Post Script:

I presented this notion to a Product Ownership Meetup and the response was amazing the conversation was full of so many great ideas, and examples of how some of the product owners are already putting this in to practice – not explicitly but have made usability and measuring usage a key part of their Product Ownership methodology. I love the conversations this group has each month, but this month I came away with so many new things to think about.

The highlight of which was Goldratt Users stories – which will be the subject of my next blog.

Tell me how you measure me and I’ll tell you how I will behave – Eli Goldratt

Feedback is not a passive activity

In Lean manufacturing setting up feedback loops is considered a critical part of the operation, so much so there is a term for this – Andon – a system to notify management, maintenance, and other workers of a quality or process problem.

The principle is that it gives the worker the ability, and moreover the empowerment, to stop production when a defect is found, and immediately call for assistance. Workers are encouraged to use this feedback mechanism freely. Common reasons for manual activation of the Andon are part shortage (dependency), defect created or found, stoppage, or the existence of a safety problem. Work is generally stopped until a solution has been found.

Loosely translated an Andon is a Paper Lantern – To shine a light on a problem.

Sounds great in principle, any worker is empowered to give feedback to management if they have concerns over safety quality or even a weakness in a process, but for it to become culture it needs to be adopted in a no-blame manner and used frequently, lack of utilization of an Andon is a serious problem and is addressed in Lean.

If a feedback mechanism is not triggered regularly then the settings are considered too loose. The threshold for triggering an Andon would continually be made tighter and tighter, quality is expected to be higher, time for a task is squeezed and so on until there is an increase in frequency of Andon being used.

The aim is to get a regular feedback of actionable information, too little and the feedback loop has failed, too much and you cannot see the problem so it needs tuning and adjusting slowly.

What does that mean to us in a non-manufacturing environment?

We have got pretty good at retrospectives and giving feedback locally, but feedback to management is largely absent.

The difficulty in many organizations is that senior management hide behind an open door policy. “Employees can talk to me any time, my door is always open”. It is very easy to pretend you are open to feedback but much harder to actually be open.

“Employees can talk to me at any time, my door is always open”

– the unapproachable manager

In many cases the open door is actually an invisible barricade: fear of retribution, fear of not being supported, fear of being ignored, fear of the messenger being shot. In many cases the fear is justified, but even when it isn’t, it doesn’t make the fear any less real to those with genuine feedback to share.

Creating Feedback Loops

Just like with Andon, this is feedback that should be sought and encouraged and your measure should be how frequently you are given constructive feedback from your employees, if you are challenged regularly and respond to it regularly then it is working, but if you are not getting regular feedback (from those outside your inner circle) then it is likely your “open door” is not that open.

Has someone in the last week given you critical feedback without being asked?

If on the occasions you do explicitly ask for feedback are you bombarded with hostile questions? Do the questions catch you by surprise? Do people seem dis-satisfied with your responses? Do you only ask for feedback when people quit? If yes then perhaps you are not asking for feedback often enough, or are not responding to the feedback you are getting.

Feedback is not passive

Feedback is generally not passive, you need to invite it, create forums where feedback is invited and expected, be open to the feedback and when you are not willing to change be prepared to explain yourself, and be prepared to repeat yourself.

It really comes down to whether you truly are a feedback culture, if you are you have to work for it.