Team Safety

How safe is your team? Is team safety important?

My colleague raised these excellent questions in a recent interview we conducted for our Scrum-master vacancy. Then this week I was challenged by some uncomfortable, but important, questions. Unfortunately, this was before I read a thought-for-the-week article on how Jesus invited questions. All this got me thinking about why team safety is important, and how we can improve it.

http://iversonforest.com/safetyteam.html

Why is safety important?

When people feel safe in a team, they are not afraid to ask questions. These may be curious, or knowledge-seeking questions, or they may be challenging, uncomfortable questions. Either way, these kinds of questions benefit both the individuals and the team. Such questions help build and spread knowledge as well as improve artefacts, processes and behaviours.

Safety can also be viewed as the absence of fear. People tend to be afraid of making mistakes, of getting things wrong. But we often learn by our mistakes. It’s only in taking risks that we make new discoveries (think of Columbus, Neil Armstrong) and move things forward. When people feel safe in a team, they have the confidence to step out of their comfort zone and take a risk, even if it leads to failure. They know that their team-members will support them, whatever the outcome.

How can we improve team safety?

http://today.slac.stanford.edu/feature/2009/safe09-site-office.asp

It's got to be more than just issuing hard-hats and fluro-vests, or books and training courses.

People feel safe when they trust each other. People feel safe when they respect each other. The excellent book, Team Geek prefixes trust and respect with humility (HRT - spoken as “heart”), which is also a vital ingredient for a healthy team. If you work in an IT team and haven’t read Team Geek, I highly recommend it - we have several copies going round our office (I did say more than just books)!

I’ve been very challenged this year (already!) by how to live out these values, firstly for myself, and, secondly, to encourage them in the teams I lead and am part of (be they family, work or social). As a leader and manager of a software team, my goal (as put by the Agile Scout, Peter Saddington) is to love the team and inspire them. Inspiring the behaviour and values that increase team safety is quite a challenge, but a vital one to engage with.

I feel like it’s going to be a long year! Perhaps it’s time for a retrospective, starting with a Safety Check? This great technique provides a safe way for the team members to share their comfort/safety level, ahead of the team discussing potentially difficult, “touchy-feely” type subjects. Writing this blog post actually led me to the Safety Check article, so for me, this post has been very worthwhile, and I’m starting to feel just a tiny bit more confident already!

A systemic approach to coaching agile teams

Last week I was privileged enough to be part of Johanna Rothman's Coaching for Leaders Masterclass.

Four of us from NewVoiceMedia attended and we had a fantastic time. There was much to learn, take away and apply. For me particularly, I saw significant overlap between coaching principles and systemic practice, which my wife is currently studying.

Our first exercise used origami to explore coaching stances, through a very simple, but effective means.

The origami from our coaching session

We then progressed onto "speed-coaching", in triplets of coach, coachee and observer:

1. The coach coaches the coachee for seven minutes, whilst the observer, well, observes. 
2. The observer provides feedback to the coach, for three minutes. 
3. The three rotate roles and repeat.

The triplet I was part of found this massively useful, with each reaching a SMART action within the time set. The systemic links that then came out for me were circularity, curiosity, reflection and neutrality.

Circularity and curiosity

Part of the coach's role is to frame the problem or goal, provide context and explore options. In each case, we saw this being done through ever tightening circles of questions, answers and reflecting back, until the root of the problem or actual goal was established. The tightening of the circle was often achieved by the coach asking curious questions. This process to me fitted well with the principles of circularity and curiosity used by a systemic practitioner to explore a client's situation.

Reflection

It was my first experience of being observed as a coach, and not only did the observer provide great insights into improving my coaching technique, they also provided additional input to the coaching session itself. In fact, many observers in the room found it hard not to be drawn into helping with the coaching. This combination reminded me of the systemic concept of a reflecting team, who observe a therapist and client, then provide additional insights to both.

Neutrality

As the group shared their experiences of speed-coaching, the question came up of whether a coach must be an expert in the coachee's problem domain. Furthermore, what would the impact be if they were a negative expert (i.e. bad at the problem domain)? We concluded that there was a middle sweet spot, but the most important strength was in coaching itself. If the coach did have an opinion on the problem domain, then the concept of neutrality becomes very relevant. In systemic practice, the therapist endeavours to be concious of how their own background might be influencing the session. It's important that they don't inflict their own views or solutions on the client, but rather guide the client in discovering next steps or possible outcomes. This is achieved by practising neutrality.

What's next?

Johanna's fantastic workshop was a great encouragement to me and reinforced many of the good things we're doing at NVM. It's also made me keen to explore further how systemic practice could be applied to agile teams, so watch this space, I'll be posting more on this topic!

Going faster, growing faster

The team I help lead has a lot of work to do. In fact, a massive amount of work to do.

