Breaking Bad - The Cult of not Giving Bad News

Anthony Boobier, Practices Coach BNZ Digital, nomad8.com, @antboobier

Why is it so hard to break bad news? Why is there a cult of people who do not want to give bad news about their projects to stakeholders? Why do we let our fears cloud our judgement? Things can seem bad when they don’t go as we planned and hoped, but in reality things ‘just are’. As Esther Derby [1] notes "The ability to ‘face the truth’ and take effective action rests on the ability to be in a mental state where our emotions and fears aren’t running us". How do we remove that fear and emotion, create an environment in which we are not afraid to break ‘bad news’, into ‘news’ that allows us to make informed decisions [2,3].

What is 'Bad news' anyway?

Bad news is information that conveys negative or unpleasant information that is likely to disappoint, upset or even anger a recipient. So what news would do that to someone on a project? Take, for instance, the following piece of news that needs to be presented back to the stakeholders:

"The feature has taken longer than expected to develop and user testing has thrown up the need for a number of changes"

Is that news 'good' or 'bad'? The fact is it is neither, it is just 'news'. It is feedback or information on a current state. What makes it 'bad' is the context in which it is delivered and the human emotion that goes along with it. If that news were delivered at a smaller scale as rapid feedback, in a collaborative environment, where the whole team was awaiting the answer; it could be construed as 'good' news.

Conversely what if that news was a surprise to the stakeholders? If it were given at a large scale after 6 months of work, tracking to a contract that looked to deliver a pre-determined output? Someone would be sorely disappointed, upset, or angry. The news would become much more emotionally charged. The key is not to promise and commit to something you have no control over.

The gap between the desired state and current reality

Every project seeks to deliver a desired state, an outcome that benefits someone. Bridging the gap between that desired state and the current reality is the role of the delivery team. News is the mechanism to communicate that gap.

The danger all too often is that we set expectations far in advance and lose focus on the original outcome and what we set out to achieve. There is instead a fixation on the outputs and the perfect plan. The plan and desired state becomes the objective by which the team is measured. Many agile projects are no different, with a focus on a detailed product backlog far in advance of any delivery; a long committed list of things to be accomplished. The result is the iterative delivery of the desired state to which the expectant stakeholders have become fixated; any deviation from this is an emotional disappointment. The truth is, when our best-laid plan meets reality, it has a nasty habit of doing unexpected things.

News is feedback

Kent Beck [4] said that: "Optimism is an occupational hazard of programming. Feedback is the treatment". In terms of project and product delivery, 'news' should be treated as that valuable feedback. At the heart of agile is empiricism; knowledge based on observation and feedback. That feedback is 'news', without it we lack the ability to make informed rational decisions.

The news has to be a timely check that enables us to take action. If not, we need to question - are we actually being agile? Or is it just incremental development of a fixed plan and given output?

Kent Beck also made the point that "product Roadmaps should be lists of questions, not lists of features" [5]. Questions that should be linked to achieving that desired outcome. If we have this mindset and treat 'requirements' as hypotheses that need to be validated through feedback, rather than a given that must be achieved it completely changes the way we approach news. A rapid empirical news feedback, driven by building upon hypotheses, measuring its outcome and objectively learning from it.

Focus on the outcome

A requirement that uses the following format [6] makes the 'desired state' an outcome that is awaiting feedback to either prove or disprove:

We believe that [building this feature]
for [these people/personas]
will achieve [this outcome].
We will know we are successful when we
[observe/measure this impact].

It helps put focus on the outcomes and impacts, rather than the features and outputs. The success through measuring that impact, takes the emotion out of the news; "What can be asserted without evidence, can be dismissed without evidence" [7]. This framework for delivering outcomes differently from originally envisaged, enables the benefit of learning through iterative delivery [8].

Facing up to reality

Dan Milstein [9] notes that when we do product development we can do one of two things when we get feedback:

a) face the unpleasant reality (aka "I was wrong")

b) reinterpret reality to fit your plan (aka "This is not bad news")

As humans we tend to choose 'b' [10]. We would rather be told a reassuring lie than an inconvenient truth. It can be very hard for us to face reality; but being able to change direction if you go down a dead-end path is all part of an empirical process. Not doing so is self-deception borne out of fear. We need to be comfortable embracing ambiguity "we may not know what that answer is, but we know that we have to give ourselves permission to explore." [11]

The fear of failure

Fear is especially strong when we are bringing something new into the world, where there is innovation and uncertainty. There are things in this situation we cannot control. Fear should not drive your decision-making; the important thing is to be objective. Who are you protecting by not giving the information? Is it that we fear what others would think of us? Or that 'I'll get the blame', or 'I've made a promise…now I'll look bad'.

The courage to treat news as feedback, comes from within the individual. The work of Carol Dweck [12] highlights this with the concept of the 'Fixed' versus 'Growth Mindset'. The Fixed mindset is one where we need to be perfect right away and any ignorance is seen as a failing. The Growth mindset however is about thriving on a challenge, seeking opportunities to grow and learn.

