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!

A tale of two retrospectives

One of my responsibilities as a Scrum Master is to facilitate our team's fortnightly retrospective. I like to experiment quite a lot with most things, and retrospectives are no exception. Our last two sessions used different formats that I thought may be of interest to others.

As a caveat, many of my ideas (and this very blog post) was inspired by a recent article from the lovely people at +TargetProcess , on different retrospective styles (of course!).

Goal-orientated

This is a twist on a traditional format that focusses three reflective questions around some shared goals:

Create fast, secure, scalable features that our clients will rave about.

Continuously improve our ability to get things done and get things right.

Share your passion for your work internally and externally.

Be (mostly) awesome.

These goals apply to every Software Engineer at New Voice Media and so we should also embody them as a team (we're hiring, by the way, Developers, a Product Owner, Op's Engineers and more - contact me if you're interested).

I printed the goals out, with emphasis on the key words, and stuck this up on the whiteboard. With this as our visual focus, we then considered three questions:

In order to achieve these goals, what should our team:

Do more of?

Do less of?

Keep doing?

The team spent 5 minutes writing ideas on stickies which were colour coded by section. Once everyone had posted their stickies on the board, we discussed each one and then starred the ones requiring significant action.

This format was great as it provided a concrete, visual focus for guiding our reflections, as the picture below shows.

Retrospective output

Looking forward - preparing for change

If your team is about to experience significant change, then a retrospective is a useful setting for sowing seeds and facilitating preparation.

Our Development Team will increase in size by 25% over the course of January (did you miss that we're hiring), and we're likely to add another 25% over the remainder of Q1, some of whom will be in a separate location. For our last retrospective of the year, I therefore made this our focus. We discussed the short and longer term changes that the team would be experiencing (cultural, as well as numerical) and shared thoughts on how this would impact us.

Applying the retrospective label to this approach may be a stretch, but I felt that it was necessary to improve the team's readiness for change. I'll let you know how well we actually responded to the growth in a few months!

Retrospective retrospective

In summary, it's important to experiment with the retrospective format and hopefully the two I've shared will help you do that. To improve our improving (which is what retrospectives are all about), it's important that we regularly apply the adjust part of the plan-do-check-adjust cycle to the retrospective itself.

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!).