So what are we doing about it (given that we're already very agile)?

Three things:

1. Go faster, by focussing the teams on stabilising and reducing cycle-time.
2. Go faster, by focussing the teams on applying the 5-why's to problems that slow us down.
3. Grow faster, by hiring more Software Engineers, both permanent and, as of today, contract. So if you're interested, please get in touch!

The challenge is the balancing act: I'm well aware of the mythical man month, so will be focussing on ensuring that growing faster doesn't result in us actually going slower!

Watch this space for an update on how it goes!

When two worlds collide - Systemic Practice meets Agile

In interviews, I often describe Software Development as being:

People + Process + Product

Although I'm passionate about all three, I think the People component is the most important, but hardest to get right. My wife is currently studying Systemic Practice, in the context of Family Therapy. In our frequent discussions about each other's work, I'm finding significant overlap between Systemic Practice and growing great software teams.

Systemic Practice seeks constructive improvement, through bringing out, sharing and respecting the views and stories of all involved. Although this approach has a strong connection to Family Therapy, it can also be applied to any group of people. For more details, visit the Association for Family Therapy site or the Systemic Practice Index.

A Crisp team article recently made a similar connection in applying what my wife calls the miracle question, to Agile Retrospectives:

If you had a magic wand / could perform a miracle, what would your new future be like?

The key with this approach is to focus on a more positive future, and the steps to reach it, instead of spending time wallowing in ones current problems. A couple of the teams I work with tried this "positive thinking" method in recent retrospectives, and found it very, well, positive! It gave a much greater focus on the end-improvement, and the actions required to get there. Time will tell if the goals are actually reached, but I have every confidence.

Another Family Therapy technique I've often found useful is the use of curiosity to subversively cause change. If you'd like a person/team to adopt a new behaviour, then instead of asking them directly, or (even worse) telling them to, try this approach: take a neutral stance on their behaviour, but just think out loud:

I wonder what would happen if you tried <describe desired behaviour>." 

Then wait for their response, without pushing or pressurising them for agreement. You may not get a positive response, or even any response at all, but given time and the right conditions, they may mull it over and their own curiosity will make them think this through. The result is often them picturing their change in behaviour and foreseeing some benefits, which they then voice themselves and buy into more readily than if you'd forced the change on them. This is because they are now the originator and owner of the change.

I've described just a couple of Systemic Practice techniques that can be applied to Software Teams. I'm sure there are many more, so I'll blog about new ones as I find them. I'd also love to hear from other  Agile Coaches or Teams applying Systemic Practice, so we can share our experiences of what works (and what doesn't!).

Julian Treasure: 5 ways to listen better | Video on TED.com

Julian Treasure: 5 ways to listen better | Video on TED.com

Just watched this great video on listening. Julian provides five steps, of which I found the following useful:

1. Practice 3 minutes a day of silence.

2. Listen in a noisy environment - how many different channels of sound can you hear?

5. RASA - receive, appreciate, summarise, ask.

Redundancy, L=V+E and being a great leader

I pleased to read in Clusters words that I often say to others. When describing my aim at work, I often state that I strive to make myself redundant, so that:

1. The team grow to be able to do all that I do, but without me.
2. I can focus on higher-level goals.

p.159 of Clusters states that "the intention of a good leader ought to be to do themselves out of a job and to do this they need to be aware of the seasons of leadership that God takes them through"

It then goes on to list these seasons/steps (as modelled by a great leader 2000 years ago):

1. State a clear vision.
2. Adopt a "I do, you watch" approach ...
3. Followed by "I do, you help" ...
   
4. Followed by "You do, I help" ...
5. Followed by "You do, I watch".

The final point I noted on leadership was from p.178, where the useful formula was stated of:

Leadership = Vision + Empowerment

A useful exercise is to consider what a team would feel like to be in if either Vision or Empowerment is Low or High, e.g.

1. Low vision + low empowerment = dead
2. High vision + low empowerment = burnt-out
3. Low vision + high empowerment = cosy
4. High vision + high empowerment = dynamic

Accountability in life

Was given the book Clusters to read this Summer and thoroughly enjoyed it whilst on holiday. It was a great book to read following on from my trip to Karamoja and then reading Velvet Elvis.

The following points stayed with me about being accountable to each other (in a small faith group, or equally at work). Several references were made to the John Wesley Class-meeting System, which would also be worth researching.

• p83. "Relational, rather than institutional accountability is entirely different ... the relationship is indispensable."
• p81. Accountability questions:
  
1. "What do you want to see changed in your life?"
2. "What do you sense God is challenging you on?"
   

Leadership advice from Bear Grylls - Facing the Frozen Ocean

For more on the book visit Amazon. Picked up a copy from my local library as it was the only title by Bear Grylls they had. Having heard a bit about this chap I wanted to learn more and was blown away by this book.

As well as being a gripping read, it contains sound advice on building and leading a team. The problem Bear set out to solve was the crossing of the North Atlantic in an open boat (a RHIB). Points of note were:

• The team he assembled had the required mix of expertise, but instead of seeking out the very best in each field, Bear looked for people who were passionate about achieving his goal and excellent team-players.

• Bear took a pure leadership / management role in solving the problem: he left the team use their own skills to solve problems to the best of their ability. He "merely" made strategic decisions and more importantly served the team as a servant-leader whenever possible.