Resolving team conflict… before things get crazy

I have recently been discussing a situation in which a team member refused to participate in a team practice. Rather than talking about what to do when this happens, I thought it more useful to consider ideas that may help to avoid situations like this altogether.

The daily stand-up meeting is a way for a team to plan its day. Done well, it can be very useful. Done badly it will be a total drag. In this case the individual concerned, let’s call him Bob, no longer wanted to participate in the daily stand-up. The reason that Bob gave was that he “simply want[ed] to be left alone to work”.

Bob’s unhappiness was an indication that something about adopting Scrum wasn’t working for him. However, his reason doesn’t actually tell us why he was unhappy. To illustrate, here are just a few possibilities…

  • Autonomy: I didn’t have any choice about the adoption of the team’s new working practices. These consultants come in and just start changing how we work like we know nothing. It just makes me feel powerless!
  • Efficacy: The stand-up isn’t useful to me or the team, it takes too long and doesn’t convey any information that wouldn’t have been found out through the course of the work. Just talking to each other when we needed to seemed to work okay didn’t it?
  • Dignity: For the last 10 years I’ve been implementing complex mathematical models for this company, and now my day is being decided by someone who attended a 2 day course and doesn’t understand my work!
  • Results: I am more productive working on my own and under enough pressure already. This is just slowing me down. If I keep being late home there will be hell to pay!
  • Safety: I feel like I am being judged on the number of things I say I have done and I get anxious trying to remember and talk about my work in front of the team. I really dread the stand-up!

I could keep going but you get the idea. Whatever Bob’s needs actually were, the strategy he chose for meeting them was non-participation. Unfortunately this strategy led quickly to conflict with his teammates who are trying to embrace the new working practices.

Without understanding Bob’s actual need, his teammates will inevitably make their own assessment as to why he is unhappy and behaving this way. As illustrated, human needs can be complex so these assessments are likely to be incorrect. They are also likely to be in the form of negative character judgements which will only exacerbate the situation e.g. that Bob is selfish, unreasonable, not a team player, doesn’t care about the work, can’t be bothered etc.

We see what we expect and miss what we don’t. The judgemental images we create of people distort our perception of everything they say and do, and are self reinforcing. Our judgements are expressed in the way we talk to each other. People become more defensive and round and around it goes, widening the gap between people until no-one is able to hear anyone’s needs.

So how might this situation have been avoided? Being able to identify Bob’s actual need creates some opportunities:

  1. It enables the team to meet Bob’s need to be heard. The account* states that “from time to time he would play up”. Playing up or ‘acting out’ is an indication of an unexpressed unmet need.
  2. Having been heard, Bob is more likely to be able to hear the needs of his teammates and their request for him to participate.
  3. Lastly and maybe most importantly, when the actual needs are known, the team may together be able find acceptable alternative strategies for meeting everyone’s needs.

Sadly it seems Bob wasn’t able to tell anyone what his needs were. This is unsurprising as most of us have difficulty in clearly identifying our needs, let alone expressing them. It isn’t something we are taught how to do and few people actively practice or develop this important life skill. Our society generally sees expressing needs as weakness, especially for men. And, few people it seems really understand how powerful being fully present with someone’s needs (i.e. empathy) can be in creating connection and resolving conflict.

Apparently, Bob left the team and the organisation soon afterwards. I can’t help wondering if the outcome might have been different if he had been able to express why he was actually unhappy. I believe that being able to support your teammates in hearing each other’s needs can help to resolve conflict before things get too out of hand. Of course, how you go about doing this is a whole other topic!

I’ll leave you with one of the most insightful talks on empathy I have found so far…

Paul Parkin – Reimaging empathy

Reflections on being agile, before Agile was a thing

In this post I pay tribute to the achievements of an extraordinary team and reflect on what our experience, years before Scrum, XP and the Agile Manifesto says about the state of Agile today…

