Section 3.6. Common Pitfalls of Phase 1
3.6. Common Pitfalls of Phase 1There are three common mistakes that teams make during this first phase:
3.6.1. Scheduling ComponentsThe biggest challenge in Phase 1 is learning to schedule functionality instead of components. One company making this transition selected functionality for each iteration but continued to schedule individuals by the components they were to produce or modify. The project was a subsequent release of an existing product, and their team had roughly 30 engineers who were divided into sub-teams matching the architecture of the system. As a result of that organization, the engineers had "specialties" and knew very little about the other portions of the system. Therefore, management thought that they had no choice but to divide the functionality into tasks for each sub-team. This meant that although the team was supposed to be delivering functionality, the individual engineers were still delivering components. One of the important effects of scheduling functionality is that it connects every engineer with the customer. That makes the feedback that the team receives at the end of the iteration relevant to every engineer. Also, each engineer becomes aware of how his efforts and challenges affect the team's ability to meet the iteration's goals. In this situation, because the engineers were assigned to work on components, they never connected with the customer and did not see specifically how their activities affected the team's ability to meet its goals. What alternatives could this team have used? The first thing to notice is that not all team members were involved in dividing functionality into tasks; the team leaders created the list of tasks that would be needed to deliver the functionality. This essentially shielded the team from the customer. Scrum advocates letting the team determine how the work will be accomplished. In this case, that means that the iteration's goals are given to the team, and all 30 engineers work together to figure out how they will accomplish those goals. The size of the team made holding a single planning session that included everyone inefficient. Another alternative would have been to assign pieces of functionality to new cross-functional sub-teams. Each sub-team would have engineers who specialized in each portion of the system, and each sub-team would be given a subset of the team's iteration goals. From that point, each sub-team would be allowed to self-organize to accomplish its task. It is highly likely that the sub-teams would divide the functionality into tasks matching the architecture and the engineers' specialties. At this point, they would be scheduling components, but there is a significant difference: each engineer would see how his tasks fit into producing the customer's functionality goals. That would connect them with the customer. Also, because these smaller teams would be cross functional, and because they would be designing solutions that affect the entire system, it is likely that the knowledge about the different parts of the system would be shared, and they would become more facile with parts of the system outside of their specialties. Over time, their need to divide functionality into components would decline, and they would learn to stay focused on the customer functionality in the iteration goals. The bottom line is that we want every engineer to be directly connected to the customer and the goals of the iteration. By scheduling only functionality and letting the engineers divvy up the work from there, even if the engineers end up working on individual components, it will keep the customer focus and connection that agility requires. 3.6.2. Making the Iteration Length Too LongOne team started this transition by selecting three-week iterations. They selected that length because they thought that would let them deliver enough functionality to impress their customer. They tried this for two iterations without success. In both cases, they made optimistic estimates (to try to increase how much they could promise their customer), overbooked their engineers (thinking that everyone codes for 40 hours a week), and overlooked some critical overhead in their process (their configuration management system required some serious hand holding to actually deliver the product). After two iterations that didn't meet their goals, they knew they had to change something. Unfortunately, they decided that they had made too big a leap and changed the length of their iterations to five weeks. The point that they missed was that those first two iterations had given them excellent feedback. If they had looked into the sources of their problems, they could have made changes to their process that would have increased their odds of success in the future. Instead, they fell back into their old ways by making the iterations longer. The sad side effect of this change was that they made the iterations long enough that they could never complete one without replanning. Inevitably, before the five weeks were up, the customer would want something new, and they would replan. From that point, every time they missed a delivery (which was every iteration), they blamed it on changing requirements from the customer and therefore never really made much progress on improving their process. The lesson here is that failing to meet the goals of an iteration is an opportunity for improvement. Look carefully at how the goals were set and what happened within the team during the iteration to find the sources of the problems. That's the best way to improve your ability to meet the goals of future iterations. 3.6.3. Not Closing the IterationA startup company that had grown from two to six engineers used this philosophy to transition from an ad hoc process to something with more structure that would not damage their ability to deliver functionality quickly. Initially, the team seemed to take to agile planning quite easily. They generated a set of story cards containing pieces of visible functionality and estimated and prioritized them. They even picked a set of cards for their first iteration. However, in that first planning meeting, there were clues foreshadowing the problems they were going to have. One of the key engineers was going on vacation, so instead of two weeks, they decided to make the iteration last three weeks. At three weeks, one of the lead engineers was saying, "We're going to close the iteration soon. The wife of one of the guys is having a baby, so we're waiting for him to get back." At four weeks, he was still saying that they were going to do it soon. At this point, they were well past developing the functionality that was to be scheduled into the first iteration and were just picking the next card off of the prioritized list to keep working. They had made one significant changethey were scheduling by customer-visible functionality. However, they were definitely not working in fixed-length iterations. Instead, their plan had essentially degraded into an (almost endless) to-do list! They had not met the goals of the first phase of the transitiona problem they eventually repaired. Let's think about what this team lost by not closing out one iteration and starting another: feedback! Closing out one iteration is a time for two very important kinds of feedback. First, we get feedback from the customer about the functionality we have delivered. All engineers get to see the customer's reaction to the functionality they produced, so they will understand the motivations for the functionality selected for the next iteration. Second, we get feedback on the process. Closing out the iteration is a time for the team to stop and think about how things went and what they would like to do differently in the next iteration. Remember Herbie and the Boy Scouts in the woods. Closing out the iteration creates a clearing along the path where we rethink our progress and prepare for the next section of the path. Team introspection is a critical part of improving our agility (and quality and happiness and...). Although closing an iteration is important, starting a new one is also important. Letting the customer select the functionality for the next iteration gives everyone an opportunity to revisit that prioritized wish list of functionality. During that review, it is likely that things will get reprioritized, reestimated, deleted, or added. So starting the iteration gives us a chance to ensure that we are working on the most valuable functionality possible. There is another benefit of closing out one iteration and starting another: rhythm! One of the things that makes agile teams efficient is that their life has a repeating rhythm to it. They learn how much functionality they can produce in that fixed amount of time and where they should be at various points within the iteration. They learn to foresee problems early and develop strategies for adjusting. Finally, perhaps the most important benefit of closing iterations is to give the team a sense of accomplishmenta milestone of achievement to propel them along. Instead of working on an endless to-do list, the team has achieved the goals of this iteration and is prepared to embark on the next one. This team's problem is rooted in the fact that they are a startup. They often work strange hours and are under pressure to produce some income, so they see anything that takes them away from their computers as detrimental to their productivity. Although they say they believe, the bottom line is that they did not yet see that the time spent closing one iteration and starting another would be recovered by the improvements that result from those activities. |
