Comments on: Handling Absence in Scrum Teams http://blog.punchbarrel.com/2008/10/16/handling-absence-in-scrum-teams/ Frank Carver's musings about software and life Sun, 22 Jan 2012 22:15:12 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Frank http://blog.punchbarrel.com/2008/10/16/handling-absence-in-scrum-teams/comment-page-1/#comment-730 Frank Sat, 18 Oct 2008 10:23:34 +0000 http://blog.punchbarrel.com/?p=683#comment-730 Interesting question. I guess the strict Scrum answer is that every sprint has a product owner, who is actively involved in answering question, ad-hoc prioritisation, and monitoring progress (using artefacts such as burn-down charts.) The point of the daily stand-up meeting is primarily to share information between team members, and to highlight problems and potential blockers rather than to report progress. In practice I have often found that it is hard to get real stakeholders that involved on a day-to-day basis. It's particularly tricky in our situation where the development team acts on behalf of several different stakeholders and customer managers, often with very different priorities. My practical answer is probably that all of these things are a judgement call within the team. If information transfer to and from stakeholders is a problem, then find out a bit more about where the real problems lie (what information is actually needed, where does it originate, etc.) and build some process or some system to solve it. Such a solution could be as simple as a BVC ("Big Visible Chart") - we use one whole wall of our engineering office as a huge interactive display showing the status of all work that we know about, for example. For more distributed teams a software solution might be more appropriate - we are also experimenting with a small change to the format of check-in comments and some software to extract and summarise development activity from that data. We don't currently deal with absence in an explicit manner, although we do check in everyone's actual and planned leave details into subversion so they may be read by anyone who needs to know. Do you have any ideas? Interesting question. I guess the strict Scrum answer is that every sprint has a product owner, who is actively involved in answering question, ad-hoc prioritisation, and monitoring progress (using artefacts such as burn-down charts.) The point of the daily stand-up meeting is primarily to share information between team members, and to highlight problems and potential blockers rather than to report progress.

In practice I have often found that it is hard to get real stakeholders that involved on a day-to-day basis. It’s particularly tricky in our situation where the development team acts on behalf of several different stakeholders and customer managers, often with very different priorities.

My practical answer is probably that all of these things are a judgement call within the team. If information transfer to and from stakeholders is a problem, then find out a bit more about where the real problems lie (what information is actually needed, where does it originate, etc.) and build some process or some system to solve it.

Such a solution could be as simple as a BVC (“Big Visible Chart”) – we use one whole wall of our engineering office as a huge interactive display showing the status of all work that we know about, for example. For more distributed teams a software solution might be more appropriate – we are also experimenting with a small change to the format of check-in comments and some software to extract and summarise development activity from that data.

We don’t currently deal with absence in an explicit manner, although we do check in everyone’s actual and planned leave details into subversion so they may be read by anyone who needs to know.

Do you have any ideas?

]]> By: Litty Joseph http://blog.punchbarrel.com/2008/10/16/handling-absence-in-scrum-teams/comment-page-1/#comment-729 Litty Joseph Sat, 18 Oct 2008 08:42:13 +0000 http://blog.punchbarrel.com/?p=683#comment-729 Besides informing about absence (hence risk to sprint commitments ), what is the recommended process for giving a a regular progress update to stakeholders? As stakeholders aren't part of daily stand-up meetings, everything gets postponed to further offline action items. When every action items get postponed daily scrum meetings become life-less and hence boring. Will you suggest a way out? Besides informing about absence (hence risk to sprint commitments ), what is the recommended process for giving a a regular progress update to stakeholders? As stakeholders aren’t part of daily stand-up meetings, everything gets postponed to further offline action items. When every action items get postponed daily scrum meetings become life-less and hence boring. Will you suggest a way out?

]]>