So you explained to your team how to do X – where X is a certain agile practice you believe it will be very helpful for them – and they learned and implemented it quite well and you were so proud of the way you convinced them to change their habits until… they don’t! And the more you try to bring them to the “right way” the more they go back. They even tell you they really want to implement the wonderful technique you showed them, but actually they don’t.
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:
- Spare the learning curve
- Hide much better their problems, so they won’t be blamed
- Keep giving an estimate that matches what the manager wants to hear, i.e. without the additional effort for testing in it
- Fear of being ostracised in an organisation that is still against agile
- Fear of showing their weaknesses, for example by breaking the build with the tests they added
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!
4 thoughts on “A matter of secondary gains”
Just a few thoughts I experienced in my years of agile working starting with a little mentoring and coaching in a team – but this as a normal team member in no specific role, i.e. something like a hobby ;-).
I believe in the technique named “convince by infection”. I assume you always find different people. Let’s classify them: “early adopters”, “doubters” and “waverers”. And treat them with respect (they are all professionals but have made different experiences in the past)! The scrum master (SM) should be an early adopter (and there it helps when the SM has background in software development). And let’s keep the nice example: TDD.
First convince an early adopter for to apply new techniques such as TDD. He (or she) is more eager to learn, intrinsic motivated, curious to learn new things. The only way is to let him experience the benefits clearly, i.e. exact requirements for a class, better design, improved testability. Let’s rename these people “agile mentors” when you have reached your goal.
The agile mentors in the team prepare the ground for to convince the next group: the waverers. The waverers think new techniques are nice, sometimes they may try, but do fall back to conventional techniques very easily, when the wind blows from the front in their current project. The agile mentors pair with the waveres and this needs it time. Especially when the team is confronted with difficulties. There they need the help by the external agile coach.
The break even is reached when the waverers are convinced and intrinsic motivated too (master a cool technique, feeling more professional, producing better quality in software) and when the change in the team is a sustainable one – especially when the agile coach has done his (or her) work and has already left the area. While the waverers are convinced you possess already the critical mass to get the doubters to the other side.
What is not clear to me is the role of other facilitators, e.g. line managers. Can they really help? Trying to motivate from outside does lead to extrinsic motivation only, doesn’t it?
And do you agree we all need this special role “agile mentor”, or do you think it is not helpful?
BTW, which book about agile coaching do you recommend to read? Agile Coaching by Rachel Davies and Liz Sedley? Wish you a nice time and thanks for your post!
Thanks for your comments Joachim,
Unfortunately things are not that simple as it seems: what you propose would definitely be true and the right thing to do if… the world would be based on linear and casual thinking. Unfortunately it’s not, it’s a complex adaptive system with loops, non linearities and oddities at all levels.
An example: have you even experienced somebody who was convinced that X is good and, sometimes later, for some unclear reasons, was actually opposing X? What happened there? Maybe it is possible to know, maybe it’s not. We’re incredibly irrational though we pretend to be rational and it could be there is no reason at all for such a change. This is one of the typical situation where there is a secondary gain at work: something not declared that is working against the change, maybe totally unconsciously. You might even reach a “critical mass” and then something changes, maybe in one person, maybe in a part of the group, maybe at the organisational level, and everything goes back to square one.
I was once very close to be able to start the agile transition of an organisation: everything was well prepared, there was a critical mass in favour and we were organising a workshop with the management to get things started. For some silly logistical reasons the workshop got postponed by a few weeks and, in the meantime, something changed and nothing happened. The critical mass obviously disappeared, everything went back to “normal”. S*** happens… 🙂
The whole idea behind the post is that, just trying to “convince” somebody will not necessarily work and it is important to look at the secondary gains the people experience in order to enable the change.
One important aspect to consider: when I hear people talking about agile coaching, they seem to imply a very much active role of the coach. The “doer” changing things here, there and all over. In fact this is, IMO, the WRONG attitude: I’m NOT *changing* companies, but supporting them in the process of change, clarifying the way they do it, providing offers and invitations to try, and reflect, asking those questions that normally cannot really be asked form within the organisation. This type of work is about enabling people and removing roadblocks and not changing heads! Actually the more we try to actively change the more “resistance” we get back – people don’t like to be changed!
You ask about the role of line managers. In an organisation composed of self-organising teams you don’t need managers controlling people, but rather leaders inspiring people and providing visions. Stop ticking off action items and start understanding where the business goes and inspire the teams to move in that direction. There is, however, an interesting attitude change in the way companies are led instead of managed and not all the managers can easily cope with this change: this is where some targeted one-to-one coaching can do miracles!
About the agile mentor: it is true that many organisation have been able to implement agility by themselves. My observation is that this requires a high level of maturity and self-awareness of the organisation, that is usually dampened down as soon as the the company becomes bigger and values control and processes. It’s like the employees’ brains learn to switch off the self-reflection part of their brains for what relates the way they work in the organisation (there are, BTW, very well known group dynamics reasons why this happens!). They usually complain with each other around the coffee machine or take their frustrations back home and ruin their families, but they don’t *really* try and change the situation they’re in. Some people try and get burned (I almost did, when I was an employee…), some just resign and go to work for better companies. Some just stay and suffer.
An agile mentor, especially when coming from outside the organisation, has the “superpower” of saying all the things that are often impossible to say and provoke the self reflection processes that, over time, cause the change.
About agile coaching books:
1. IMO agile coaching is still in its infancy and based more on metaphors and myths rather than being a real discipline. There are years of experience in the field of organisational change that we don’t currently try to import in the way we work. As such, rather than the pre-packaged books about agile coaching I suggest to look in the body of knowledges related to training, coaching, organisational consulting, … and import what works there.
2. We (=agile community) are incredible readers. We love books and devour them, but there is nothing like the experience of a training with a good trainer. So if you’re even just a bit serious in learning about coaching, I’d rely first on some training about communication, group dynamics, coaching, …: a few days might work way better than tons of books!
btw, for me personally it is nice to have the chance to discuss such interesting topics with an expert in agile coaching (of course, better would be face-2-face). And maybe neither my idea of critical mass nor convincing by infection does help here.
Yes, of course, we have here no linear but an adaptive and complex system. Yes, people don’t like to be changed. Yes self-organizing teams do not go with conventional line managers and we need leaders inspiring people. Yes, an coach and/or mentor from the outside has more power than an internal one. I do agree to every statement because of my own experience. But there is more and I have questions about this!
I keep the example TDD. We have been coached in it. Several external coaches have spent time to teach us this technique. I think the people have listen to the benefits. Some changed their procedure. Some do it sometimes sometimes not. Some don’t do it ever. Why? Maybe there are secondary gains. Something like “spare the learning curve”. This one I can imagine. But what can help on this situation?
Okay, there is an agile coach/mentor giving the support in the right direction by pairing, coding doyo’s. He/she does convince – not by brain washing – but by an attitude of try-and-reflect, make the people feel the benefits, giving this change a lot of time to get happen, by an offer to practise an alternative approach in developing software, by respecting the people’s different speed in changing their practises. My question here is: what is the right approach to do this in an effective and a sustainable way? And what to change while you know in fact the people do not want to be in this “learning curve” even with the coach/mentor?
The managers are already featuring this change towards TDD. They have ordered externals. They are giving the time to the team to practise and learn new techniques. They have communicated the right vision. The interesting question is: what to do when this is not sufficient? Believe in self-organization? Does this fall from the skies? What they have to do to improve the self-organization?
Maybe the simple answer is: they have to hire you. This would be fine with me 😉
Sorry for the late answer – have too many things in parallel at the moment…
> Some don’t do it ever. Why?
The plain answer is: I don’t know. The good thing is: I don’t care!
Let me explain a bit better: the answer to the question “why” it’s probably pretty much impossible to find (see http://blog.connexxo.com/2009/12/the-whys-of-why-not-why.html for more). Yes, there are several ways to try and get the answer (five whys, cause-effect analysis …), but I’d expect the real answer to be pretty much emotional rather than rational, i.e. very likely the person being asked for the why will not really give the real answer – also because it might be even totally unconscious. To translate it in the language of this post: there is a secondary gain in action that is based on a “why”, though it might never really come out clearly.
I’m not just talking about people “resisting” the coaching (oh, let me glide around this topic here: resistance is a very interesting concept in coaching and has usually more to do with the coach than with the client…), but also co-operating client often have difficulties in articulating the real why of what they are doing. The whole freudian psychoanalysis is – as the name says – focused on analysing the client. The problem is that very often by asking questions we are also suggesting answers, so if we search for a why long enough we are even “polluting” the answer (a very well known effect is the False Memory Syndrome!).
As I said: I don’t care. My usual approach in this case is to search for solutions instead: what would the person need to do something else? And then start experimenting… You can find some more information about this is my presentation about solution focused (http://blog.connexxo.com/2010/04/solution-focused-presentation-again-mini-xp-days-2010.html) and in the workshop I am currently presenting at some conferences Change, Change, Change! (http://blog.connexxo.com/2011/12/change-change-change-workshop-at-xp-days-benelux.html).
> My question here is: what is the right approach to do this in an effective and a sustainable way?
My answer here is: stop trying to change people and start creating the conditions that enable people to change. Each of us should be free to choose what we want to do and of course we are responsible of our choices. But often I see some people having nothing to do with the team coming from outside and “forcing” people to change. Take as an example the manager who comes in and says “we *must* become agile until the end of the year” or the coach who comes in and says “X is the best thing in the world and you must do it because it’s great!” (replace X with your favourite agile buzzword…).
I don’t force people to change. I cannot. I don’t want to. The way I work is by making things transparent, reflecting about them with the team and having them making sense of what happens, offering ideas and suggestions that might be liked and used, but maybe also not.
Once people change through this approach, the change is stable (unless there are external forces that change the panorama), but it takes a while: patience is the key virtue here!
> And what to change while you know in fact the people do not want to be in this “learning curve” even with the coach/mentor?
That’s the art. Again the 6 conditions for change is a good base to start, though there are several others available.
> What to do when this is not sufficient?
Other invitations, work on the conditions for change, experiment. If there were a fixed recipe we would have found it already (and the daily rates for agile coaches would be lower… 🙂 )
> Believe in self-organization?
Every group self-organises. There are no other options. The question is what are the results of such a self-organisation. Self-organisation is a characteristic of every complex-adaptive system, but the results depend on what are the forces operating on the group.
> Does this fall from the skies? What they have to do to improve the self-organization?
Think obstacles: what is preventing self-organisation to work for a more productive team? What are the secondary gains that push people to self-organise in a command-and-control system? What would people need to choose the most efficient way to work? To be part of and promote a highly productive team?
> Maybe the simple answer is: they have to hire you.
The real answer is: for writing good software you need the right programmers. To build a good team you need the to go through the right process to build the team: who has the skills to do that? There are some talented people who can do that without any study – I’ve met a few of them and they can be amasingly effective – but in most company this is a totally neglected skill when putting together teams. A coach trained in making communication work might help. But might also fail, exactly like great programmer sometimes build also crappy code!