Like many before it, this particular project had all the potential to be a disaster. In 1993 document driven waterfall was the default approach with Big Design Up Front and all the testing at the end. And yet it was a great success, delivering a suite of innovative application software, on time with amazing quality and to industry acclaim. So why did it succeed when so many were failing? What were we doing differently?

Back then, we didn’t have a team board or daily stand-ups. We sat together and would talk often about what we were doing, how it was going and if we were struggling. When necessary we would pair up to solve problems. We were all fanatical about C/C++ and Object Oriented Analysis & Design. Ideas were white-boarded as a team and we would take turns to study and present design patterns to each other.

There was no build or test automation. We were just one small team and would manually pull each other’s changes as soon as they were committed, incorporating them into our individual development and testing. SourceSafe didn’t support branches, forcing us all to work on the mainline/trunk. Consequently, bugs and broken builds were quickly spotted, communicated and fixed as a matter of pride (or shame!). We had no testers and in addition to testing each other’s code as we went, we would all test prior to a release.

We didn’t have a backlog or use User Stories. Thankfully we were able to collaborate directly with a first class domain expert and resident user of the tools we were creating. We could discuss and understand the requirements with the minimum of fuss and documentation. Our project plans were kept simple, mostly a hand sketched outline on one side of A4. Just sufficient to set our stakeholder’s expectations, but leaving us enough room for manoeuvre. Beneath this we took a prototyping approach, exploring technical risks and enabling our domain expert to validate new functionality quickly. Because of the team’s discipline and technical skill, these ‘prototypes’ were of shippable quality.

We didn’t have time-boxed iterations or retrospectives. If people thought of better ways of doing things we would discuss them. Every Friday we would have lunch at the local pub and reflect on our week and chat about whatever. People would be gently ‘ribbed’ for their screw-ups and we would celebrate our achievements.

We were not a self-organising team. We were directed by our Team Leader, an exceptional individual with considerable technical ability. This enabled him to assemble a highly competent team and provide a strong architectural vision. Technical excellence aside, he nurtured a culture of curiosity, commitment and openness. He led by example, sharing his knowledge and giving us courage that the task was achievable. Whilst doing much of the ‘heavy lifting’ he also shielded us from the nonsense surrounding the team, in what was a very mixed up organisation.

It was challenging work but this experience showed me that software development could be successful, satisfying and at times even fun. With hindsight, the key factors contributing to our success are clearly visible and familiar:

  • Customer collaboration enabling us to “build the right thing”
  • Engineering discipline and excellence enabling us to “build the thing right”
  • Incremental delivery enabling better risk management and stakeholder engagement
  • Great leadership nurturing a team culture of openness, collaboration and learning

So what can this experience tell us about the state of modern Agile? Out of curiosity, I tried to mark up Christopher Webb’s epic “Agile Landscape v3” (shown above) with the practices that I believe contributed to our success, and that we would have identified with at the time. The only one I could find, before giving up with a headache, was “Onsite Customer”. The behaviours described in my story, as well as the four key success factors, aren’t represented on ‘the landscape’ anywhere. I’m not saying we wouldn’t have benefited from many of the practices illustrated, just that we didn’t actually need any of them to find an effective and more agile way of working.

Over the years, the mind boggling proliferation of Agile methods and practices has prompted many to try and bring people’s attention back to simple principles and values. This reflection, on a team being agile long before it even had a name, underlines the importance of keeping sight of what truly matters.

Better ways and words for giving “Feedback”

Feedback is immensely helpful for our individual growth and team performance. And yet giving feedback can be a challenge. How can we make it more likely that our feedback will be well received and have a positive outcome?

Being able to give and receive feedback creates a huge opportunity for us, and yet for many people even the term “feedback” is loaded with negativity. Lets see if we can find some better ideas and words to help us with this important skill.

Psychologist Marshall B. Rosenberg, creator of Nonviolent Communication (or NVC) proposed that when we communicate, we are really only saying one of two things: “Thank you” or “Please”. In other words we are either expressing gratitude or making a request. How could this idea help us with giving feedback?

