I’d never met the team before. It was a small company in Cornwall and the big boss man was away on holiday that week. They took me upstairs to the meeting room. We talked for about an hour and I could tell there was something on their mind.
Eventually one of them asked:
“we have this question we’ve been talking about for ages we’d like you to help with.”
This was it, the $64,000 question.
“Ask” I said.
“Well… should we be using source code control?”
To some of you this might sound funny, to others shocking, but believe me, on average I meet one team a year who don’t use source code control. On this day I had two voices, one in each ear.
The voice in my left ear said:
“You are only a coach, you are here to help them make their own decisions. Talk about their goals, what they want to achieve, find out if they think source code control could help them. Let them explore why it might be the wrong choice.”
The voice in my other ear said:
“Jesus Christ…”
On the one hand the (agile) coach is there to help the team reach their best. The coach isn’t there to tell them what to do, the people – the team – are the experts in what they do, and they are self-organising. The coach is there to help them unlock their superhero powers.
On the other hand: the coach has done this before. If they are any good they have not only worked with many teams before and read many reports in books and blogs but they wrote the reports, their teams are in the case studies. The team may well be experts in Java, JavaScript, inertial navigation, limb-replacements or whatever but the coach is the expert in agile. The coach is there to teach.
If you’ve read about coaching in other contexts you might recognise this as a question of non-directive coaching v. directive coaching. Agile, and agile coaching has never really come to terms with that differentiation.
As a coach you have next to no authority, all you can hope is that the coachees come to respect you and trust you enough to follow your suggestions. But then, maybe you shouldn’t be suggesting anything?
But if you claim to know anything – about coaching, about agile and heaven forbid software development – is it right to hold back on them when you know the answer? Isn’t it dishonest not to say what you know – or at least sincerely believe – to be true?
And if you can see what they need to do, don’t tell them but work to help them see that answer, well… thats just manipulation isn’t it?
When do you allow free will and when do you railroad?
When do you unlock self-knowledge and when do you teach?
When do you let people take decisions you can see are mistakes?
When do you know facts that will help? And when are you just full of the same biases as everyone else?
Take the documentation question: classically trained developers who have never worked in high-performing teams commonly see documentation as the answer to so many questions:
Question: How do we make sure requirements are clear?
Answer: Documentation
Q: How do we help new recruits find their way around the system?
A: Documentation
Q: How do we keep track of the code design?
A: Documentation
Q: How do we agree which bugs to fix?
A: Documentation
Q: How do we communicate with customers?
A: Documentation
Some people just don’t know what they don’t know.
I too was trained that documentation was the answer to these questions and more, I too saw the lack of documentation as a major problem when I started work somewhere new. It took time (and Railtrack PLC) for me to realise documentation wasn’t the answer, it was John Seely Brown and Julian Orr who help me to realise documentation was a problem, and it took Capers Jones to make me see the cost of documentation.
But should I impose my view of documentation on a team? – should I even be making them see the world as I do?
Ultimately the team are self-organizing. They have the right to document, or not to document, and they can decide to ditch the coach. (Being an agile coach can be a high risk profession.)
Ultimately they are allowed to self-organize long (seated) morning meetings. They are allowed to reject TDD, BDD, CD, CI and just about every other agile practice.
And you know what? They could be right.
Coaches need to be self-aware and with that self-awareness comes self-doubt. Just because a team doesn’t follow the normal rule book doesn’t mean they are wrong. They could have a better solution. They could have a solution that works better in their context.
Back in Cornwall, I paused for a few moments while the angels on my shoulders argued their case. Then I said:
“Put it like this, without source code control I wouldn’t get out of bed in the morning.”
With that question settled I moved onto the issues. What problems would it create? Why wouldn’t you use source code control? What is the worst that could happen? What difference would big boss man see?
Arse about face really but it worked. The following morning I walked into their office and found them checking everything in.
Eight years later that small company has grown more than 20 fold: would they have done that if I had answered differently? Might they have done even better? Did I make a difference or was it all them?
But I still face dilemmas like that everyday I’m “coaching”.
Like this post?
Like to receive these posts by e-mail?
Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”
I agree it’s a tough one, but personally if you are coaching, you don’t tell. If you are training or mentoring then fair enough. An Agile Coach will have to wear many hats from time to time. I try and stick in coach mode as much as I possibly can but this article seems to highlight the switch really well.
Just an observation from my view after reading your post. Might the team be asking for permission? They might of seen you as the one the big ‘boss’ man brought in and if they get you on side anything’s possible.
So maybe they felt as if they couldn’t self-organise and try new things themselves without the buy in of their management. The team seemed to adopt the change very quickly so it might of been something they all wanted to do anyway?
Thanks for the post! 🙂