Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
0 likes1,317 views
This document summarizes strategies for handling distributed and remote teams when using Scrum. It discusses maximizing communication bandwidth between remote team members through tools like video conferencing and pair programming. When offshoring teams, it recommends initially having separated team members rather than fully separated teams. It also provides guidelines for team members working remotely or from home. Finally, it outlines a Scrum Master checklist for the beginning, during, and end of each sprint and emphasizes empowering the self-organizing team over time.
Scrum and-xp-from-the-trenches 08 distributed teams & scrum master checklist
- 1. Scrum Session#8 (Last ) HOSSAM HASSAN KEEP IT SIMPLE & STRAIGHTFORWARD
- 2. Former Session PART FIFTEEN - How we handle multiple Scrum teams
- 3. Agenda Backlog PART SIXTEEN - How we handle geographically distributed teams ◦ Distributed teams ◦ Communication bandwidth in a wider sense ◦ Some Implemented Measures ◦ Offshoring ◦ Team members working from home PART SEVENTEEN - Scrum-master checklist ◦ Beginning of sprint ◦ Every day ◦ End of sprint ◦ Try to make yourself redundant
- 4. PART SIXTEEN HOW WE HANDLE GEOGRAPHICALLY DISTRIBUTED TEAMS
- 5. Distributed Teams •Distributed teams are everywhere. •Most open-source projects are built by fully distributed teams, so there’s no doubting that it can be done. •Nevertheless, nothing can beat the productivity of a small, cross-functional team sitting together in the same room, 100% focused on a single shared goal. •So the first priority should always be to try to achieve that context, or to get as close as possible. •If you still can’t avoid having team members in different locations, try to get the best tools and techniques to mitigate the damage.
- 6. Our Strategy •Our strategy for this is quite simple. •We use every trick we can come up with to maximize the communication bandwidth between the physically separated team members. •I don’t only mean communication bandwidth as in megabit/second (although that is of course important as well). •I mean communication bandwidth in a wider sense.
- 7. Communication bandwidth in a wider sense • The ability to pair-program together • The ability to meet face to face at the daily scrum • The ability to have face-to-face discussions at any time • The ability to meet physically and socialize • The ability to have spontaneous meetings with the whole team • The ability to see the same view of the sprint backlog, sprint burn down, product backlog, and other information radiators
- 8. Some Implemented Measures • Webcam and headset at each workstation • Remote-enabled conference rooms with webcams, conference microphones, always-on- always-ready computers, desktop-sharing software, etc. • Remote windows – big screens at each location, showing a permanent view of the other locations, sort of like a virtual window between two departments. You can stand there and wave. You can see who is at his desk and who is talking to whom. This is to create a feeling of “Hey, we’re in this together.” • Exchange programs, where people from each location travel and visit each other on a regular basis. As usual it’s all about experimenting: inspect => adapt => inspect => adapt => inspect => adapt => inspect => adapt => inspect => adapt
- 9. Offshoring There are two main strategies here: 1. Separated Teams 2. Separated Team Members. The first strategy, separated teams, is a compelling choice. Nevertheless, we have started with the second strategy, separated team members for several reasons.
- 10. Using Separated Team Members Reasons 1. We want the team members to get to know each other well. 2. We want excellent communication infrastructure between the two locations, and want to give the teams a strong incentive to set this up. 3. In the beginning, the offshore team is too small to form an effective scrum team on their own. 4. We want a period of intense knowledge sharing before independent offshore teams will be a feasible option. In the long run, we may well move towards the “separated teams” strategy.
- 11. Team members working from home •Working from home can be really good sometimes. •Sometimes you can get more programming done in one day at home than a whole week at work. At least, if you don’t have kids. :o) •Yet one of the fundamentals in Scrum is that the whole team should be physically collocated. •So what do we do? •Basically, we leave it to the teams to decide when and how often it is OK to work from home. •Some team members work from home regularly due to long commutes. •We do, however, encourage the teams to be physically collocated “most” of the time. •When team members work from home they join the daily scrum using a Skype voice call (sometimes video). They are online through instant messaging all day. Not as good as being in the same room, but good enough. •We once tried the concept of having Wednesdays designated as focus day.
- 12. Self-Organizing Team •One of the key ideas in Scrum is the self-organizing team. •The importance of this can’t be overstated. •The team should be given as much responsibility as possible, including things like work hours and work from home policies. •Self-organization is the key to creativity, motivation, innovation, and many other Good Things! •Some managers are afraid that teams will misuse this trust, but I rarely see that happen in practice. •As long as the team is clearly accountable for the product they deliver, they tend to act responsibly.
- 14. Scrum Master Checklist 1. Beginning of sprint 2. Every day 3. End of sprint
- 15. Beginning of sprint • After the sprint planning meeting, create a sprint info page. • Add a link to your page from the dashboard on the wiki. • Print the page and put it on the wall where people pass by your team. • Send an email to everyone announcing that a new sprint is started. Include the sprint goal and a link to the sprint info page. • Update the sprint statistics document. Add your estimated velocity, team size, sprint length, etc.
- 16. Every day • Make sure the daily scrum meeting starts and ends on time. • Make sure stories are added/removed from the sprint backlog as necessary to keep the sprint on schedule. • Make sure the product owner is notified of these changes. • Make sure the sprint backlog and burn down are kept up to date by the team. • Make sure problems/impediments are solved or reported to product owner and/or chief of development.
- 17. End of sprint • Do an open sprint demo. • Everyone should be notified about the demo a day or two before. • Do a sprint retrospective with the whole team and product owner. Invite the chief of development as well, so he can help spread the lessons learned. • Update the sprint statistics document. Add the actual velocity and key points from the retrospective.
- 18. Try to make yourself redundant •Although over time, as Scrum master, try to make yourself redundant. •Coach the team to do these things without you. •Even if you don’t succeed in making yourself redundant, the very act of trying will lead you to do Good Things. •Some Scrum masters end up in a role more like Scrum admin or Scrum slave because they are so keen on pleasing the team. •If the team relies too much on you, then you are effectively hindering their ability to self-organize. •In the beginning, that may be fine if the team is new to Scrum and needs your help. •But over time, you should slowly back out from admin stuff and give the team more and more responsibility. •That saves time for you to chase impediments, or do non-Scrum-master stuff like coding, testing, etc.