PrintNumber ErrorLocation Error Correction DateAdded
1 viii First printing October 2009 Second printing January 2010 1/12/2010
1 p xix There’s no way to thank Rebecca Traeger enough. She is a miracle worker as an editor, adviser, and sounding board. As the former editor for the Agile Alliance and the Scrum Alliance, I contend that she is the best-read person in the agile world. She’s also the world’s greatest editor. She worked wonders with this book, doing more slicing and dicing than a Veg-O-Matic on a late-night infomercial. This book is significantly better for her involvement in it. There’s no way to thank Rebecca Traeger enough. She is a miracle worker as an editor, adviser, and sounding board. As she is the former editor for the Agile Alliance and the Scrum Alliance, I contend that she is the best-read person in the agile world. She’s also the world’s greatest editor. She worked wonders with this book, doing more slicing and dicing than a Veg-O-Matic on a late-night infomercial. This book is significantly better for her involvement in it. 1/12/2010
1 p 3 One company to realize these benefits by adopting to Scrum is Salesforce.com. Founded in 1999 in a San Francisco apartment, Salesforce.com is one of the true, lasting dot-com-era success stories. One company to realize these benefits by adopting Scrum is Salesforce.com. Founded in 1999 in a San Francisco apartment, Salesforce.com is one of the true, lasting dot-com-era success stories. 1/12/2010
1 p 9 In many organizations, employees have been suffering from future shock for years. Teams are asked to do more with fewer people. Outsourcing and distributed teams have becoming increasingly common. In many organizations, employees have been suffering from future shock for years. Teams are asked to do more with fewer people. Outsourcing and distributed teams have become increasingly common. 1/12/2010
1 p 18 Greene and Fry led the rollout of Scrum at Salesforce.com. They have shared this entertaining slide deck that covers how they did, what they learned, and what they’d do differently. Greene and Fry led the rollout of Scrum at Salesforce.com. They have shared this entertaining slide deck that covers how they did it, what they learned, and what they’d do differently. 1/12/2010
1 p 24 Confusing motion with progress. Every day we see a flurry of activity. Meetings are being held, status reports are being circulated, documents are being written, and code is being checked. It is easy to confuse all of this motion with progress. When a lot is happening, it can be hard to admit that all that activity is not leading us any closer to the desired products. Confusing motion with progress. Every day we see a flurry of activity. Meetings are being held, status reports are being circulated, documents are being written, and code is being checked in. It is easy to confuse all of this motion with progress. When a lot is happening, it can be hard to admit that all that activity is not leading us any closer to the desired products. 1/12/2010
1 p 50 In contrast, choose a quieter approach when you want to experiment either with all of Scrum or just parts of it. For example, maybe you introduce daily meetings—don’t call them daily scrums in this case—and see how that works. Then introduce the idea of working in timeboxed sprints. If these go well, maybe start calling what you’re doing agile or Scrum and proceed from there. Additionally, always choose a stealth approach when it is your only option. If you don’t have the political clout to say, “We’re doing Scrum,” or if doing so will create too much resistance, start quietly. In contrast, choose a quieter approach when you want to experiment either with all of Scrum or just parts of it. For example, maybe you introduce daily meetings—don’t call them daily scrums in this case—and see how that works. Then introduce the idea of working in timeboxed sprints. If these go well, maybe start calling what you’re doing agile or Scrum and proceed from there. Additionally, always choose a stealth approach when it is your only option. If you don’t have the political clout to say, “We’re doing Scrum,” or if doing so will create too much resistance, start quietly. 1/12/2010
1 p 64 Help a community team form to decide how much up-front architecture is enough. Help a community form to decide how much up-front architecture is enough. 1/12/2010
1 p 71 The Enterprise Transition Community and improvement communities I am referring to are specialized types of what are known as communities of practice (Wenger, McDermott, and Synder 2002). The Enterprise Transition Community and improvement communities I am referring to are specialized types of what are known as communities of practice (Wenger, McDermott, and Synder 2002). 1/12/2010
1 p 72 We started building better tools and giving informal talks to different technical groups. (Mediratta 2007) We started building better tools and giving informal talks to different technical groups. (2007) 1/12/2010
1 p 78 Improvement communities are self-motivated and self-organizing. In general, no one is told to join an improved community. (Although this may occasionally be done to start a new community.) Improvement communities are self-motivated and self-organizing. In general, no one is told to join an improvement community. (Although this may occasionally be done to start a new community.) 1/12/2010
1 p 83 What I find best is to select a project whose length is near the middle of what is normal for an organization. Ideally and frequently this is around three or four months. This gives a team plenty of time to start getting good at working within sprints, to enjoy it, and to see the benefits to them and to the product. A three- or four-month project is also usually sufficient for claiming that Scrum will lead to similar success on longer projects. What I find best is to select a project whose length is near the middle of what is normal for an organization. Ideally and frequently this is around three or four months. This gives a team plenty of time to start getting good at working within sprints, to enjoy it, and to see the benefits for the team and for the product. A three- or four-month project is also usually sufficient for claiming that Scrum will lead to similar success on longer projects. 1/12/2010
1 p 83 Not only is coordinating work among that many Scrum teams more than you want to bite off initially, but you also probably wouldn’t have time to grow from one team to more than five anyway if you also looking for a project that can be completed in three or four months. Not only is coordinating work among that many Scrum teams more than you want to bite off initially, but you also probably wouldn’t have time to grow from one team to more than five anyway if you are also looking for a project that can be completed in three or four months. 1/12/2010
1 p 84 Such a team will usually wait to begin their first sprint until they have created a product backlog that contains all of the features that are known at the time. Trond Wingård, an agile project manager, has been successful with this approach. Such a team will usually wait to begin its first sprint until it has created a product backlog that contains all of the features that are known at the time. Trond Wingård, an agile project manager, has been successful with this approach. 1/12/2010
1 p 86 It can be very beneficial to include a well-respected, vocal skeptic as long as the skeptic has demonstrated a past willingness to admit being wrong or changing an opinion. These individuals can become some of the transition’s strongest supporters when convinced of the benefits through hands-on experience. It can be very beneficial to include a well-respected, vocal skeptic as long as the skeptic has demonstrated a past willingness to admit being wrong or change an opinion. These individuals can become some of the transition’s strongest supporters when convinced of the benefits through hands-on experience. 1/12/2010
1 p 97 Although it is the social aspect of change that can create resistance, all resistance comes from specific individuals. Teams or departments do not resist changing to Scrum; individuals do. This chapter, therefore, focuses on effective techniques for overcoming individual’s resistance. Although it is the social aspect of change that can create resistance, all resistance comes from specific individuals. Teams or departments do not resist changing to Scrum; individuals do. This chapter, therefore, focuses on effective techniques for overcoming individual resistance. 1/12/2010
1 p 100 Expose pragmatists to successes of other companies through conferences, regional agile interest groups, and so on. Expose pragmatists to the successes of other companies through conferences, regional agile interest groups, and so on. 1/12/2010
1 p 102 Any successful communication plan will include plenty of opportunity for unconvinced employees to hear from their peers. An article in the MIT Sloan Management Report conveys a similar message. Any successful communication plan will include plenty of opportunities for unconvinced employees to hear from their peers. An article in the MIT Sloan Management Report conveys a similar message. 1/12/2010
1 p 107 Consequently, he habitually pushed the team to bring more work than they could handle into each sprint. Overcommitting was his way of making sure that some features were worked on over at least two sprints. Consequently, he habitually pushed the team to bring more work than it could handle into each sprint. Overcommitting was his way of making sure that some features were worked on over at least two sprints. 1/12/2010
1 p 107 Provide training. Some of a skeptic’s resistance is a result of not having done something or not having seen it done before. Training—whether formal classroom training or as provided by an external coach brought in to work with the team—helps by giving the skeptic the experience of seeing how it can work firsthand. Provide training. Some of a skeptic’s resistance is a result of not having done something or not having seen it done before. Training—whether formal classroom training or as provided by an external coach brought in to work with the team—helps by giving the skeptic the experience of seeing firsthand how it can work. 1/12/2010
1 p 108 It turned out to be the right amount; for the first time the team finished all their work inside one sprint. As team members came to see the value of completing what they committed to, Thad’s subtle efforts to force the team to overcommit were thwarted by the team’s new insistence that they bring in to the sprint only what they could handle. It turned out to be the right amount; for the first time the team finished all its work inside one sprint. As team members came to see the value of completing what they committed to, Thad’s subtle efforts to force the team to overcommit were thwarted by the team’s new insistence that it bring in to the sprint only what it could handle. 1/12/2010
1 p 110 Elena was fortunate to work in a large organization in which she could be moved to a different department that was still taking a wait-and-see attitude toward Scrum. She eventually came around to the point where she is again a productive team member, though even today she will admit to be secretly waiting for a change back to the old way of working. Elena was fortunate to work in a large organization in which she could be moved to a different department that was still taking a wait-and-see attitude toward Scrum. She eventually came around to the point where she is again a productive team member, though even today she will admit she is secretly waiting for a change back to the old way of working. 1/12/2010
1 p 110 Katherine worked as the director of metrics and measurement for a large division of a financial data provider. I had been told she was a supporter of the division’s shift toward Scrum but that she had a few questions for me so that she could more effectively to do her job of collecting process and product metrics. Katherine worked as the director of metrics and measurement for a large division of a financial data provider. I had been told she was a supporter of the division’s shift toward Scrum but that she had a few questions for me so that she could more effectively do her job of collecting process and product metrics. 1/12/2010
1 p 110 She instated some new procedures that dramatically improved things. As a result, teams seemed to be meeting their deadlines (mainly because schedules were padded by what I considered astounding amounts) and quality improved (by creating a separate test group that would spend months testing after a product was handed over to them). She instituted some new procedures that dramatically improved things. As a result, teams seemed to be meeting their deadlines (mainly because schedules were padded by what I considered astounding amounts) and quality improved (by creating a separate test group that would spend months testing after a product was handed over to them). 1/12/2010
1 p 111 This is consistent with the advice of Stewart Tubbs, author of a textbook on small group interaction: This is consistent with the advice of Stewart Tubbs, author of a textbook on small-group interaction: 1/12/2010
1 p 112 Acknowledge and confront fear. Diehards resist in part because of the uncertainty of what their job will look like with Scrum. Acknowledge and confront fear. Diehards resist in part because of the uncertainty of what their jobs will look like with Scrum. 1/12/2010
1 p 113 No one had told me about these annual process changes prior to my first visit with this company, but considering their history of adopting a new process every January, it wasn’t surprising that Dexter would take a wait-it-out approach to Scrum. In fact, many followers adopt this approach, reasoning that this change will be followed by some later change and they might as well skip a few along the way. No one had told me about these annual process changes prior to my first visit with this company, but considering the company’s history of adopting a new process every January, it wasn’t surprising that Dexter would take a wait-it-out approach to Scrum. In fact, many followers adopt this approach, reasoning that this change will be followed by some later change and they might as well skip a few along the way. 1/12/2010
1 p 115 Some of the 12 suggestions in this short book can be used to help overcome resistance. Sections on catching people doing something right and confronting fear are particularly useful. Other suggestions, such as align your culture, are too big to be adequately covered in the 12 pages devoted to it. Some of the 12 suggestions in this short book can be used to help overcome resistance. Sections on catching people doing something right and confronting fear are particularly useful. Other suggestions, such as align your culture, are too big to be adequately covered in the few pages devoted to them. 1/12/2010
1 p 120 On the whole, however, if a team finds that impediments are often not cleared quickly, they should remind their ScrumMaster about the importance of being committed to the team. On the whole, however, if a team finds that impediments are often not cleared quickly, team members should remind their ScrumMaster about the importance of being committed to the team. 1/12/2010
1 p 122 Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Similarly, if a team identifies four or five good ScrumMaster candidates among its ranks, it may want to rotate among them, giving each a chance to try the role. 1/12/2010
1 p 125 Roman Pichler, author of Agile Product Management: Turning Ideas into Winning Products with Scrum, stresses the importance of the product owner: “The product owner has the authority to set a goal and shape the vision. Roman Pichler, author of Agile Product Management with Scrum: Creating Products that Customers Love, stresses the importance of the product owner: “The product owner has the authority to set a goal and shape the vision. 1/12/2010
1 p 125 See Also
See Agile Product Management: Turning Ideas into Winning Products with Scrum by Roman Pichler for a thorough discussion of the product owner role.
See Also
See Agile Product Management with Scrum: Creating Products that Customers Love by Roman Pichler for a thorough discussion of the product owner role.
1/12/2010
1 p 128 the infinitude of possible solutions and gives them a basis for making and comparing choices. Boundaries for that new box are determined by the most important constraints for the business, which may involve things like minimum guaranteed functionality, dramatically faster performance, reduced resource consumption, and, yes, in some cases the date. the infinitude of possible solutions and gives team members a basis for making and comparing choices. Boundaries for that new box are determined by the most important constraints for the business, which may involve things like minimum guaranteed functionality, dramatically faster performance, reduced resource consumption, and, yes, in some cases the date. 1/12/2010
1 p 130 ultimate responsibility and authority, a “the-buck-stops-here” individual. Even with a product owner team, each development team needs to have one identifiable, consistent person they can go to for answers. ultimate responsibility and authority, a “the-buck-stops-here” individual. Even with a product owner team, each development team needs to have one identifiable, consistent person it can go to for answers. 1/12/2010
1 p 130 Available. By far the most frequent complaint I hear from teams about their product owners is that they are unavailable when needed. When a fast-moving team needs an answer to a question, waiting three days for an answer is completely disruptive to the rhythm they’ve established. Available. By far the most frequent complaint I hear from teams about their product owners is that they are unavailable when needed. When a fast-moving team needs an answer to a question, waiting three days for an answer is completely disruptive to the rhythm it has established. 1/12/2010
1 p 133 One difficult goal of “do this amazing thing in 6 months” is in many ways less stressful for the team than 13 successive two-week sprints of “I need more, more, more!” If you have product owners who are pushing teams this way, the ScrumMasters should first push back and then work with the product owners to set longer-term goals for the teams while ensuring teams have commensurate degrees of freedom in how those goals are achieved. One difficult goal of “do this amazing thing in 6 months” is in many ways less stressful for the team than 13 successive two-week sprints of “I need more, more, more!” If you have product owners who are pushing teams this way, the ScrumMasters should first push back and then work with the product owners to set longer-term goals for the teams while ensuring teams have commensurate degrees of freedom in how those goals are achieved. 1/12/2010
1 p 134 On a Scrum team, individuals are asked to look beyond their explicit role to find ways to help the team accomplish its goals. In the next chapter, we look at what this new emphasis on teamwork and shared responsibility means for existing roles in the organization. On a Scrum team, individuals are asked to look beyond their explicit roles to find ways to help the team accomplish its goals. In the next chapter, we look at what this new emphasis on teamwork and shared responsibility means for existing roles in the organization. 1/12/2010
1 p 135 Schwaber, Ken. 2004. Agile project management with scrum. Microsoft Press.
Schwaber’s second book is full of anecdotes about teams using Scrum both successfully and unsuccessfully. In addition to chapters dedicated to the product owner and ScrumMaster roles, other valuable advice on performing those roles is spread throughout the book.
Schwaber, Ken. 2004. Agile project management with Scrum. Microsoft Press.
Schwaber’s second book is full of anecdotes about teams using Scrum both successfully and unsuccessfully. In addition to chapters dedicated to the product owner and ScrumMaster roles, other valuable advice on performing those roles is spread throughout the book.
1/12/2010
1 p 137 For example, the self-organizing nature of a Scrum team eliminates the role of the technical team leader, individuals are asked to look beyond their specialty and help the team in any way possible, emphasis is shifted from writing about requirements to talking about them, and teams are required to produce something tangible by the end of each sprint. For example, the self-organizing nature of a Scrum team eliminates the role of the technical team leader, individuals are asked to look beyond their specialties and help the team in any way possible, emphasis is shifted from writing about requirements to talking about them, and teams are required to produce something tangible by the end of each sprint. 1/12/2010
1 p 140 Other project managers have used their roles to become knowledgeable about the business and its customer. A project manager in this situation will leverage that knowledge into a role as a product owner. This can be an excellent fit, especially for the project manager who is having a hard time completely relinquishing the ability to tell the team what to do. As part of their role, product owners are allowed to tell the team a bit of the “what to do” as long as they stay largely away from telling them how to do it. This can satisfy a former project manager whose nature makes it hard to stop occasionally directing the team.
If a project manager can overcome the old habits of directing the team and making decisions for it, it is likely such a project manager can become a good ScrumMaster. This is the most common new role for project managers in organizations adopting Scrum. The new role will likely be difficult at first for the former project manager as she learns to bite her tongue and let the team learn how to work through their own issues and make decisions.
Other project managers have used their roles to become knowledgeable about the business and its customers. A project manager in this situation will leverage that knowledge into a role as a product owner. This can be an excellent fit, especially for the project manager who is having a hard time completely relinquishing the ability to tell the team what to do. As part of their role, product owners are allowed to tell the team a bit of the “what to do” as long as they stay largely away from telling them how to do it. This can satisfy a former project manager whose nature makes it hard to stop occasionally directing the team.
If a project manager can overcome the old habits of directing the team and making decisions for it, it is likely such a project manager can become a good ScrumMaster. This is the most common new role for project managers in organizations adopting Scrum. The new role will likely be difficult at first for the former project manager as she learns to bite her tongue and let the team learn how to work through its own issues and make decisions.
1/12/2010
1 p 143 The answer to the first of these concerns depends entirely on the architect in question. Many architects may find that very little about their job changes. The answer to the first of these concerns depends entirely on the architect in question. Many architects may find that very little about their jobs changes. 1/12/2010
1 p 146 What do programmers do on a Scrum team? They program. They test. They analyze. They design. They do anything necessary to help the team complete the work committed to for a sprint. Although it is OK to have specialists on a Scrum team, specialists need to be willing to work outside their specialty whenever needed for the greater good of the team. What do programmers do on a Scrum team? They program. They test. They analyze. They design. They do anything necessary to help the team complete the work committed to for a sprint. Although it is OK to have specialists on a Scrum team, specialists need to be willing to work outside their specialties whenever needed for the greater good of the team. 1/12/2010
1 p 149 An increased emphasis on test automation becomes a hallmark of Scrum teams. Even teams that have struggled for years to make progress in automating tests find that the short sprints of Scrum make test automation a necessity. Over time this reduces the reliance on manual testers, those who read a script, push a button, and note the results. An increased emphasis on test automation becomes a hallmark of Scrum teams. Even teams that have struggled for years to make progress in automating tests find that the short sprints of Scrum make test automation a necessity. Over time this reduces the reliance on manual testers: those who read a script, push a button, and note the results. 1/12/2010
1 p 153 Work beyond your specialty. To create something potentially shippable by the end of the sprint, individuals need to be willing to work outside their specialty occasionally. Work beyond your specialty. To create something potentially shippable by the end of the sprint, individuals need to be willing to work outside their specialties occasionally. 1/12/2010
1 p 155 To do so would be inconsistent with the underlying philosophy of Scrum: Trust the team to solve the problem. For example, Scrum doesn’t explicitly say you need to test. It doesn’t say you need to write all code in pairs in test-driven manner. To do so would be inconsistent with the underlying philosophy of Scrum: Trust the team to solve the problem. For example, Scrum doesn’t explicitly say you need to test. It doesn’t say you need to write all code in pairs in a test-driven manner. 1/12/2010
1 p 167 Jones’ 1990 article, “The Breakfast Food Cooker,” remains a classic parable of what can go when software developers over-design a solution. I highly recommended reading it at http://www.ridgecrest.ca.us/~do_while/toaster.htm. Jones’ 1990 article, “The Breakfast Food Cooker,” remains a classic parable of what can go wrong when software developers over-design a solution. I highly recommended reading it at http://www.ridgecrest.ca.us/~do_while/toaster.htm. 1/12/2010
1 p 170 Next the developers asked the product owner if they could work on the part of the system that would display a scanned document to a human who would be able to override the scanned and interpreted values. This was chosen as the second architectural goal of the project for three reasons: Next the developers asked the product owner if they could work on the part of the system that would display a scanned document to a human, who would be able to override the scanned and interpreted values. This was chosen as the second architectural goal of the project for three reasons: 1/12/2010
1 p 181 The impact of team size on overall schedule is shown in Figure 10.3. The impact of team size on overall schedule is shown in Figure 10.3. 1/12/2010
1 p 185 It will be hard for you to prioritize my work and provide feedback on it if my team is working far in advance of yours. Because of this, a component team should not develop new capabilities until one or more feature teams is ready for them. When a component team works far in advance of what feature teams need, they resort to guessing at what capabilities are needed next. All too often this results in components or frameworks that are not usable by the feature teams. All new capabilities, including those built by component teams, should be developed within the context of externally visible functionality. It will be hard for you to prioritize my work and provide feedback on it if my team is working far in advance of yours. Because of this, a component team should not develop new capabilities until one or more feature teams is ready for them. When a component team works far in advance of what feature teams need, it resorts to guessing at what capabilities are needed next. All too often this results in components or frameworks that are not usable by the feature teams. All new capabilities, including those built by component teams, should be developed within the context of externally visible functionality. 1/12/2010
1 p 187 Stories weren’t complete from a user perspective. Teams were working on different features at different times with different acceptance criteria. There was a lot of rework coming back into the system. Teams were blaming each other for incomplete functionality, failing builds, test, etc. Stories weren’t complete from a user perspective. Teams were working on different features at different times with different acceptance criteria. There was a lot of rework coming back into the system. Teams were blaming each other for incomplete functionality, failing builds, tests, etc. 1/12/2010
1 p 189 However, the benefit of allowing a team to self-organize isn’t that the team finds some optimal organization for their work that a manager may have missed. Rather, it is that by allowing the team to self-organize, they are encouraged to fully own the problem. However, the benefit of allowing a team to self-organize isn’t that the team finds some optimal organization for its work that a manager may have missed. Rather, it is that by allowing the team to self-organize, it is encouraged to fully own the problem. 1/12/2010
1 p 190 Homogen-eous teams reach consensus more quickly than do heterogeneous team, but they do so by failing to consider all options (Mello and Ruckes 2006). Homogen-eous teams reach consensus more quickly than do heterogeneous teams, but they do so by failing to consider all options (Mello and Ruckes 2006). 1/12/2010
1 p 196 Institute simple rules. Gaining agreement on simple rules can help lead to the right organizational behavior. A simple rule such as “No one can be assigned to more than two projects,” can work wonders. Johannes Brodwall, chief scientist with Steria in Norway, suggests one simple rule. Institute simple rules. Gaining agreement on simple rules can help lead to the right organizational behavior. A simple rule such as “No one can be assigned to more than two projects” can work wonders. Johannes Brodwall, chief scientist with Steria in Norway, suggests one simple rule. 1/12/2010
1 p 198 Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have between five to nine members. Will you be able to feed most teams with two pizzas? Given the compelling productivity and quality advantages of small teams, the majority of teams in a good design should have five to nine members. 1/12/2010
1 p 198 Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of their unique accountabilities. Does the design support a clear understanding of accountability? A well-designed team structure will reinforce the concept of a shared, all-teams accountability for the overall success of the project while providing each team with clear indicators of its unique accountabilities. 1/12/2010
1 p 203 The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team members know that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck. 1/12/2010
1 p 204 The team’s goal is to finish all of the product backlog items they have committed to for the sprint. This is a whole-team commitment, not a commitment by each person to complete the tasks he or she has signed up for. The team’s goal is to finish all of the product backlog items it has committed to for the sprint. This is a whole-team commitment, not a commitment by each person to complete the tasks he or she has signed up for. 1/12/2010
1 p 207 In figure 11.1, change FedEx to DHL in the lower right hand box. done 1/12/2010
1 p 215 It is hard to overstate the importance of team learning. I meet too many teams who are much improved over how they were before they adopted Scrum but that have failed to improve since. Continuous improvement is part of Scrum; failing to learn, and wasting the knowledge gained are serious deficiencies.
Encourage Collaboration Through Commitment
Tommy Lasorda, long-time manager of the Los Angeles Dodgers baseball team, has said, “My responsibility is to get my twenty-five guys playing for the name on the front of their shirt and not the one on the back” (LaFasto and Larson 2001, 100). Team learning will only get you so far in your quest to become a high-performing, agile team. To keep your self-organizing team working as a unit instead of a collection of individuals, you must constantly reenergize and focus them toward shared goals. To do this you must find ways to renew team members’ commitment to their purpose and to each other. There are a number of things you can do to build and nurture this kind of commitment.
It is hard to overstate the importance of team learning. I meet too many teams who are much improved over how they were before they adopted Scrum but that have failed to improve since. Continuous improvement is part of Scrum; failing to learn and wasting the knowledge gained are serious deficiencies.
Encourage Collaboration Through Commitment
Tommy Lasorda, long-time manager of the Los Angeles Dodgers baseball team, has said, “My responsibility is to get my twenty-five guys playing for the name on the front of their shirt and not the one on the back” (LaFasto and Larson 2001, 100). Team learning will only get you so far in your quest to become a high-performing, agile team. To keep your self-organizing team working as a unit instead of a collection of individuals, you must constantly reenergize and focus it toward shared goals. To do this you must find ways to renew team members’ commitment to their purpose and to each other. There are a number of things you can do to build and nurture this kind of commitment.
1/12/2010
1 p 220 Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.” Then in Wicked Problems, Righteous Solutions in 1990, DeGrace and Stahl describe how managers exercise indirect control over a self-organizing team. Self-organizing teams are not free from management control. Management chooses for them what products to build or often chooses who will work on their projects, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.” Then in Wicked Problems, Righteous Solutions in 1990, DeGrace and Stahl describe how managers exercise indirect control over a self-organizing team. 1/12/2010
1 p 223 Self-organization does not mean a collection of individuals are free to do whatever they want. The individuals self-organize around a problem that is presented to them by the organization. (“We want a product that does this.”) The containers, differences, and exchanges put in place by the organization influence, but do not determine, how a team organizes itself around the problem.
Keep in mind also that a change agent is not fiddling with a team or project’s containers, differences, or exchanges for her own pleasure. The change agent is doing it as part of helping the team become the best that it can be.
Self-organization does not mean a collection of individuals is free to do whatever it wants. The individuals self-organize around a problem that is presented to them by the organization. (“We want a product that does this.”) The containers, differences, and exchanges put in place by the organization influence, but do not determine, how a team organizes itself around the problem.
Keep in mind also that a change agent is not fiddling with a team’s or project’s containers, differences, or exchanges for her own pleasure. The change agent is doing it as part of helping the team become the best that it can be.
1/12/2010
1 p 225 Another good way to amplify differences is to change how the team makes decisions. For example, if a team currently makes decision by a majority vote, ask members to require consensus for the next two sprints. Do the opposite if they currently require consensus. These and other approaches for dampening or amplifying differences are shown in Table 12.2. Another good way to amplify differences is to change how the team makes decisions. For example, if a team currently makes decisions by a majority vote, ask members to require consensus for the next two sprints. Do the opposite if they currently require consensus. These and other approaches for dampening or amplifying differences are shown in Table 12.2. 1/12/2010
1 p 233 This excellent book builds on ideas in Eoyang’s doctoral dissertation on self--organization and applies them specifically to organization change. It presents the model that organization change can be influenced through the containers, differences, and exchanges that are put in place or encouraged by change agents in the organization. This excellent book builds on ideas in Eoyang’s doctoral dissertation on self--organization and applies them specifically to organization change. It presents the model that organizational change can be influenced through the containers, differences, and exchanges that are put in place or encouraged by change agents in the organization. 1/13/2010
1 p 269 A good ScrumMaster will continually nudge a team toward adopting improved technical practices that help them learn how to overlap their work. A good ScrumMaster will continually nudge team members toward adopting improved technical practices that help them learn how to overlap their work. 1/13/2010
1 p 272 Even though a team’s designers (or architect or technical designers) may spend time looking ahead, they remain members of the team working on this sprint. Even though a team’s designers (or architects or technical designers) may spend time looking ahead, they remain members of the team working on this sprint. 1/13/2010
1 p 274 The work of this first sprint didn’t eliminate many architectural uncertainties, but it did start the team off with a successful first sprint. It also gave them the ability to easily get data into the system, which everyone involved knew would benefit them during subsequent sprints. The work of this first sprint didn’t eliminate many architectural uncertainties, but it did start the team off with a successful first sprint. It also gave it the ability to easily get data into the system, which everyone involved knew would benefit the team during subsequent sprints. 1/13/2010
1 p 286 In Chapter 13, “The Product Backlog.” we learned that the product backlog should be progressively refined. In Chapter 13, “The Product Backlog,” we learned that the product backlog should be progressively refined. 1/13/2010
1 p 303 My second answer is again to collect data so that you are prepared and can anticipate the impact of team size changes. To do this, have someone in the organization keep track of the percentage change in velocity for the first few sprints following any change in team size. You want to track the change for a couple of sprints following a team size-change because velocity almost always drops in the first sprint, even when team size goes up. This is the result of increased communication, productive team members taking time to get a new member productive, and so on. In my experience, the long-term impact of the change is apparent by the third sprint after the change. My second answer is again to collect data so that you are prepared and can anticipate the impact of team size changes. To do this, have someone in the organization keep track of the percentage change in velocity for the first few sprints following any change in team size. You want to track the change for a couple of sprints following a change of team size because velocity almost always drops in the first sprint, even when team size goes up. This is the result of increased communication, productive team members taking time to get a new member productive, and so on. In my experience, the long-term impact of the change is apparent by the third sprint after the change. 1/13/2010
1 p 316 Reduced the number of staff involved in their nine deployments of the application by 65% (to 15 people) Reduced the number of staff involved in its nine deployments of the application by 65% (to 15 people) 1/13/2010
1 p 316 These results are not unusual for an organization that automated testing seriously. Use them as starting goals for your own automation efforts. These results are not unusual for an organization that takes automated testing seriously. Use them as starting goals for your own automation efforts. 1/13/2010
1 p 321 Technical debt is often the result of a rushed implementation. This is not always bad. As Cunningham writes, “Shipping first time-code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite” (1992). Technical debt is often the result of a rushed implementation. This is not always bad. As Cunningham writes, “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite” (1992). 1/13/2010
1 p 323 An emphasis on quality can have dramatic results. Nine months after adopting Scrum and taking the steps recommended here, Steve Greene of Salesforce.com says that it had already achieved “over 300 person hours saved per major release, and hundreds more across the lifespan of all the patch releases. That is a lot of time we now spend on features, automation, design, basically all things good and productive” (2007). An emphasis on quality can have dramatic results. Nine months after adopting Scrum and taking the steps recommended here, Steve Greene of Salesforce.com says that his company had already achieved “over 300 person hours saved per major release, and hundreds more across the lifespan of all the patch releases. That is a lot of time we now spend on features, automation, design, basically all things good and productive” (2007). 1/13/2010
1 p 334 All-too-often a team finishes its sprint planning meeting only to discover it needs a small amount of work done by another team—the catch is that team is not available. All too often a team finishes its sprint planning meeting only to discover it needs a small amount of work done by another team but that team is not available. 1/13/2010
1 p 340 Everyone was very good at figuring out what needed to be done on their team. Everyone was very good at figuring out what needed to be done on his own team. 1/13/2010
1 p 350 Design for evolution. Acknowledge that each community will change over time. It will rise and fall in importance, members will come and go, goals will shift. This is good as it represents the progress of each community changing in response to changing project, people, and organizational needs. Design for evolution. Acknowledge that each community will change over time. It will rise and fall in importance, members will come and go, goals will shift. This is good as it represents the progress of each community adjusting in response to changing project, people, and organizational needs. 1/13/2010
1 p 353 This book is the authoritative source of information on communities of practice. Included is information of how to encourage them to form, how to lead them, how to measure the value they provide, and some of the downsides of using communities. This book is the authoritative source of information on communities of practice. Included is information on how to encourage them to form, how to lead them, how to measure the value they provide, and some of the downsides of using communities. 1/13/2010
1 p 356 FIGURE 18.1
Two different approaches to distributing a team between the United States and France.
FIGURE 18.1
Two different approaches to distributing teams between the United States and France.
1/13/2010
1 p 361 Finally, I notice a dramatic difference in long-term orientation (118 for China and 29 for the United States). From this difference, I’ll know that the regular visible progress demonstrated by sprint reviews will be a strong positive motivation for the U.S. team but might not have a similar effect on the team’s Chinese team members, who bring a much longer time horizon to the project. Finally, I notice a dramatic difference in long-term orientation (118 for China and 29 for the United States). From this difference, I’ll know that the regular visible progress demonstrated by sprint reviews will be a strong positive motivation for the U.S. team but might not have a similar effect on the team’s Chinese members, who bring a much longer time horizon to the project. 1/13/2010
1 p 367 All of the distributed teams I’ve worked with report benefits from getting together occasionally. How teams do this differs tremendously—some teams collocate entirely for the first few sprints, other teams plan occasional full-team get--togethers, although others rotate members between sites. Most use a combination of techniques. We will consider each in this section. All of the distributed teams I’ve worked with report benefits from getting together occasionally. How teams do this differs tremendously—some teams collocate entirely for the first few sprints, other teams plan occasional full-team get--togethers, others rotate members between sites. Most use a combination of techniques. We will consider each in this section. 1/13/2010
1 p 371 The ambassadors were able to communicate lessons learned as well as set future direction for the project” (2006, 322.) The ambassadors were able to communicate lessons learned as well as set future direction for the project” (2006, 322). 1/13/2010
1 p 374 During the next sprint planning meeting, discuss whether enough detail is provided with each product backlog item being planned into the new sprint. If not, either add more detail during that meeting or consider selecting different product backlog items and adding detail during the sprint. During the next sprint planning meeting, discuss whether enough detail is provided with each product backlog item being planned into the new sprint. If not, either add more detail during that meeting or consider adding detail to upcoming product backlog items during the sprint. 1/13/2010
1 p 375 When I was 10, I spent the summer with my grandmother who lived near New Orleans in the hot, sticky, southern part of the United States. Having grown up in southern California with its near-perfect weather, I complained (more than once, I’m sure) about how hot it was in New Orleans. My grandmother’s reply was always the same: “It’s not the heat; it’s the humidity.” Analogously, for a distributed team, it’s not the distance, it’s the time difference. When I was 10, I spent the summer with my grandmother who lived near New Orleans in the hot, sticky, southern part of the United States. Having grown up in southern California with its near-perfect weather, I complained (more than once, I’m sure) about how hot it was in New Orleans. My grandmother’s reply was always the same: “It’s not the heat, it’s the humidity.” Analogously, for a distributed team, it’s not the distance, it’s the time difference. 1/13/2010
1 p 381 Each of these approaches is described as the next two strategies for handling the daily scrum. Each of these approaches is described in the next two strategies for handling the daily scrum. 1/13/2010
1 p 382 I usually do not advocate this approach as a primary technique. It can be used to supplement daily calls if the team decides that a daily call is too much and needs to reduce their frequency. I usually do not advocate this approach as a primary technique. It can be used to supplement daily calls if the team decides that daily calls are too much and needs to reduce their frequency. 1/13/2010
1 p 390 Sliger describes a team that wrote a barely sufficient specification to approval for the project. Sliger describes a team that wrote a barely sufficient specification to gain approval for the project. 1/13/2010
1 p 390 Other times, waterfall-at-end occurs when there is an external group—operations for example—who require some testing to occur at the end. Other times, waterfall-at-end occurs when there is an external group—operations for example requires that some testing to occur at the end. 1/13/2010
1 p 392 Those areas with stable, well-known requirements can be built by the sequential teams; those areas with uncertain requirements or where multiple designs approaches are valid should be built by the Scrum teams. Those areas with stable, well-known requirements can be built by the sequential teams; those areas with uncertain requirements or where multiple design approaches are valid should be built by the Scrum teams. 1/13/2010
1 p 394 These checkpoints often wreak havoc on a software team’s desire to use Scrum as they are not suitable to work done in an incremental manner. These checkpoints often wreak havoc on a software team’s desire to use Scrum as they are not suitable to work done in an iterative manner. 1/13/2010
1 p 395 But in separating them we would like to achieve the ability to have high-level checkpoints to provide the necessary oversight, while still allowing the team the freedom of managing themselves and their project in an agile manner. But in separating them we would like to achieve the ability to have high-level checkpoints to provide the necessary oversight, while still allowing the team the freedom of managing itself and the project in an agile manner. 1/13/2010
1 p 398 Our auditor suggested we take photos of the whiteboard after every design discussion and to file these along with copies of any handwritten notes anyone had taken. We put a locking file cabinet in the team room and stored all design documentation there. Our auditor suggested we take photos of the whiteboard after every design discussion and file these along with copies of any handwritten notes anyone had taken. We put a locking file cabinet in the team room and stored all design documentation there. 1/13/2010
1 p 398 But that wasn’t good enough for our auditor, who insisted we included a failing test in every night’s build. We added But that wasn’t good enough for our auditor, who insisted we include a failing test in every night’s build. We added 1/13/2010
1 p 399 Although I don’t think any of these steps helped us produce better software, they did not add significant ongoing overhead. Documenting everything about our process took time, but that was one-time effort (with planned annual updates), and I bore the brunt of that for the team. Juan Gabardini, who has worked with Scrum in two ISO 9001-certified companies, concurs. Although I don’t think any of these steps helped us produce better software, they did not add significant ongoing overhead. Documenting everything about our process took time, but that was a one-time effort (with planned annual updates), and I bore the brunt of that for the team. Juan Gabardini, who has worked with Scrum in two ISO 9001-certified companies, concurs. 1/13/2010
1 p 410 As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me that at his team’s sprint review the week before, the team had decided to ask him to resign as their ScrumMaster and to leave the team. He had done so and was looking around within his company to find another Scrum team to join. But the shock of being asked to leave had not yet worn off. As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me that at his team’s sprint review the week before, the team members had decided to ask him to resign as their ScrumMaster and to leave the team. He had done so and was looking around within his company to find another Scrum team to join. But the shock of being asked to leave had not yet worn off. 1/13/2010
1 p 411 This attitude is prevalent at SAS, a privately owned software development company with over 4,000 employees. SAS has been in the top 20 of Fortune magazine’s Best Companies to Work For list every year the list has been published. An article in the Harvard Business Review describes the multivational culture at SAS. This attitude is prevalent at SAS, a privately owned software development company with over 4,000 employees. SAS has been in the top 20 of Fortune magazine’s Best Companies to Work For list every year the list has been published. An article in the Harvard Business Review describes the motivational culture at SAS. 1/13/2010
1 p 415 When doing this, be careful to have people sit with their Scrum development teams rather than with their functional teams. Avoid, for example, having all programmers in the company sit together in a different part of the building than testers. When doing this, be careful to have people sit with their Scrum development teams rather than with their functional teams. Avoid, for example, having all the programmers in the company sit together in a different part of the building than the testers. 1/13/2010
1 p 432 problem I’ve seen is teams who incorporate this survey into their sprint retrospective in place of the more open-ended discussion that should be part of a retrospective. problem I’ve seen is teams who incorporate this survey into their sprint retrospectives in place of the more open-ended discussion that should be part of a retrospective. 1/13/2010
1 p 435 You can also compare your team against its own data from a prior period, allowing you what improvements have been made since then. You can also compare your team against its own data from a prior period, showing you what improvements have been made since then. 1/13/2010
1 p 436 Because the CA approach assessess each characteristic individually, it is possible to see which of these characteristics is dragging down the organization’s overall quality score. Because the CA approach assesses each characteristic individually, it is possible to see which of these characteristics is dragging down the organization’s overall quality score. 1/13/2010
1 p 438 It’s well known that if we introduce a new metric and tell teams that they will be evaluated against that metric, they will alter their behavior to optimize that metric. Tell a team that they will be measured on the number of defects in the defect tracking system and that number will go down—perhaps because of good, honest improvements, but perhaps also because they will find ways to more informally communicate about some bugs, thereby bypassing the defect tracking system. Even if we could devise a metric that couldn’t be gamed, one number does not present a complete view. It’s well known that if we introduce a new metric and tell teams that they will be evaluated against that metric, they will alter their behavior to optimize that metric. Tell a team that it will be measured on the number of defects in the defect tracking system and that number will go down—perhaps because of good, honest improvements, but perhaps also because team members will find ways to more informally communicate about some bugs, thereby bypassing the defect tracking system. Even if we could devise a metric that couldn’t be gamed, one number does not present a complete view. 1/13/2010
1 p 448 Wait, you say, I have a final objection. Being agile isn’t my goal, delivering great products is. If I’m good enough, why can’t I stop? To that I say, of course, being agile is not your goal. Your primary goal is to develop amazing products, quickly and cheaply, that thrill your customers and users. To do that, though, I believe you will need to be agile. And to be agile, you must continuously improve. Wait, you say, I have a final objection. Being agile isn’t my goal, delivering great products is. If I’m good enough, why can’t I stop? To that I say, of course being agile is not your goal. Your primary goal is to develop amazing products, quickly and cheaply, that thrill your customers and users. To do that, though, I believe you will need to be agile. And to be agile, you must continuously improve. 1/13/2010