May 25th, 2010
The One Where The ScrumMaster Was Also A Developer
This blog post is the first in a series of stories from real Scrum teams (although the names etc have been changed to protect anonymity).
Marcel had been at the company for 7 years and, in that time, had come to be known as the “go-to guy” for Java work. In fact he was known affectionately as the “Java Guru”. The last project was a really important one for the whole company and, naturally Marcel was a central part of the effort to build this product. On more than one occasion he had come up with a breakthrough to help get the team and project back on track and, with a monumental effort from everyone, the project just about met the deadline.
In an attempt to get things under a little more control and avoid this type of situation in the future, management had decided that it was time to start using Scrum. One problem they had was they couldn’t afford a dedicated ScrumMaster and so, after the whole team were trained in Scrum, management asked Marcel if he would take the role on as he was the most experienced person on the team.
Marcel seemed apprehensive but had not got to where he was by saying no when asked if he could take on more responsibility so agreed. He found this challenging almost immediately when working with the team and the Product Owner to come up with the Sprint plan – how much time was he going to spend doing his ScrumMaster work? And therefore, how much of the Product Backlog could he and the team commit to? During the sprint, finding time to chase down the team impediments while also trying to complete his tasks was a constant headache and he often found himself stopping mid-task to shift his focus to a problem the team needed resolving.
Also, the team didn’t seem to be very self-organising as they were supposed to be with Scrum and he couldn’t work out why.
Can a person be a ScrumMaster and a member of the development team at the same time? This is a question that I think I have been asked every week for the last 5 years (or at least it feels like it). From Marcel’s point of view he was obviously very conflicted, between his duties as a member of the team and his responsibilities as a ScrumMaster in servant-leadership of the development team.
First of all this dual-role has made planning (both at a sprint level and release level) even harder than it would normally be as there is an additional unknown variable thrown into the mix, namely how much of Marcel’s time can he spend on development activities and how effective will the rest of the team be without a full-time ScrumMaster? Marcel and the rest of the development team could agree on a figure (say 30%) that they think Marcel would be able to spend on items on the Sprint Backlog as one way of handling it. This at least gives them something to go with but there is another issue here – which items should Marcel commit to?
A team member who is not totally committed (which is effectively what Marcel has become) poses a new problem for the team in that, if he takes on the high-risk or high-priority items, there is a very high chance that he will be interrupted during his work leading to either delay or, in some cases, mistakes. For this reason, the team may decide that it would be prudent for Marcel to focus more on the lower risk items, letting the “full-time” people tackle the higher risk items. This mitigates risk but also loses the value that the “Java Guru” could and should be adding to the team and the Sprint.
Marcel will also probably end up doing less of the job he likes and I see the loss of passion and enjoyment a lot in people taking on these dual roles. This will almost always lead to a loss of productivity, not just in the individual but in the rest of the team as well as they subconsciously get dragged down by it. Of course, this could be the beginning of a whole new career direction for Marcel but, in my experience, that is the exception rather than the norm.
One of the typical problems I see in teams that employ the developer/ScrumMaster dual role is that the rest of the team is slower to self-organise, and in many cases, just don’t get there. I put this down to two factors: firstly the lack of focus of the ScrumMaster (and the fact that quite often it is not the right person) holds a team back due to the lack of coaching and facilitation time available; and secondly, the implied hierarchy of one person with two roles. This person with the dual-role at least appears to be a little bit more important than the rest of the development team and this can stop the rest of the team “stepping up” and increase the feeling of responsibility of the person with the dual-role.
An option for Marcel and the team could be to rotate the role with each member of the development team taking on the dual-role for a Sprint at a time. This would remove the implied hierarchical challenges and mitigate the impacts on Marcel’s technical passion. It would also give every member of the team an opportunity to get some experience in removing impediments and serving the team, almost increasing the self-organisational capabilities of each team member in turn. However, you are almost certain to have someone in the team who is either unsuitable for this role, or not happy about taking it on and therefore are almost guaranteed to have at least one Sprint where the team struggles. Also, a big part of being an effective ScrumMaster is the networking within the organisation: knowing who to speak to and where to go when a certain problem comes up. By only giving each person one Sprint to play the role, nobody is going to get the opportunity to build up their network and “get their teeth into” the role.
Another option would be to duplicate the dual-role i.e. have two people (or possibly the whole team) who are both developer/ScrumMasters. This way whoever is least “in the zone” with their work could pick up the ScrumMaster responsibilities and the risk is spread a little. Obviously we are then bringing the sub-optimisation that comes with task switching to more people instead of one and making planning even harder and there is no focal point for impediment removal.
In this particular scenario, the team found that because Marcel couldn’t be relied upon to perform his development “heroics” others in the team had to step up technically which, although meant a short-term velocity drop, was a massive boost to long-term productivity and teamwork.
Scrum itself is not particularly prescriptive about this situation although its values of commitment and focus imply to me that it is not recommended. Also in practice it is usually sub-optimal in that it compromises both the development efforts of the individual and the effectiveness of the ScrumMaster role, usually leading to lower velocity of the team. Therefore it is probably best for this situation to be avoided wherever possible, or at least until the team is mature enough to be able to cope with a part-time ScrumMaster. The team would really have to work out how to balance things such that they have the greatest chance of success – would having Marcel fully focussing on his role as developer with a less effective ScrumMaster be better for the team than having a dual-role within the team?
A secondary consideration here is the message that the organisation is sending by not supporting the team with the ScrumMaster that Scrum requires. This is a fundamentally important role and a full-time role too. It isn’t really a question of whether the organisation can afford a ScrumMaster but rather can they afford NOT to have one? This is a question certainly worth asking. Although the options above are all valid ways of coping with the issue, a better solution would be to look at the issue itself – very much what a ScrumMaster is there to do.
0 comments | view comments | add comment