I am managing a team of 6 people that recently moved to Scrum.
We have a Scrum Master (one of the developers in the team) and a Product Owner.
Since I have quite a lot of free time (because a lot of management work that I used to do is now done by the Scrum Master and Product Owner), and since I want to remain technically relevant, I am doing some technical development work.
I act as a part of the development team, commit to some of the stories in each sprint, and participate in all the meetings as a part of the team.
Do you think it is a good idea? Can it contradict the “self-organization” of the team?
1
Have a read of Roy Osherove’s developing thoughts on team leadership in an Agile world at 5whys.com
He talks a lot about three key stages a team goes through as it evolves from Waterfall to Scrum.
Survival phase (where most teams I see are in) — in which team has no time to learn — requires a more command and control type of leadership to create that learning time from nothing.
Learning phase — where a team has time to learn and is using it — requires coach like leader, with bursts of control when things will take too long to learn the hard way (choosing no source control, for example)
Self Organization Phase — Where teams can solve their own problems — requires more of a facilitator type of leader, that does not tell people what to do, but simply provides constraints and end goals. The team will get there on its own.
When I came across Roy’s ideas, at OpenVolcano ’10, I was at a complete loss as to why my team had stopped improving. Then I realised that the team had crossed from Survival to Learning and I hadn’t changed my style of management at all. I did so and it helped a lot.
So I suggest figuring out which of those three phases you’re in and managing accordingly.
Also, make a decision now and be a leader or a developer. Don’t fall into the trap of thinking you have spare time until you’re well into the Self-Organisation phase. And, if you get there, realise that you’re a good team leader (it’s difficult) and move on to another team rather than reintegrating yourself.
pdr’s comments are valid, and I agree with them. But I don’t believe them to be universal for all cases.
Your management style will dictate how well or if you even should consider working in two roles.
As the team manager, you hold authority over performance and career type decisions for your employees. Wielded incorrectly, the power disparity between you and your employers can ruin your attempts at being part of the development team.
So long as you are aware of that disparity, and you clearly delineate between your roles, I think that you can be both a manager and a developer. I’ve seen it done successfully a number of times, and I’m currently working on a team in that same situation.
It’s worth noting that you can’t eliminate all of the effects of the disparity. There will be times when you need to bite your tongue and hold back from a spirited debate. There will be others when you need to pull the trump card and point out that ultimate responsibility for the team lies with you, so you’re making a diktat.
You’ll need at least two strong, experienced developers on your team who are politically secure. Their role is to keep the power disparity in check and to call you out if things are getting out of balance. You could get by with just one other strong developer, but having a second provides objectivity in case the two of you get deadlocked on an issue.
I honestly like it when my immediate supervisor keeps himself technically relevant. It facilitates their understanding of my difficulties, and I think we end up with a better performing team.
3
I went through a similar experience before, leading a team of 6 developers in a Scrum team. Besides what pdr and GlenH7 have mentioned, things that helped:
- The best tester on the QA team was really good at keeping us accountable for the quality of our work, including the work I did. When I wrote buggy code, she called me out on it in a way that would be hard for another developer to do.
- I usually did the Sprint Demos, especially when we had bad sprints. Since I was demoing to the CEO, it was embarrassing when stuff didn’t work. Aside from ensuring that I understood features that others developed, it also meant that my stuff had to be as solid as anyone else’s.
- I let others make decisions. My experience is different from that of GlenH7, I always found it to be a mistake to pull the trump card. Instead, I talked through the different consequences of decisions, and made clear to which ever developer was working on something what the consequences were for the thing I thought was the “wrong” way of doing something. There are many reasons for doing this, but the biggest one is that as team lead, you don’t have time to make all the decisions.
- Using a product like Sonar can make things like code quality more objective.
1