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.
This was it, the $64,000 question.
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.
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.
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?
Question: How do we make sure requirements are clear?
Q: How do we help new recruits find their way around the system?
Q: How do we keep track of the code design?
Q: How do we agree which bugs to fix?
Q: How do we communicate with customers?
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 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.
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".
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?