In Part 1 of this series, I described a situation where the agile coaching that I provided was rejected by management. In this installment, we’ll be talking about a different kind of situation. This one is relatively recent for me, so it’s a little reminder that opportunities to learn are always with us. In this particular case, there were a few things that contributed to a less-than-successful engagement. So let’s jump in.
Scenario Two: Unmet Expectations For Agile Coaching
Recently, one of our clients asked our Solutions Manager to check into some things that they thought were happening with one of our teams. She reached out to me and we talked about what was happening. I happened to be at Agile 2017 and was able to meet with the dev manager from the client between sessions. While I couldn’t really engage with the team at that point, I did get the client’s concerns first-hand. Nothing seemed terribly difficult to resolve and it seemed like more of commitment versus delivery issue. I saw it as something we could begin to rectify with clearly-defined working agreements.
The Initial Engagement – The Flop (Texas Hold’em Style)
I had a session with the team and it was clear that there were some areas where the team had concerns. These seemed to be only partially aligned with the client’s concerns, so my thoughts evolved to a need to improve communication. The good thing – from my perspective – was that the team was otherwise doing well. There were no critical complaints from the client and we had time to address some of the core issues.
My plan was to observe the team during their ceremonies and then provide some guidance based on that. There were some pronounced issues on both sides that came to light during those initial observations. And I saw one particular thing that required some action on the client side.
The Turn (Texas Hold’em Style)
There seemed to be two competing and conflicting perceptions of the team’s performance. From the client’s side, the concerns were about how the team was doing its work – performance and delivery issues. From the team’s perspective, the concerns seemed to be focused on communication, or lack thereof. Making improvements on the communications front was the first priority. Crafting and communicating the working agreements would be the first step, especially the Definition of Done.
For the client side, there were some things that needed to be addressed. Their culture is a bit lax on meeting start times. With a distributed team, that kind of behavior challenges the working relationship. It’s always best to be consistent and diligent when working with remote teams.
The River (Texas Hold’em Style)
About four weeks into the engagement we got word that the client decided to cancel the project. This was shocking to everyone from our side. We felt that the team made improvements and I’d just met with the client the week before to provide some feedback. I was floored. And very disappointed.
As can be expected, once the project was canceled, emotions ran very high. Part of the feedback was that I, as the agile coach, had totally failed to deliver. I felt horrible about the situation but was concerned about the blame being spread. I didn’t feel like it was my responsibility to resolve the key client issues – performance and delivery – but that any core issues could be exposed and then addressed with clear working agreements and better communication. An agile coach doesn’t solve the team’s problems; they help the team understand what their own issues are and what their own solutions to those problems are.
“I Call” – The Analysis
It was clear after things started going downhill that I hadn’t set expectations properly. When starting an engagement, it’s critical to establish the rules of that engagement. What will the coach be doing? Not doing? What should the team expect to happen? Without that clarity of vision, the participants can imagine all sorts of things:
- The coach is a “white knight” sent in to fix their problems.
- A coach is going to tell them how to make everything okay.
- The coach can wave their proverbial “magic wand” and make it all good.
Of course, none of those encompass agile coaching in any way, shape, or form.
I failed to establish these expectations and set that with the team. As a result, they created all sorts of expectations that I didn’t meet.
The team, fortunately, moved off to another client when the engagement ended. But the negative feelings and “bad taste” persisted. We held two different retrospectives: one internally and one with the team and the client. The internal one was really an opportunity for us to talk about where we had misses – as a team. I did volunteer up that I didn’t coach as effectively as I should have and that I didn’t set the team’s expectations properly. It’s certainly an item that I’ll be addressing with my next engagement right off the bat.
This situation was easily avoidable if I’d just followed some standard practices. I didn’t think the team was in danger so I was a little lax on some of the engagement elements. But I should have realized there was more urgency – and I take responsibility for that. And I totally failed to set the expectations for the team. They should have known what to expect and I dropped that ball.
Agile coaching isn’t something you can do on autopilot. It requires full attention. And it absolutely needs strong communication. When done properly, agile coaching can really help a team find their best path forward. And, when it’s not done well, teams can languish and fail. Only through due diligence can an agile coach help their teams achieve success.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)