Goal: to look smart Avoid Failure Avoid challenges Failure defines your identity Feedback and criticism is personal

Goal: to learn Confront uncertainty Embrace challenges Failure provides information Feedback is about current capabilities

Don't let failure define you and try and reinterpret reality to avoid being wrong. Failure is not an identity it is just feedback and information. How we as individuals respond to it, defines how we socialise news with others and in turn how we interpret it.

The important thing to note is that agile is a team game; we succeed or fail together. An individual does not reside in a project vacuum. Mindsets change the meaning of failure, but even if the individual has that Growth mindset, their environment has to support concrete feedback and open communication.

The amygdala [13] is an area of the brain, which, amongst other things, is responsible for decision-making and emotional reaction. It frequently asks the same question about it's surroundings' 'Am I safe?' if you are and things are familiar, you remain calm and collected; if not it sends fight or flight self preservation response to the rest of your body, to get away from the situation. We are feeling creatures that think; we need to feel safe so that we can think rationally.

Create an environment where it is safe to fail

I used to work in a Telco product development company, where the CIO would ask us, his delivery teams, 'What did you fail at this week?' He would be curious if we had nothing to tell, and if our updates was as he put it 'suspiciously green'. He knew many people become paralysed by the fear of failure, afraid of what others will think. Failure is life's way of nudging you and letting you know you're off course. The job of a leader is to create a safe environment, where news can be openly shared; otherwise we need to question are we truly working in an agile environment? Agile is, after all a team game.

Tools and techniques

The giving of news should follow the same patterns as agile empirical feedback. Based on my experience I have found the following approaches support making feedback effective.

Make it timely: Bad news does not get any better with age. Fast and early feedback is the key to ensure timely decisions can be made. Minimise the learning and feedback loop, as there is nothing more frustrating to be told something that is now far too late to take any action over.

Small batches: News should be broken down into small batches and checked to ensure the message is received and understood. Doctor's use this approach and call it 'Chunk and Check' [14]:

• Chunk your message into small batches and check for understanding
• Listen actively to feedback from the recipient
• Encourage reflecting back what they have heard to ensure the message you sent is received and understood

Drop the jargon: The recipient needs to understand the news you are conveying, so drop the jargon and use language and terms that they understand. News such as - 'our velocity was impacted due to technical debt', may not be understood by all your stakeholders.

Visualize, visualize, visualize: Make it visible and accessible, because, as a colleague of mine used to say "no-one ever shouts at the board". Information on a board makes the conversation far less emotive.

Same team, same message: Take it in turns to deliver the news. There are many shoulders in a team and you should be happy to share the same message. Watch out for the situation where one person is filtering the news. You don't want to be afraid of your team talking to stakeholders around the coffee machine and 'giving the game away'.

Conclusion

News is neither good nor bad; it is just feedback that if used correctly enables us to make objective decisions. The perception of news being 'bad' is a symptom that something is broken within the system itself, where fear and emotion have the upper hand. We need to create a system where people look forward to news and facing the truth, a system where:

• expectations with the stakeholders are being set correctly as outcomes, rather than outputs;
• there is a collaborative environment, where it is safe to fail and your colleagues are allies rather than judges;
• we treat news as frequent feedback that allow us to take concrete action;

References

1. Esther Derby http://www.estherderby.com/2010/04/facing-up-to-the-truth.html
2. https://www.youtube.com/watch?v=_1JjqdRGGxE
3. http://www.slideshare.net/AgileNZ/anthony-boobier-nomad8
4. Kent Beck, eXtreme Programming explained, Addison-Wesley, 2000
5. https://twitter.com/kentbeck/status/339435106961854464
6. Jeff Gothelf with Josh Seiden, http://shop.oreilly.com/product/0636920021827.do
7. https://en.wikipedia.org/wiki/Christopher_Hitchens
8. Gojko Adzic, https://gojko.net/2013/02/13/the-february-revolution/
9. http://www.slideshare.net/LeanStartupConf/4-dan-milstein-pdf
10. Dan Milstein, Leadership, Uncertainty and Self-Deception https://www.youtube.com/watch?v=m9UkOyjcaes
11. An Introduction to Human-Centered Dessign, https://www.ideo.com/work/human-centered-design-toolkit/
12. Carol Dweck, http://www.amazon.com/Mindset-The-New-Psychology-Success/dp/0345472322/
13. Jill Bolte-Taylor https://www.youtube.com/watch?v=PzT_SBl31-s
14. Skills for communicating with patients, 2^nd edition, Jonathan Silverman, Suzanne Kurtz and Juliet Draper 2005

---

Related Methods & Tools articles

• Distributed Software Team Communications: Tripping Over Words
• The Core Protocols, an Experience Report - Part 1
• The Core Protocols, an Experience Report - Part 2

More Agile and Scrum Resources

Scrum Expert

TV Agile

---

Click here to view the complete list of archived articles

This article was originally published in the Spring 2016 issue of Methods & Tools