Questioning Servant Leadership

...First up - I really don't agree with Mary (perhaps a first) - I do think that servant leadership is good reminder to managers that they're no longer in a totally command and control world. That they need to focus on the needs of the organisation and team (in that order).

Second - Mary's point about coached teams reverting to their old habits when the coach moves really struck me. I'm a full time coach and I need to keep this mind on a regular basis.

This article (and accompanying thread) really struck a chord with me (so much so I have just signed up for an account so I could reply!) mainly because I am in the situation of being a (relatively inexperienced) manager as well as a team lead.



I am glad the whole 'sword' concept has been brought out into open discussion - I often find it is paramount to blasphemy to talk about these things in agile circles.



The vast majority of literature speaks of self-managed teams (one article I saw on this site even spoke of teams that are responsible for firing decisions) but in my experience teams do not self-manage to the full extent. Team-mates do not give critical feedback to each other (although they will complain about it) so it is left to the Team Lead to correct the behaviour - and make ultimate decisions about hiring / firing.



During my tenure I have often found myself in a dilemma of whether to step in or let the situation self-correct. And often when the situation does not self-correct I have to step in anyway - at which point much time has passed and it is worse than if I would have done it anyway.



I believe fully self-managed teams to be an ideal that I have never seen in practice (despite numerous books and whitepapers).



I would also like to point out that I have been a Team Lead without management responsibility (separate manager) and although my job was a lot easier I do not believe it benefited the team or the business - to the extent the reporting was eventually changed.

Jay - thanks for taking the time to sign up and reply. As you say its a very interesting topic and note sure of your circumstances or practices so please take my remarks as very general.


Before using the sword I believe a good Scrum Master/Manager should exhaust other approaches - over several iterations. My preference is to ensure that a particular problem is raised (perhaps indirectly) during a retrospective and then let the team work on solving the problem. Often they come up with better solutions than I had in mind in the first place.


For example - lets say that I knew that one individual had not be writing unit tests for their code in an iteration then I would wait for others to raise it. If no one did then I might say: "I've noticed that there were a few check-ins in the last iteration that didn't have any unit tests". This way its not directed at any one person. To go further I might use the code coverage tools that I use to demonstrate in completely objective way that test coverage had gone down in one or more packages. Now its the tool providing the information not me. In addition I would be patient and expect change to take several iterations.


Finally if nothing changed I consider why the person is resisting see: www.infoq.com/news/2008/08/overcoming_resistance and use the resistance game mentioned there in for me to understand.


Only if everything else failed would I use my sword. You have to be very careful about using that sword. To quote Scott again:

The problem with wielding a sword is that it's hard to be seen as
other than a sword wielder once the sword has been wielded<\blockquote>


As I said at the start Jay - you may already doing just this.


Cheers


Mark</\blockquote>

I would expect something like lack of unit testing to self correct - you are right. However I would not stand by if it took more than a couple of iterations. That situation can usually be resolved through non-confrontive coaching.



It is with behavioural and performance issues that I feel self-management lacks.... An example - an employee is constantly distracted by her laptop / phone whilst pairing, reducing velocity and in turn distracting other team members. It would be fantastic if other team members brought this up in retrospective. In most cases they won't. If the team lead brings it up as 'I notice we have become distracted....' (obviously no names mentioned) I would argue that act in itself is at least an un-sheathing of the sword!



Behavioural situations need to be dealt with early - if not then it is almost deemed as normal team behaviour.
My suggestion? A simple quiet work in private with an explanation of behaviour and example, why it impacts the team/individual/business, a suggestion of corrective behaviour and, in some cases, a consequence if behaviour continues.

I think what we may be seeing here is similar to the role of a coach on a sports team, especially professional sports. It's conceivable that a team could coach themselves and be successful, but we never see this at anything but the beer league level. I believe that a (good) coach brings coherence, leveraging the team members' strengths and helping to marginalize their weak points.



The most successful professional coaches aren't the ones who strike fear in the hearts of their players, but rather the ones who inspire the players to do their best for them. Occasionally, that will require more than just gentle prodding. However, a good coach will know which players respond to a swift kick in the rear end and those who require a different approach.



I coached a lot of basketball "back in the day", and there was only a single instance where I yelled at the team. It was actually a calculated gamble, intended to get their attention because yelling is something that I never did. It worked, owing mainly to the shock factor since I never did it. I also never did it again. My style was always upbeat, positive and supportive.



I still use this approach when coaching Agile teams, although I haven't yet had to yell at a team! ;)



Dave Rooney

Mayford Technologies

My suggestion? A simple quiet work in private with an explanation of behaviour and example, why it impacts the team/individual/business, a suggestion of corrective behaviour and, in some cases, a consequence if behaviour continues.

I've been coaching for about 8 years now and I've pretty much done a 180 over that time with respect to style. It's my experience that you can talk and talk and lecture and lecture but most teams just aren't really going to "get" some of the subtle agile lessons without first screwing up. You CAN force the issue but, at best, you're going to get grudging compliance that will disappear the moment the team feels you're not watching. The team has to feel like they're doing this for themselves or, in my experience, it won't succeed.

My style has become more "push, then back off", opportunistic, and very small steps. Part of this is due to the fact that I've primarily been involved with guerrilla agile adoption rather than big bang implementations. I tend to wait for someone on the team to observe a problem, then start a discussion about what to do about it (with some suggestions, of course). Get the team to try something, even for just a little while. Sometimes the suggestion takes root, sometimes the team's not ready and they push back. In that case, drop back and regroup and wait for the next opportunity.

Progress is slower, obviously, but when things do get adopted, they usually become entrenched pretty quickly.

The fun part is when an outsider drops by, looks at the state of your agile adoption, and starts pointing out all the flaws.

is it not your role as a coach / manager to create a working environment which is most conducive to productive work as possible? I find the above technique effective - most of the time the person is thankful and often doesn't even realise their behaviour is affecting the team.

Great snapshot of this discussion, but it's Scott Bellware, not Delware.