Explaining the Task-Board

The task-board is very personal to each team, some teams use virtual boards from their software tools e.g. Jira or TFS but in my experience most prefer a tactile board. Moving index cards or post-its or magnets to show status of the story in progress.

My preference is to also have other documents displayed near the Task-board to help remind the team of certain commitments and to aid them in remaining focused.

1. I like to see the sprint Goal, having this displayed by the task-board makes it convenient for one of the team to pose the question – “Does that help us move to the Sprint Goal?” when a team member proposes adding a new task. It keeps focus and an awareness of direction.

2. I also like to display a list of the impediments raised by the team and if possible the status of them. When resolved they are removed, but when visible it is a reminder to the Scrum Master and the team that there is an impediment we should be looking to remove ASAP.

3. The burndown chart is an obvious example of visible data that is useful for the team. It should be updated daily in advance of the stand-up so that it is available to be discussed as part of the stand-up meeting. In addition to the standard 3 questions I feel it is important for the team to be aware of our progress and when appropriate to discuss what action may be necessary to take.

4. Displaying the commitments from the last retrospective becomes a reminder to the team to be looking to improve, not just the explicit commitments but a general desire to get better.

5. The final document I like to keep near the board is the Definition of Done (and usually the definition of ready too). The definition of done is the team’s agreement to a quality standard. But more than that it is a way of reminding the team that ‘Done’ is more than coding functionality. It is very common for a developer to say “We’ll be done in an hour”, to which my response will regularly be “But will you be done?” and point at the definition of done, usually prompting a clarification to “I’ll be ready to deploy” or “I’ll be ready to hand over to <X> for Smoke testing”. It may seem pedantic, but reminding them that done is a collective agreement and not a single person delivery helps the team work together.

All of these documents are displayed openly in the Team room visible to anyone interested, but they are useful only to the team.

Team rooms will often display far more than this, cartoons, story writing tips, Velocity charts, spider diagrams, support rotas, but the 5 documents listed are the ones I find most useful and encourage any team to keep upto date and visible.

Product Owner Role – Overview

I have been asked to give a summary introduction of the responsibilities of the product owner role to a budding Product Owner. They are due to go on a training course in around six-weeks so this is much more of a high level introduction to the expectations of the role.

I began by outlining some of the core expectation of the role, the delivery expectations and the importance of the role in the process.

But the crucial and generally time consuming aspect of the role is the co-ordination, interaction and management of the stakeholders.

The Product Owner is one of the hardest roles in Scrum, being lobbied by users, the business, the team and others. Giving time to users to properly understand requirements, understanding the goal and vision of the project/product. Identifying priorities. Being available to the team. Making decisions and all the while knowing you are the single wring-able neck, the one person responsible for the success of the project.

The Product Owner is involved in writing stories, planning releases, setting the product vision, the sprint goals and constantly ensuring that the backlog is up to date and prioritised.

It is not for the feint of heart.

Multi-tasking TV viewing

I was aimlessly watching a movie on TV recently, and after about 20 minutes or so it went to an Ad break, I cannot bear TV adverts it is like scratching nails on a blackboard for me and knowing the breaks are quite long I switched to another channel and saw another movie that drew my attention. I watched that for a while – until the next Ad break and switched back, this went on for most of the movie(s). By the end I realised that I had watched enough of both movies to claim I had watched them, but had missed so many crucial plot events that they both felt hollow and disappointing.

What is so interesting about this experience is that it is such a good metaphor for being a Scrum Master of two teams. I’ll come back to this in a bit.

There have been many studies on multi-tasking and context switching (I believe there is a distinct difference – think the difference between juggling and plate spinning) and one that I read recently – http://www.infoq.com/articles/quantifying-impact-agile suggested that if you split someone between two tasks/teams there is a loss of 20% productivity, 3 teams 40% loss etc. I suspect that this is an implicitly accepted value by management and considered an acceptable loss. But it is my opinion that only applies to work that can stack or be put on hold.

If someone is split 50/50 between two teams answering emergency calls say, if they are not there when the call comes in then the call is missed. If the call centre is for the fire service, the loss in productivity and availability is consequential.

Back to being a Scrum Master for two teams. The prevailing view in the industry is that a Scrum Manager can effectively support two teams (some even believe three), but the prevailing view amongst Scrum Masters is that to be truly effective you can only support one team.

My experience is that I cannot context switch this job. It is not possible for one team to pause while I deal with the other, the sprint goes on relentlessly, problems do not wait for me to return, and often problems lurk until I leave to manifest. While I am giving attention to one team I am ignoring and neglecting the other, when I try to remain aware of both I run myself ragged and finish up giving neither attention. I was even asked to take on a third team – which I refused saying I couldn’t give them the attention they need.

So what is the answer? The obvious answer is to say that if money is no object and recruitment was instant and effective and new starters hit the ground running the answer is to hire a good Scrum Master for each team. Sadly that is not the case, there are three development teams and only one Scrum Master and although they are attempting to recruit another, the sad truth is that good Scrum Masters are very hard to find, and underlying all this there is a limit to the budget. A real-world problem that is not easy to solve with a text book response.

That is a little doom and gloom, and most of the time I can support two teams and I think I do a good job. One team is more mature than the other and so I generally split my time 70/30 and both teams seem to be improving (my definition of success). My problem is that I know I could do a great job if I could focus on just one. But is it worth the total neglect of the other?