Better Software - July/August 2008 - (Page 26) pursue that goal and provided with ongoing guidance from a product owner, an agile team can become truly high performing. Don’t give your team that opportunity! If micromanagement isn’t your style, follow guideline 3. guiDeline 3: Equate self-managing with self-leading and provide no direction to the team whatsoever. While support for using agile may come from the highest levels of a company, often the adoption of agile will be driven by the team itself. Don’t worry. You still have plenty of opportunities to create failure in those cases, especially if you are the manager. You may want to start by undermining the evangelist on the team—the one who has read all the books and is taking the chance to promote agile. Brush off the rules he is asking you to follow. Interrupt the daily scrum with new directions. Change the priority of the iteration goals. It works well and is encapsulated in guideline 4. guiDeline 4: Ignore the agile practices. They don’t apply to management. If you want to be sure that agile doesn’t take root, go straight to the team members themselves and let them know you think agile is a fad. Some of them will be skeptical to begin with, so it won’t take much to convince them to ignore the practices. Remember, like Barney Fife, you have the power to nip this thing in the bud. Just follow guideline 5. guiDeline 5: Undermine the team’s belief in agile. Team Issues Not all of us are managers. Don’t worry, non-managers can wreak havoc at the team level, as well. Just take the case of the NotQuite team, tasked with developing inventory-management software. This team shows the power of consistency in bringing down an agile project. For its first iteration, NotQuite committed to completing six items from the product backlog; it finished four. Because it was the first iteration and most teams overcommit in their first iteration, the product owner cut the team a little slack. This didn’t faze the NotQuite team. For the second iteration the team again planned to finish six items; it finished five. The slight improvement only 26 BETTER SOFTWARE JULY/AUGUST 2008 lulled the product owner into a false sense of security. NotQuite continued to chronically overcommit, falling short in the third, fourth, and fifth iterations. Soon, the product owner learned not to trust the team, and this undermined any success it may have had with agile—a fantastic implementation of guideline 6. guiDeline 6: Continually fail to deliver what you committed to deliver during iteration planning. When falling short, don’t make the mistake of going all-out on every iteration, reaching the last day panting with exhaustion time after time. A team like that could almost be forgiven for never quite delivering what it planned. A key to NotQuite’s failure was its cavalier attitude toward missed commitments. Team members made it clear that it really didn’t matter if something was finished on the last day of the iteration (as had been committed) or a few days into the next iteration. What’s a few days between friends? Remember, a few days here and there can add up to quite a lot. If a team continually misses its commitments, it makes it impossible for the product owner to make plans and external commitments. This leads to guideline 7 for how to fail at agile. guiDeline 7: Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered. Perhaps the best way to cause an agile project to fail is to follow guideline 8. guiDeline 8: Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on. Merrilynn was able to use this guideline to kill her company’s pilot agile project. Her organization was developing an application that would have separate Windows and Web-based clients. As a development director, Merrilynn had control over team composition and was able to create three separate teams: a Windows team, a Web team, and a test team. This team structure worked against the goals of agile. If Merrilynn had wanted to succeed, she would have instead created three teams that each included Windows, Web, and test skills. Because Merrilynn kept the teams separate, she made it impossible for any www.StickyMinds.com team to deliver the working software that an agile team is expected to deliver at the end of each iteration. Nicely done, Merrilynn. Another option open to Merrilynn was putting all twenty of her people on one team. This would have violated the standard agile advice of creating teams of five to nine people. She could have justified it to anyone who questioned the decision by stressing the unique twoclient nature of her team’s product. If she had chosen to create one large team instead of three reasonably sized teams, Merrilynn would have substantially increased the communication overhead of her team. This would have slowed progress and created complaints about how all the conversations in agile were a tremendous burden. If separating teams is too hard to justify, you can bog down a project very easily by following guideline 9. guiDeline 9: Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup. Product Owner Issues If the management and team guidelines aren’t available to you, there is another route to take: Consider a takedown from the product owner angle. A product owner has many options at her disposal to bring an agile project to its knees. Take Kathy, for example, who was the product owner for a team working on a video game. The team was making great progress on features with every iteration and showing more player “fun” every time. Kathy let team members keep thinking that this was all they needed to do. She never attended reviews, rarely tried the game, and requested stories that were meant to steer the game toward the product she imagined. If that weren’t enough, Kathy didn’t share her own vision with the team or the other customers to whom she reported (such as marketing). A year into development, the game was demonstrated to a group of executives who were shocked at the direction the game had taken. It was not what they wanted to market. The disconnect between Kathy, the team, and http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.