The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Mark Levison on Sep 04, 2008
Is the role of an agile manager only that of servant leader? Should they ever use traditional command and control tools? Should the agile manager ever wield authority and make demands of the team? Should they ever make changes in the membership? This has recently been the topic of discussion on the Lean Agile Scrum mailing list.
Peter Alfvin describes a "servant leader" as:
Wikipedia describes the role as: Servant-leadership emphasizes the leader's role as steward of the resources (human, financial and otherwise) provided by the organization. It encourages leaders to serve others while staying focused on achieving results in line with the organization's values and integrity.
Scott Delware says that:
I don't like wielding swords when I'm a team leader on a software team, but I haven't really figured out yet how to never need to swing a sword and still intercede when team members pathologically do not meet expectations set by leadership and management, and pathologically take risky liberties. ... The problem with wielding a sword is that it's hard to be seen as other than a sword wield once the sword has been wielded
Steven "Doc" List counters:
I don't think a team lead should be a manager, nor vice versa. This is consistent with my understanding of TPS - Team Leads are not in management, have no personnel responsibilities, and are there to help the teams do their best.
...
So the coach/team lead should/could be the charismatic prophet who guides, teaches, and leads the team to higher and higher levels of competence and accomplishment.
The manager should be responsible for personnel issues, moving staff around, hiring and firing.
Mary Poppendieck notes that she has never liked the term "servant leader" saying that doesn't describe what she has seen in successful managers. Instead she sees a manager's job as bringing out the best in people and helping them be part of the team. She goes on to say:
In my experience, it is the leader’s (manager’s) job to intervene in the case of inappropriate behavior, and when he or she does, the rest of the team will be grateful for the intervention. This is not wielding a sword as opposed to being a servant. It is being a “servant” (if that’s what you want to call it) to the whole team by suppressing the individual behavior that will keep the team from being successful.
It’s not about telling people what they are doing wrong. It’s about constantly steering everyone on the team in the direction of success, and never letting any individual compromise the progress of the team toward success.
On the role of coaches Mary warns in cases where the group has both a manager and a coach that the manager often gets pushed off to the side while the coach takes centre stage. When the coach leaves the team reverts to its old behaviors. For the changes to stick to for the team to continue improve she believes that the manager must learn how to coach.
Tom Stephen shares his experience in how military command and control work:
the most effective fighting (successful) force is the one where small unit leaders make local decisions. They are closest to the fighting and therefore need the flexibility to make on-the-spot decisions based on the circumstances. ... This doesn't mean that senior leadership leaves it all to the small unit commanders. Their job is to set the objectives, remove obstacles, and very importantly lead by example. Let the leaders on the ground figure out how to best execute.
In addition Tom notes that the junior people (lowest ranking) are usually asked for their ideas first so that their ideas are incorporated before senior people set the tone.
Case Study: IBM's Agile Transformation
18 agile and lean practices for effective software development governance
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
...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.
Tell them what they are doing wrong; tell them how they should fix it; tell them what will happen if they don't. This seems very prescriptive to me, and only views things from your perspective. At some point you need to talk to the employee, try to see things from their perspective, and explore why the situation arose to start with. Hopefully the explorative discussion will provide them with the clarity and focus required to suggest their own solution. They will be far more likely to buy in to a solution reached as a result of a dialogue, than a prescribed one.
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.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
9 comments
Watch Thread Reply