views:

231

answers:

7

We are a small team of 5 people (Product Owner, Product Owner Assistant, and 3 Developers) and I am currently moving us to become an Agile team using scrum to manage the project. I have been reading Agile Project Management with scrum, the help documentation for Rally, and various blogs to try and bring myself up to speed on Agile software development practices and roles. I am currently the team lead and also the only one who would be able to play the role of scrum master for our team.

My problem is that I need to be able to serve as the scrum master as well as a member of the agile team which seems violate the domain boundaries of the agile team.

Can I reasonably be both a scrum master and a developer for our team? What pitfalls should I look out for as I try to fulfill both roles and what can I do to address them?

+5  A: 

IMO, yes you could do both. As for pitfalls, here are a few:

  1. Team autonomy - The other developers are part of the same team with you and in theory there isn't an hierarchy in terms of control, so be aware of when you think you may be on a power trip or when the PO may go on a power trip as these can be where things could get ugly at times.

  2. Bringing in Agile too quickly and overwhelming your team - Not everyone will want to change how things go and accept a bunch of different rules and practices. Try to bring in things over time, so that what works well can get its own kinks worked out before another practice gets added. Setting up sprints, estimating tasks, breaking down work into stories, having daily standups and having demonstrations at the end of sprints are all separate pieces that may do better if you add one and let it sink in before trying to put too much in at once.

  3. Buy-in from the PO and assistant - Make sure these people know their role in the process and how if something in the backlog has to be re-prioritized or if something has to be added or dropped, what the procedure is here. There is nothing worse than doing the demos for the phantom customer that isn't there to give feedback which is crucial to the overall process.

  4. Splitting time - There are some Scrum Master things that will take some time away such as creating burn down charts and tracking velocity over time. This may mean that you'll be a partial developer rather than the 100% developer you are now. Where I work, we have a BA that is the Scrum Master and it works well here.

Those are the big ones that I can easily state along with the management of where you work and project manager also being OK with this process and understanding that everything isn't all planned out and that is OK.

JB King
+3  A: 

You can serve as a part-time developer if you are the Scrum Master. In reality, it depends on how much time you spend clearing impediments as to how much time you can code.

For the first Sprint, try to allow for yourself no more than half of the capacity as the other developers, and tell them you are doing so and why. If there are fewer than expected impediments, you can always drag stuff off the backlogs to keep yourself busy.

In the Sprint review, you can adjust how much of your capacity you will "guarantee" for the purposes of development. If you see you are over committed in the Sprint, reduce your development capacity.

For me, I probably wouldn't ever commit to more than 1/2 capacity, because there's always something silly going on that'll need some attention.

ntcolonel
+6  A: 

This probably isn't exactly the answer you're looking for, but hopefully I can provide some insight.

I worked for a good deal of time under the scrum methodology. One thing I leaned while working under it is that scrum isn't a "one size fits all" technique. Everybody's business is different. It's very easy to take a protocol like scrum and adhere so tightly to it that you get caught up in who's in charge of what and what needs to get done by who. The "worst case" scenario is something like what can be seen in Prisoner of Process on TheDailyWTF.

My advice is to try it out: you can't know whether the role is suitable until you try it out for yourself. Everybody and every company is different; your team may jive well with your dual-position. On the other hand, processes might be encountered that cause your position to become a stumbling block.

Lastly--and somewhat off-topic--don't be afraid to bend the rules. If something needs to get done, there shouldn't be a bureaucratic nightmare when a simple task needs to get taken care of. On the other hand, don't habitually bend rules; instead, consistency in your decisions and processes will benefit your end goals.

Hope this helps and good luck.

mattbasta
+5  A: 

Ideally no.

  • One objective of the scrum master is to remove road blocks to development.
  • The objective of the team member is to complete all committed tasks for that sprint.

If you are both, what would you do if on the last day of the sprint you are working hard to complete your task and another team member brings you a problem they need their scrum master to solve as soon as possible? Which would take priority?

In the 'real world' you may need to live with the resources that you have, I would say in many cases the team lead will also be the Scrum Master.

You may find some answers in this question relevant as well.
Does the scrum master have to answer the 3 standup questions as well?

As for pitfalls

  • The one mentioned above - what will you give priority to, your Scrum master task or your development task?
  • During the daily Scrum meeting each person should be giving their update to the whole team, (not the Scrum Master). If the Scrum Master is also the boss then there can be more of a tendency to talk to the boss and update them, as opposed to updating the team.
Paul Rowland
+3  A: 

One person can be a Scrum Master and a Developer, but it is a compromise.

Ken Schwaber and Jeff Sutherland's Scrum Guide at scrum.org teaches:

The ScrumMaster may be a member of the Team; for example, a developer performing Sprint tasks. However, this often leads to conflicts when the ScrumMaster has to choose between removing impediments and performing tasks. The ScrumMaster should never be the Product Owner.

The compromise is that also being a developer takes time away from the single purpose of being a Scrum Master, to remove impediments.

As Paul Rowland's answer says, having the Scrum Master also be a developer is a compromise, as it means that the person may have to choose between development tasks and the Scrum Master's one defined goal, which is to remove impediments.

And as others have said, if you're new to all of this, start with doing things "by the book" at first if you can. When you have a good feel for how that works, then experiment with changing how you do things - you're agile after all.

JeffH
+1  A: 

Reading the word "domain boundaries", makes me feel very "un-agile". Keep in mind Agile values rather than exact practices, that's Agile is a mind set of "Inspect & adapt", so trying this for a while in your team should tell you the right answer for you team specific case.

As for my experience, I've been working in Agile teams for 2 years & for all that time the team leads always played the scrum master role & it has been working just fine for us

Shady M. Najib
+1  A: 

In my opinion, the greatest challenge is prioritizing between your ScrumMaster tasks, and your development team tasks. In that sense, I would think that you should remove impediments before you take on a development task.

As stated many times, Scrum and Agile are not a one-fits-all. So I guess you will have to try it out and see how it fits ... and of course, inspect and adapt. If you see you are taking on tasks and not completing them because of a growing impediments list, cut down on your development commitments in the next sprint, or take less challenging task.

NeoDesign