Sheila's Blog

No one ever said it was going to be easy taking on the role of scrum master.  One of the best things about scrum is also the worst thing about it.  There’s a lot of room for interpretation.  Rather than being a detailed framework, scrum is like a list of guidelines or best practices for developing software.  The purist approach to scrum can be too rigid to flourish in some environments, and after all – scrum is supposed to be about adapting and improving.  I think it’s more important to focus on the spirit of scrum and try and implement the best practices described as best you can.

A large number of companies out there now say that they ‘do scrum’.  This can be a bone of contention, especially for those who have a very strict interpretation of what scrum is, and what it isn’t.  It also presents the problem of taking on the role of scrum master with a team that has been ‘doing scrum’ for a period of time, but not necessarily successfully.  It can be hard to sell a new style of managing software development that comes with the same label on the tin as what’s been done before.  People who have had a negative experience of scrum may be extremely resistent to continuing to use it, even in a different form.

It’s a daunting task to take responsibility for a team. When you’re inheriting a development process that has a list of ‘issues’ so long you can’t see the end of it, it’s easy to get lost just trying to figure out where to start. In the mean time, you have a team that needs to be kept productively busy while you find a way to start progressing in the direction you want to go.  Really, the only place to start with is the Product Backlog.  If that’s not right, everything is going to fall apart.  This is something to tackle first with the Product Owner, and then with the team.

The scrum master and product owner must commit to working on the backlog and producing something useful for the team.  It can be a good idea to put this as a task in the current Sprint – even as one with 0 Story Points.  If the team is to commit to delivering what it promises, the Product Owner and Scrum Master must lead by example and do the same.  Inevitably, the team will need to get involved at a certain point to assist with breaking down the backlog items and assigning story point estimates, but there needs to be something there to start with.

To start generating the Product Backlog, a number of meetings were needed with the Product Owner.  We needed a clear understanding of what projects were potentially in the pipeline, what the deadlines were, and how to prioritise these things.  We started with an extremely high level list of about 10 items that was loosely prioritised.  For each of the items a document was created with a broad description of the item and what it involved.  I then split some of these stories into smaller ones and added some of the tasks that might be needed to complete them.  We reviewed what we had at that point and were happy that the list could be broken down into a Product Backlog that would at least cover a couple of months for the development team.  The team could now provide some input and take the first steps into being less dependent on having the Product Owner present for every single meeting.  This had been a must when requirements were only generated in the Planning meetings at the start of every week.

Tags:   scrumNo Comments