Maybe you weren't clear enough. Well, no, they understood and they were even implementing the technique very well.
Maybe something changed in the organisation. Actually not even that: the management constellation is as it was before.
Maybe you forgot to consider their secondary gain[s]!
The Secondary Gain is something your team gains by not changing (or loses when changing). It is often a very important barrier against change in individual coaching and also in team coaching. It happens to be very important because... we tend not to see it or blatantly ignore it!
The secondary gain is an extrinsic motivator and, as such, it is connected to one or more causes that can be clearly labeled, though they are not necessarily easy to identify. Once you have some working hypothesis about what these secondary gains could be, it is also important to validate them on the field: sometimes the consultant's opinion is flawed by his/her own biases!
Let's take as an example the team from the beginning that claims to implement e.g. TDD, but in fact does not want to do so. Here are some possible secondary gains:
There can be a lot of possible secondary gains and, of course, each individual in the team might have his/her own ones, though some of them will be common for the whole team and are usually systemic diseases of the organisation. The important thing to consider is that without removing/resolving these secondary gains, no change is possible regardless of how shiny the primary gain can be!
The assumption this article is based on is that we're not sure whether a person/a team/an organisation can change at all: what are the conditions that allow a change to happen? Can we actually support our clients in implementing these conditions, thus effectively lowering the barrier to change?
This very topic was the subject of my recent presentation at Agile Prague called "Change, Change, Change!". It was inspired by all the many books suggesting THE way to change the way individuals, teams or organisations work without even discussing what are the pre-requisites for such a work.
Here are the slides:
The presentation takes heavy inspiration from the work of Clare Graves (a collection of his articles can be found here), a psychologist who spent a big part of his life doing research on change and human evolution.
His thesis is that change is a reaction to changing Life Conditions, an evolution needed to adapt to the environment we're living in. As the environment changes - for example for an IT company a fiercer and more global competition - we need to search for new solutions we did not have before as the problems to solve are different.
Graves found that, in order to enable change, six conditions have to be there:
If one or more of these conditions are not fulfilled, change is unlikely to happen, i.e. we'll get resistance from the client.
These six conditions are a great analysis tool when starting a coaching activity: does the client have these basic pre-requisite in place or do we have to do something in some of these cases?
Typically in the software development world there is a lack of clear solutions for the current problems. An example: recently I dealt with a client who is searching for a PMI like solution for project management, one that gives them clear control over their development activities, because at the moment they have nothing in place that helps them understand how their projects are going. As per condition 2 - Solutions - until they have implemented a solution they reckon should have solved their problem and they realise that, in fact, it doesn't, they will not be open to discuss anything about agile project management.
Another typical scenario is when a team new to agile starts to "get it" and delivers: if the organisation will not guarantee condition 6 - Stabilisation and Consolidation - for example by not defending the team's specialty in the organisation, there are high chances the team will revert back to the old way of doing things.
So what is the status of these six conditions in the organisation you're working with or in?
One final topic: in the beginning I put "coaching them to agile" in quotes. If you agree on my view that coaching is supporting your clients in exploring new options, then it is not possible to coach somebody to something, but rather let somebody reflect on a certain topic and explore other behaviours that were previously impossible. If you "coach somebody to something" this is mentoring or even using force!
In the workshop I delivered at the Turku Agile Day together with Mike Sutton, we stressed the importance of the Observer role in coaching, giving also some instructions on what this role is about. But while reflecting on the workshop, we got the impression we should have spent some more time describing it, so here we go...
1. What is an Observer?
Easy, the Observer... observes. But... what exactly? The Process!
With "the process" I mean how a certain communication/interaction/procedure goes.
Let's clarify in a specific context: in one-to-one coaching we have the Coach, the Client and - you guessed already - the Observer.
2. What does the Observer do?
A few things...:
Example: "You did great" does not help: too imprecise, too generic, not circumstantiated.
Example: "When asking for his emotions in subject X, you framed the question implying the Client should have felt bad for what he did: this worked well as it helped the client open up but it also caused the discussion to fall back to talk about the problem instead of searching for solutions. It was immediately visible how the Client became uncomfortable and showed signs of nervousness by moving on his chair much more". Now this is a fairly defined feedback we could work on! With this feedback we can learn. If we have recorded the session we could go back to that place and check what happened, relating it to what we did and look for alternatives.
A good Observer, the one giving feedback in this format, is your best friend in practicing coaching!
3. In real life: the Coach as an Observer
One of the most important characteristic of a coach is the capability of providing qualified feedback to the team, i.e. the coach himself acts also as an observer of the team's behaviour, a mirror of how they act. All we said before for the Observer's role in a one-to-one coaching belongs to the observation the Coach can do when working with a team. Some of the aspects are related to the way the team works:
What? You don't have that luxury? Cool down, you're not alone. In this case it's important for the Coach to be able to "step out of himself" and take the Observer’s role from an independent Meta-Position. With a bit of experience this is possible and helpful. Though not as effective as having an external observer, it might be the best option available. in this case, when you are de-briefing a session, either with yourself or with other colleagues, remember to specify from what perspective comes what you're talking about: the You-Coach or the You-Observer.
4. How can this possibly be important?
Duh... How can you possibly decide for the right interventions if you don't understand what happens? IMO there is no need to go for a complete and complicated systemic analysis - that would anyway be incomplete and useless as we're working with complex-adaptive systems, but a basic understanding of the dynamic involved in the interactions, a clear understanding of what the goal should be and a fair dose of experience will make it easier to decide for a handful of interventions that might be useful in a situation.
5. How do I become an Observer? What skills do I need?
The basic skill needed by an observer is the capability of calibrating himself on the reaction of the others: how do you understand exactly when somebody is happy or sad? Knows what he is saying or makes things up? Talks about experience or about theory? Try practice a bit and you'll realise each of us behaves differently in these situations and that it is possible to learn how to "read" these situations!
A second very important skill is the one to remain "out" of the process. As Observers we're "just" observing, we have no active role in the session, we have no right to intervene. A typical mistake of the practicing Observer is the entering in the discussion to "support" the Coach - think "pair coaching" somebody ("ping-pong coaching"?): believe me, this goes badly!
It's also very important to remember that an Observer is anyway a part of the system and will influence it, so try to stay out "of the scene" as much as possible, though you will still impact the coaching no matter how hard you try not to.
A final remark: being an Observer requires a lot of discipline, but it's an incredibly powerful tool to improve your listening and observing skills and it's a great investment I recommend to every coach!
So, in summary, the role of the observer is a crucially important part in coaching, the part that will give you a fresh view on what you're doing. Get an external one if you can, if not, practice your observing skills as much as you can!
The interesting point is that there seems to be no correlation between the quality of the coach and the fact that he/she uses games, so... what's going on here? Here's my take:
1. There's game and game (and reality)
Just because there are plenty of games available, it doesn't mean they are all equally suited for agile teams. And just because the coach likes them, it doesn't mean they are suited either. I would classify agile games based on the mix of characteristics they have in four dimensions:
2. Choosing a game is more than just gut feeling
Once we are aware that games have a various mix of characteristics, we have to face the problem of how to choose them. "Because it worked with another team" is no answer for me: it might still work with a different team, there are good reasons for it, and in most of the cases it will. But it might also not work!
Here is my way of deciding what to play:
3. Running a game is more than just playing
I mentioned before the initial framing and the de-briefing of the game. Especially for games having a procedural or a social learning it is important to frame them properly:
4. And then there are other options as well
But... wait! I said I am not playing as many games with the teams I coach compared to my colleagues. So what am I doing instead?
Well, a lot of things, in fact. Actually I typically check whether it is possible to achieve the same learning in a different way before playing a game. Playing a game involves changing context, playing the game and coming back to reality to integrate the learning. If the system allows it, I rather prefer to skip the two context switches and act directly in the reality of the team.
I got a similar question proposed some time ago by one of my customers. Instead of giving my answer, I started asking questions instead - well, I'm a coach, aren't I?
First I asked what characteristics are important for a ScrumMaster in that particular organisation:
Once he had prepared this list, I asked the manager I was talking to to rate the two candidates on each of these skills using a scale from 1 to 10: one of the two was clearly the winner!
Bonus
What if both candidates were very similar or, though different, a simple averaging of the ranking on each skill gave a similar result?
Well, in that case I would have ranked each skill in order of importance and understood who of the candidates was stronger on the most needed skills, though I would have also considered the potential of each candidate to improve on the top priority skills.
On the other hand I am actually pretty much in favour of more systemic tools like the Cause-Effect Diagrams and the Thinking Process, despite the risk of using an oversimplified and/or incomplete version of these methods.
While preparing for my "Agile as a Systemic Change" presentation I realised one more detail that confirmed my skepticism in the 5 Whys: the lack of circularity!
One of the peculiar characteristics of a system is the presence of loops, i.e. cause-effect connections that end up creating a closed loop, reinforcing a certain situation, like this:
These loops are exactly the features we search for in a system as they are the endemic and self-enforcing reasons of the behaviour of a system.
On the top of asking why - which is, in my view, a dangerous way to analyse a system - the 5 whys is a way to "go back" in the cause-effect chain for a while:
[The picture is built from right to left: we find A, we search for the cause finding B, we search for the cause of B we find C, ...]
If we're lucky we might even find a loop:
but if it happens it happens by pure chance.
What I recently used with some success is, instead, a technique I developed and called Three Hows, where, for each effect, I ask something like "How does effect A happen?", and asking this questions at least three times but usually even more ("And how else does effect A happen?", "And how else?"):
And then back for each cause of A:
Thus maximising the chances of finding a loop:
In this process, I refrain from asking "why" as a question and use "how", though also "what" is a good alternative. Anyway, I try as much as possible to use the client's language and the client's reality, avoiding to add my content in the discussion, even in the form of a question.
As I said, I had some success with it and I will test it more on the field. At the same time, I am looking for your feedback: does it work for you? Either way, I'd love to hear your experiences with this.
