Two hours per team

Someone asked me recently for advice about consulting into multiple teams, in particular about how to make the most effective use of a number of short sessions. He will be spending two hours with each team in each visit. This will be an ongoing relationship, with a series of visits made up of these two hour coaching sessions.

Systems of systems ¶

I think of the client organisation as a system of systems. Each team is a system of work, with the team members participating in activities that deliver solutions to the business. The department is then a system made up of these team systems, whose goal is to deliver strategic business impact, usually in the form of one or more programmes of work.

Without understanding the broader goal of the department or programme I’m not really qualified to have an opinion at a team level. There are a number of obvious basic hygiene areas I can advise on, but I’ve found that the point at which even this breaks can surprisingly early.

Understand the landscape ¶

For instance every team should have their code in a source control system, be writing tests and have CI, there is simply no excuse not to. But what if the technology stack you are working is hostile to these? One team I coach uses a legacy business flow modelling tool, which you “programme” by dragging icons around in a GUI. Testing is mostly manual and it doesn’t have a concept of versioning as such. I expect it is possible to freeze or snapshot its state, but not in any meaningful way, and anyway the opportunity cost means it isn’t worth it. There are other more useful things they can be doing, and this application is reasonably stable. They are gradually moving responsibilities away from it until eventually they will be able to retire it, so it makes more sense in the meantime to just live with the risk of not having that backstop of versioning and CI. So even something this fundamental still isn’t a hard-and-fast rule.

Then there are the tactical versus strategic trade-offs to be aware of. Where are we going in terms of technology landscape, organisational structure or business responsibility? Are we migrating to a new platform, as one of my clients is doing, and if so how do we decide which work happens in the current world and which on the new platform? Do we want the programme team to grow or shrink, or to remain stable? Do we expect individual teams to remain stable or do we want to restructure the teams as different kinds of work come down the pipeline? How do we expect the profile of work to change over time? How much of that work is our choice as a business, and how much is externally-imposed by legal or regulatory frameworks? How much of the scheduling is in our own hands?

One of my objectives as a consultant is to get a handle on these kinds of question as soon as I can, so I can help teams align themselves with the broader business and department goals. Sometimes the answer is “We don’t know” or “We haven’t really thought about that”, which is a useful data point in itself. Maybe I can facilitate some of those discussions and help the organisation gain some clarity.

Be flexible ¶

From here there are a number of ways to engage with the individual teams. Sometimes I’ll send through a mini-questionnaire ahead of the visit, asking them to think about things like:

• What do you want to get out of this session?
• What do you see as your biggest impediment at the moment? What is frustrating you?
• What would you like to get better at?

As you can see, these questions aren’t dissimilar to the kind of preparation you might do for a retrospective, and often these sessions have a similar feel. Sometimes though they are more delivery-focused, and even involve pair-programming or whiteboard activities.

I don’t necessarily want the team to write anything down, just to spend some time thinking about how best to use the session. This helps them come into it more focused and present. Some sessions take the form of specific technical or process questions—design and architecture reviews or topics like test and build automation, planning and estimation seem to come up a lot. Some involve discussions around topics of interest or concern, or just spending some time with the team and feeding back what I see.

Have a goal ¶

I find it helps to start with some sort of goal or objective for the session, even if we end up going in a different direction. Don’t be afraid if this happens, sometimes there is a more important underlying issue to explore and the original goal just acted as a catalyst to surface it. Something that presents as frustration about how long UAT takes could really be about improving our understanding of the end users who are supposed to be testing the application. They may be too busy to take time to test the software, or maybe there is a disconnect between what we are delivering and what they wanted. If we are getting it right they should be eager to help shepherd new features into production, and part of that is for them to think about it as their software rather than something that is happening to them.

One client had the idea of running a department-wide brainstorming session to identify the top strategic areas they wanted to improve, whether in specific teams or applications or across the whole department, and turned this into a prioritised list. Then we started addressing these topics in the sessions.

Be a bumblebee ¶

As you move from team to team you will notice themes or patterns emerging, which might hint at a deeper underlying organisational or technological issues. You may also notice something one team is doing that other teams could benefit from. You are in a great position to help them share this knowledge, and a lot of cross-team coaching is about connecting people up, and helping them figure out why they weren’t connected up in the first place.

Coaching across an organisation allows you to cross-pollinate along multiple dimensions. One team may have figured out a way to automate testing in a legacy technology. Another might have a really nice way of modelling the business. One programme may have an innovative model for identifying skills gaps or aspirational training needs. Acting as a vector for this kind of knowledge sharing can be a real enabler for an organisation. Of course the long game is that they do this for themselves, but in the meantime you are giving them something they can model.

Make a difference ¶

My goal is to see some kind of behavioural change as a result of these coaching sessions. Sometimes I won’t necessarily give the team anything new in terms of techniques or training, but just reaffirm what they are doing. This can give them the confidence and encouragement to keep at it or even try other things, which is especially important when they are going through the kind of changes involved in an agile or lean adoption. Many of their existing tools and mental models will break and that can leave someone feeling vulnerable and uncertain. They don’t know what “good” looks like in this new world, so having external validation can be a big help.

One area I work on with teams is how to measure themselves. This is a kind of bootstrapping coaching so that over time they start coming up with experiments of their own, which is always an exciting shift.

I keep notes of these discussions so I can review them over time. I’m always surprised at how much detail gets lost if I don’t do this, and how much progress I can otherwise miss. They grow up so fast, these teams!

Three stages of coaching ¶

I learned a coaching model from former ThoughtWorks colleague Richard Watt over ten years ago which has served me well. He talks about three stages of coaching.

Stage 1 is Coaching from the front. It’s a “Follow me, don’t worry, it’s going to be alright” kind of coaching. The team or individual doesn’t yet have a frame of reference for where we are going, and the most effective way they will become self-sufficient is to experience it for themselves.

Stage 2 is Coaching from the side. You are walking beside them with a firm hand in their back. They are finding their own direction but you are setting the pace. During this stage it is common for a team to become complacent as things start to take shape and they are getting the hang of a new way of working, or worse for the team to get frustrated with a lack of progress and try to revert to their old habits. Your role is to help them maintain their momentum and not to let up. This is the trough of the Satir change model, where they have most to gain tactically by reverting to type, and the most to lose strategically.

Stage 3 is Coaching from behind. By this point the team is largely self-sufficient and even self-coaching. Your role now is to provide the occasional course-correction, and to help the team hold itself to account. They should be starting to reflect on their own process by this point, and even reaching out to other teams.

Make yourself redundant ¶

Finally, remember effective coaching has a diminishing return. You should be trying to coach yourself out of a job as the teams become self-sufficient, in terms of both their new ways of working and techniques for introspection and improvement, so they can coach themselves. There is a lovely moment when you realise you are no longer injecting new content but simply helping the team validate its own decisions, as you transition into coaching-from-behind.

For extra credit you can be looking out for the people who themselves want to become coaches, so you can coach them in coaching. When they start coming back with observations and insights you missed it can lead to some great conversations and discussions.