Retrospectives are the last thing a team does during a Sprint. There are a wide variety of approaches and formats one can use for Retrospectives, but the one thing all have in common is that the Retrospective must produce tangible results. One extremely effective way I have found to help ensure that the Retrospective meets this vital goal is to build a Team Improvement Backlog using the items the team identifies as action items.
A Team Improvement Backlog is nothing more than a prioritized list of action items the team comes up with during its Retrospectives. The most common recommendation, and one I heartily endorse, is that the team collectively chooses the top one or two items on the Team Improvement Backlog at or near the end of each Retrospective and then decides how to implement them and how to demonstrate success. Just like user stories, Team Improvement Backlog items need to have acceptance criteria -- the all-important definition of done.
There are a couple of nuances that can play into management of the Team Improvement Backlog. In general, items teams add to their improvement backlogs are public in keeping with the agile and Scrum values of openness and transparency. There are occasions, however, when I have recommended that certain items be kept private to the team. Examples include specific team interaction items, particularly when those items address individual behaviors. Retrospectives are sometimes more like the closed locker room meetings sports teams hold when they are experiencing a crisis. Teams typically do not allow reporters or even coaches into the locker room during such meetings simply because what the team members have to say to each other is strictly for their benefit as a team. In my coaching experience, private improvement backlog items are rare, but it's a handy tool to have in your bag especially when teams are storming.
Keep the Team Improvement Backlog visible in the team room and track progress at each Retrospective at the latest. Individuals who take on improvement items should also be talking about their work and plans during the Daily Scrum.
If you're not already using a Team Improvement Backlog, add this handy tool to your repertoire and use it to help your teams grow.
All for now....
...-.-
Friday, December 10, 2010
Wednesday, December 8, 2010
ScrumMaster Dilemmas
A few weeks ago, during a Product Owner class I was teaching, the lone practicing ScrumMaster in the room raised his hand after I had finished the section of the course reviewing Scrum roles. His question was basically this: "So, you just said one of the ScrumMaster's functions is to be a bulldozer, but when I solved a problem for my team last week, they accused me of 'throwing them under the bus' and now they won't talk about impediments anymore. What am I supposed to do?"
After learning more about the situation, I understood what had happened. At the last Retrospective, the team had raised an issue they were having with their Product Owner and, seeing himself as the fullback, snowplow, bulldozer, problem-solver, the ScrumMaster had simply taken the team's concerns to the Product Owner and worked out a solution. When he (the ScrumMaster) reported back to the team during a Daily Scrum his progress in resolving the issue with the Product Owner, the team reacted very negatively, as the ScrumMaster had described in his original question.
His confusion and genuine sense of hurt were palpable. He thought his role was to clear the road for the team so that they could get their work done as efficiently and effectively as possible. His point is entirely valid, but his experience demonstrates one of the many dilemmas that face ScrumMasters.
Take it to the team!
In her excellent book*, Lyssa Adkins gives this advice again and again. Self-organizing teams need to be empowered to solve their own problems -- or at least to devise prospective solutions to the problems they face. The ScrumMaster in my class did not realize that self-organizing teams, even those that have only been practicing for a few months, do not want to be presented with solutions to problems. Instead, as Lyssa points out, self-organizing teams want, and need, to be presented with problems. The team is then empowered to devise solutions -- and the team's solution will be the best one for that team. It may not be the solution the ScrumMaster would have chosen, but that does not change this essential fact.
Despite the best of intentions, ScrumMasters run into difficulties with their teams when they take on problems and solve them without team involvement. The team may ask their ScrumMaster to implement the solution to a problem, but the team itself needs to solve the problem. Many ScrumMasters came from backgrounds where individual problem solving was a major part of their job descriptions. Perhaps they were even evaluated on the basis of their individual problem-solving prowess. In a Scrum (or other agile framework) team environment, the equation changes. Problem solving abilities are still valuable, but within the context of of the self-organizing team.
ScrumMasters must engage in a delicate balancing act, being the bulldozer, fullback, or snowplow for their team, yet not imposing solutions on the team. It is more difficult to achieve this balance when a ScrumMaster is responsible for more than one team. Under pressure to help their teams succeed and with a severely limited amount of time and attention to offer to each team, such ScrumMasters are naturally inclined to gather lists of problems and run with them, handing solutions to their teams in rapid succession. This situation is bad for the teams, stunting their growth and inviting resentment against their ScrumMaster; it is also bad for the ScrumMaster who never really has time to get to know each team and the various individuals at the depth necessary to achieve the highest degree of effectiveness.
So what's a ScrumMaster to do? "Take it to the team," let the team solve problems, and keep the wolves at bay.
All for now....
...-.-
*Lyssa Adkins, Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Upper Saddle River, NJ: Addison-Wesley, 2010.
After learning more about the situation, I understood what had happened. At the last Retrospective, the team had raised an issue they were having with their Product Owner and, seeing himself as the fullback, snowplow, bulldozer, problem-solver, the ScrumMaster had simply taken the team's concerns to the Product Owner and worked out a solution. When he (the ScrumMaster) reported back to the team during a Daily Scrum his progress in resolving the issue with the Product Owner, the team reacted very negatively, as the ScrumMaster had described in his original question.
His confusion and genuine sense of hurt were palpable. He thought his role was to clear the road for the team so that they could get their work done as efficiently and effectively as possible. His point is entirely valid, but his experience demonstrates one of the many dilemmas that face ScrumMasters.
Take it to the team!
In her excellent book*, Lyssa Adkins gives this advice again and again. Self-organizing teams need to be empowered to solve their own problems -- or at least to devise prospective solutions to the problems they face. The ScrumMaster in my class did not realize that self-organizing teams, even those that have only been practicing for a few months, do not want to be presented with solutions to problems. Instead, as Lyssa points out, self-organizing teams want, and need, to be presented with problems. The team is then empowered to devise solutions -- and the team's solution will be the best one for that team. It may not be the solution the ScrumMaster would have chosen, but that does not change this essential fact.
Despite the best of intentions, ScrumMasters run into difficulties with their teams when they take on problems and solve them without team involvement. The team may ask their ScrumMaster to implement the solution to a problem, but the team itself needs to solve the problem. Many ScrumMasters came from backgrounds where individual problem solving was a major part of their job descriptions. Perhaps they were even evaluated on the basis of their individual problem-solving prowess. In a Scrum (or other agile framework) team environment, the equation changes. Problem solving abilities are still valuable, but within the context of of the self-organizing team.
ScrumMasters must engage in a delicate balancing act, being the bulldozer, fullback, or snowplow for their team, yet not imposing solutions on the team. It is more difficult to achieve this balance when a ScrumMaster is responsible for more than one team. Under pressure to help their teams succeed and with a severely limited amount of time and attention to offer to each team, such ScrumMasters are naturally inclined to gather lists of problems and run with them, handing solutions to their teams in rapid succession. This situation is bad for the teams, stunting their growth and inviting resentment against their ScrumMaster; it is also bad for the ScrumMaster who never really has time to get to know each team and the various individuals at the depth necessary to achieve the highest degree of effectiveness.
So what's a ScrumMaster to do? "Take it to the team," let the team solve problems, and keep the wolves at bay.
All for now....
...-.-
*Lyssa Adkins, Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Upper Saddle River, NJ: Addison-Wesley, 2010.
Subscribe to:
Posts (Atom)
