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!
Interesting enough, none of these interaction patterns seems to really make the difference in the way the teams perform. What I mean is that I've seen teams perform in a good and bad way in all configurations, so apparently Scrum is pretty robust w.r.t. the actual duties taken on by the Product Owner.
But there is a more interesting behavioural pattern I noticed: the style of interaction with the team. When the Product Owner shows respect for the team and care for the product he/she is developing, then I notice an improvement in the way the team works and in what the team delivers.
Here's the way I made sense of this:
Respecting the team seems to be a major motivator for the people in the team: they are appreciated by the Product Owner, they are working to support somebody who understands their efforts and the complexity of their job. A Product Owner respecting the team is also respected by the team. While respect is IMO a fundamental characteristic of the way we interact as human beings in general, it seems that while teams are resilient to a certain dose of disrespectful behaviour, the interaction relationship Team-Product Owner is much less resilient.
Caring for the product seems to be communicating to the team the importance of the work they are doing and inspiring a sense of urgency and of importance of the decisions taken. For the team it becomes clear that they are not developing something for a customer far away from their reality: they are putting the effort to support somebody who cares in what they produce. What they do is important because it is appreciated!
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.