marshall-rosenberg
Dr Rosenberg role-playing scenarios to demonstrate the application of NVC

“All people ever say is THANK YOU (a celebration of life) and PLEASE (an opportunity to make life more wonderful)” Marshall B. Rosenberg PhD.

Thinking of “positive feedback” as giving thanks and “negative feedback” as a request to behave in a different way, gives feedback new meaning and opens up a new vocabulary. A compassionate request providing an actionable alternative way of being has the potential to be far more valuable to someone than simply pointing out their limitations!

Say Thank You often

Expressing appreciation isn’t difficult. It is just a case of being clear about what it is someone is doing and why this is helpful. Here is one simple way of achieving this:

recognition
A commendation from George to Sunil thanking him for his openness

Developing a sense of gratitude is good for us, mentally and even physically. Sharing appreciations publicly not only celebrates our colleagues. It encourages others to do likewise and helps to create an open feedback culture within the team.

Saying Please?

Asking someone to behave differently takes more care, however it needn’t be that difficult either. NVC gives us a more positive way to frame our requests that is more likely to receive a compassionate response from the recipient. Consider the following example expressed in a form inspired by the NVC request:

recommendation
A recommendation from Jane, suggesting how a teammate could meet her need for equality and respect

Lets examine the request a little more closely by breaking down each part:

I am noticing…

Jane identifies her teammate’s behaviour i.e. interrupting Pauline and Sunil and gives examples of when this occurs e.g. in their planning and design meetings. These observations are expressed in a way that is without judgement or diagnosis, while the examples provide clarity.

Starting with observations of just what the person is saying and doing is important. Often we form an opinion of someone, but when we try to identify the actual behaviours that led us to this diagnosis, they prove elusive. If you find you are struggling to identify the person’s behaviours i.e. just what they are saying and doing, then maybe you need to wait, observe more closely and reevaluate the basis for your request.

The greatest benefit comes from identifying repeated behaviours that are having the most significant and detrimental impact on the individual and or the team.

This makes me feel…

In the example, Jane is feeling frustrated and anxious because her need for respect and equality for others isn’t being met by her teammate’s behaviour. In this situation, by expressing her emotions and her underlying unmet need,  she is more likely to elicit a compassionate response from the recipient. This inventory of feelings shows the full range of emotions that we may experience. Thankfully in professional situations the range is more limited making them easier to identify and express.

The ability to identify and communicate our feelings and emotions is an important life skill. Our feelings point us to the unmet need that is driving them. This knowledge gives us an opportunity to find strategies for getting our needs met that are not in conflict with other people’s strategies for meeting their own needs.

A common misinterpretation is to say something like “This makes me feel… like you do not care about the work“. Note that this isn’t expressing an emotion. It is actually making a judgement about what you think the other person is thinking! If you find yourself doing this, reflect for a moment on the emotions you are feeling, not what you are thinking. This will help you to identify the need that is not being met by the recipient’s behaviours. Just as with feelings, humans have share many needs. Here is an inventory of needs that may help you identify your own in a particular situation.

From now on, it would really help…

Finally, Jane asks her teammate if they would let Pauline and Sunil explain their ideas fully their design meetings. This would meet her need for respect and equality. The request is expressed as something the recipient can actually do, as opposed to asking someone not to do something. This is clearer for the recipient and reduces the possibility that the request will be met with a defensive reaction.

Conclusion

Equipping ourselves with the tools to be able to give feedback is the first step. The form described above is inspired by the NVC process. Another approach similar to NVC, is the Feedback Wrap from Jurgen Appelo’s Management 3.0.

Whichever you prefer, both help us to say the things that need to be said. As long as we say it from the heart, with good intention towards the recipient and the team, we won’t go far wrong.

I’ll leave you with Dr Rosenberg talking at an NVC workshop…

The examples shown above are taken from TeamSense, a fairer way for team members to exchange frequent meaningful feedback.