Better Software - July/August 2008 - (Page 27) “as you can see, failure at the product owner level is easily achieved through miscommunication, general ignorance of the team’s progress, and lack of education. “ senior management caused the project to lose six months of progress. Well done, Kathy! Kathy demonstrated several guidelines for how an agile project can fail at the hands of a product owner. guiDeline 10: Don’t communicate a vision for the product to the team or to the other stakeholders. guiDeline 11: Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress. guiDeline 12: Replace a plan document with a plan “in your head” that only you know. One of the tenets of iterative development is the discovery of the value of features being added as part of the whole. This is the reason that every iteration produces a potentially shippable release of the product. This is in stark contrast to plan-driven projects, which attempt to predict the utilization of resources so the product emerges complete from all the separate parts only at the end. When a product owner does not make that change, the team can quickly fail. It is just as critical to educate the product owner as it is to educate the team. Generally speaking, if you want to fail quickly, avoid training at all. The crucial role of product owner often is balanced by someone else who acts as the team’s ScrumMaster or coach. On many successful projects, a certain amount of naturally occurring tension exists between product owner and ScrumMaster. A product owner always desires more, more, more features. The coach, by contrast, is responsible for monitoring the health of the team. If the team is being pushed too hard and is beginning to get sloppy due to fatigue, the coach pushes back against the product owner’s desires for more. A good way to fail at agile is to eliminate this push-pull tension between the coach and product owner by following guideline 13. guiDeline 13: Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team. As you can see, failure at the product owner level is easily achieved through miscommunication, general ignorance of the team’s progress, and lack of education. You can compound that, if necessary, by having one person act in roles that are designed to balance each other. Following these guidelines to the letter is a great way to fail. code, and since all new code would be fresh in everyone’s minds there would be little chance of accidentally breaking it. However, Jon and his coworkers did embrace refactoring and collective code ownership. Their new rule was that any programmer could change the code of any other programmer at any time. They soon learned that refactoring and collective code ownership can be very dangerous without the safety net of automated unit tests to make sure you aren’t breaking things while improving them. Jon and his team had unwittingly stumbled on these two guidelines for causing a team to fail at agile. guiDeline 14: Start customizing an agile process before you’ve done it by the book. guiDeline 15: Drop and customize important agile practices before fully understanding them. An alternative to these guidelines is to dive into the practices without understanding why you’re doing them. As coaches, we encounter many teams who have learned a technique or been told to do something by someone and who then continued to do it even when they’d outgrown the technique (a subtle, yet effective, subterfuge). This brings to mind the story of the newlywed wife who cuts a quarter inch off both ends of every roast she cooks. When her husband asks why she’s trimming the roast that way, she has no ready answer; she does it that way because it’s the way her mother always did it. Curious as to her mother’s rationale, the wife calls her mother and asks why she taught her to cut the ends of the roast. Her mother says she only does it that way because her own mother taught her to do so. The young wife next calls her grandmother and asks why she cut a quarter inch off the end of every BETTER SOFTWARE Process Issues If all else succeeds, careful misapplication of process issues can bring down almost any agile project. Jon is a terrific example of a process nightmare, and he did most of his best sabotage without even knowing he was doing it. Jon was the lead developer for a Chicago-based team developing software designed to approve or reject loan applications. In addition to being the lead developer, he was also the ScrumMaster (note how he began by embracing guideline 13, which by itself can wreak havoc). Jon and his team were new to agile and were anxious to get rid of its unneeded parts. They immediately dispensed with daily standup meetings, reasoning that since the team sat in the same general area, most conversations could be heard over the six-foot-high cubicle walls. They also decided that having automated unit tests was unnecessary. Since theirs was a new application, there was no chance of breaking old www.StickyMinds.com JULY/AUGUST 2008 27 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.