Search this site
A summarized checklist for use by a ScrumMaster running Scrum – how to be good at this role
Filed Under Agile, Scrum, ScrumMaster | Posted on March 9, 2010
Running a Scrum team is not very difficult, and a ScrumMaster can handle multiple Scrums (I have seen ScrumMasters handling multiple Scrum teams) as long as the timing of the daily Scrum meeting is modified. After all, you need to make sure that the team is there on time, are being brief and to the point, and you are ensuring that their impediments are being handled. Right, it’s that simple, right ? Well, there is a lot more you can do, to make sure that your Scrum team is working at peak productivity and efficiency, and this can be real rewarding for you to handle.
Here is an external checklist that is very detailed and useful (link to checklist).
The following is a much shorter version of some of the tips that seem to be useful in ensuring that you do a good job of the role of ScrumMaster. What are the things that you need to do or have (in terms of traits) that can help you be good at this role? Here are some tips:
- Be skillful in ensuring that you are not becoming the impediment for the team, or a bottleneck for the team. If you believe in the traditional command and control kind of system rather than the team being a empowered team, then you are doing a dis-service to the team or to the Scrum process.
- The ScrumMaster should work to ensure that the team treats the Daily Scrum as an occasion where the team talks to each other rather than to the ScrumMaster
- Work to anticipate problems rather than being reactive. If you only react to the impediments that are raised, then you will forever be chasing the impact of problems rather than working to prevent them from happening.
- Training. The ScrumMaster is a pivotal person who can provide guidance to the team about the processes followed in Scrum, work to ensure that they totally understand it, and point out issues as he sees it
- The ScrumMaster should never act as an intermediate between the product owner and the teams, even though the product owner may feel that their time is limited and would prefer the ScrumMaster to be the funnel through which information flow happens
- Work to get feedback and ensure that this feedback is incorporated. The team, especially after they get experience, typically has a lot of useful information to offer in the retrospective, but will continue to do so if they feel that their feedback is being valued and steps taken to incorporate the feedback.
- Once in a while, it is useful for the ScrumMaster to get some third party feedback, ideally by an expert in the process of Scrum
- Works to resolve dependencies. There are very few projects that are totally stand-alone, with teams being dependent on other groups (internal and external) in terms of either schedule of deliveries, or in terms of some critical technology. The ScrumMaster needs to take effective action to ensure that such dependencies are resolved in time.
- The ScrumMaster needs to have a checklist in place; this brings in a degree of thoroughness that can make the ScrumMaster even more effective (and also helps if somebody has to take over for periods in between)
- The ScrumMaster acts as a shield between the Scrum team and the external stakeholders such as management, engineering managers; this needs to be a very effective shield to ensure that people do not try to apply influence in a way that could affect the team.
Scrum terms – What is Velocity ? – a brief description
Filed Under Agile, Scrum | Posted on March 6, 2010
Scrum comes with its own set of terms, some of which should be familiar to all of you by now. This post will talk about the term called ‘Velocity’, which in normal English is a slightly scientific way of talking about speed. You would consider that Scrum will not deviate too much when using the word, and hence in Scrum-speak, Velocity refers to the amount of work that can be done in one Sprint cycle, and is partly derived from the experiences of previous Sprints. It is a summary of all the stories that the team done in the current Sprint, multiplied by the effort taken for each story, so if a team did 3 stories with an effort of 4 days each, and did 2 stories with an effort of 5 days each, then the Velocity for the team will be = 3*4 + 2*5 = 22. Note, for Scrum, we try to stay away from marking estimates with actual time intervals such as hours, days, etc, so when measuring the Velocity, the effort required for each story is defined in something called Story points rather than time durations.
So, when a Sprint cycle has completed (or multiple Sprint cycles have got completed), the team can review the amount of work that got done in these cycles, and develop a fair idea of what is the amount of effort that they can complete in the current cycle, and that actually becomes the Velocity. As you move over time and do multiple Sprints, the Velocity will be a very useful tool that will allow you to plan and predict the amount of work that the team can do in future Sprint cycles.
What does the ScrumMaster do about velocity, especially when the team is a bit new ? Well, if the team keeps on improving their Velocity as they move ahead on Sprint cycles, then that is a good movement, and the ScrumMaster can work with the team to understand the improvements that have happened, so that these can be built on. Conversely, when the team is not able to improve its Velocity or the Velocity even reduces, it is a bad sign for the team since it means that they are not able to generate the required level of accuracy, and even improve on these estimates. However, do not get into the concept of trying to compare the Velocity across multiple groups implementing Scrum; the effort that each group puts in, the amount of work that can happen, the degree of difficulty, all of these determine the actual amount of stories that the team can complete.
However, Velocity also means that you are looking forward, not looking at the amount of work that employees are actually doing; so if that means that an employee spent night and day resolving some complex issues, in terms of Velocity, it will be defined as a reduction of the amount of work required (and you might not even credit the employee for the amount of hard work required to get the work done as per time and schedule)
What are some of the impediments that can hold up a Daily Scrum ? How are impediments handled ?
Filed Under Agile, Issues, Meeting, Pitfalls, Problems, Process, Scrum | Posted on March 5, 2010
Part of the routine of a Daily Scrum is where team members come up with the issues that they face which could be stopping them from doing their work. These are called impediments, and are typically problems that are preventing them from completing their work. Once the team members articulate their impediments, it is the role of the ScrumMaster to resolve these issues. But resolving of these impediments is not done during the Daily Scrum meeting, since the meeting is supposed to be a quick and short meeting and this would not be possible if people start solving these impediments right then and there. Further, it would be a big turn-off to other team members if they have to sit in a meeting where some issue is being discussed that is not relevant to them.
An impediment is just that, anything that prevents a person from getting their tasks done. It could be complicated matters such as technical dependencies, or it could be small matters such as an unpleasant odor near the office of the person, or a non-working machine. Once these are communicated during the meeting, it is then the responsibility of the ScrumMaster to resolve these issues offline, depending on the nature of the impediment. Some matters would require the ScrumMaster to call a meeting to resolve these issues, while infrastructural issues need to be handled by the ScrumMaster by contacting the required organizational persons. These can also be policies related to the organization (typically found in teams which have recently moved over to Scrum or where the organization uses other methods of development for a significant number of its projects). In such cases, the ScrumMaster will have to also raise these organizational issues. If the team members start to get a feeling that their impediments are not being handled in time or handled effectively, it can quickly have a very quick effect on the efficiency of the whole Scrum process. Part of the process of impediment handling is to ensure that people can see the status of their impediments, when they will be resolved, and that there is sustained action towards the same. If this require some sort of tool, then that should also be used.
Some of the more difficult impediments relate to personnel issues. You could have a team member who is dragging his / her feet, either because of lack of capability, or because they are not convinced about Scrum; in such cases, resolutions can be to try and figure out what is wrong, and if that does not work with the employee, then it makes sense to talk to get a different person.
Some of the impediments are related to user stories or the specifications. In such cases, the ScrumMaster has to make sure that he gets the Product Owner (and maybe the experience designer) to answer all questions and provide the required level of detail.
Scrum of Scrums – How the process works, and some modifications / variations
Filed Under Improvement, Issues, Product Management, Product Owner, Scrum | Posted on March 4, 2010
In the previous post (brief overview of Scrum of Scrums), I mentioned the Scrum of Scrums. In this post, will post some more details of how it operates (including some variations), and some scenarios in which it is needed.
When needed
A Scrum of Scrums is very useful when the overall project is much larger than a single Scrum team, and the teams need to ensure that they have a good system of communication going across the teams. The Scrum of Scrums also helps to ensure that the teams are working to remove any cross team impediments This is where representatives from the various Scrum teams get together, work through what activities are happening across teams and also ensure that efficient coordination is happening across the teams. It works to have a ScrumMaster (you can also call him the Uber ScrumMaster) for running and coordinating this Scrum of Scrums. The Scrum of Scrums can meet daily, or alternate days, but lag behind the regular Scrum, since it is the issues that emerge from the regular Scrum that are discussed in the Scrum of Scrums.
Scrum of Scrums – what needs to get addressed
The Scrum of Scrums lasts longer than the regular Scrum meeting, since the issues that get raised at this meeting typically affect far more people than the impediments raised at the regular Scrum meeting, and it makes sense to try and close those issues as early as possible. Team representatives can talk very quickly about what their teams have done, but the major focus is to bring out issues, and to avoid getting into a boasting match about what their teams have done. This meeting is also a good place to walk through higher Product level features that need attention from the Product Management team, or are technically challenging enough that they need to be addressed at a much higher level than the Daily Scrum meeting. The team also reviews the issues raised during previous Scrum of Scrums (maintained in an issues backlog – in such cases, some issues cannot be resolve then and their and needs to be carried forward to another meeting). Using some sort of tool for this purpose is useful, but does not need to be very complicated; in some cases, even Excel or a Twiki is good enough.
Cross Geography Scrum of Scrums
For projects which are located across geographies, such as where teams in different locations are working on separate components that are inter-dependent and which together make up the application, the teams may have their own Scrums at their own location. However, it is pretty important that such teams get together, coordinate, and share notes; and also resolve inter-dependencies. Because of the complication of cross-geographies and different working styles, in such cases, it makes sense to have a daily Scrum of Scrums to make the coordination between them more efficient. In many cases, teams have found that the Scrum of Scrums benefit from having Product Owners and Senior Architects attached to them, attending the meetings when required. One weekly meeting that reviews whether the Scrum of Scrums is having a beneficial effect or needs some modification helps to make the process more tight, more productive.
Ad: 
