Better Software - July/August 2008 - (Page 28) “Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.” roast. Her grandmother tells her, “Because my roasting pan was too small. The roast wouldn’t fit any other way.” We capture this as our next guideline for failing with agile. guiDeline 16: Slavishly follow agile practices without understanding their underlying principles. If you haven’t been able to implement guidelines 14 through 16 and your agile project is succeeding despite your best efforts, you can bring even a successful project to a halt simply by changing nothing. What, you say? Change nothing? Follow the example of the StatusQ team. StatusQ, assigned to build a new Web-based reservation system, got off to a good start. Team members were new to agile but did a good level of research and sent a few of their people off to become certified ScrumMasters. The project quickly benefited from the new practices. In a month, StatusQ had a simple Web site up and running and was able to demonstrate a few key interfaces that gave its customers a lot of confidence that their vision of an accessible and powerful reservation system would work. StatusQ never held a retrospective at the end of each sprint. The ScrumMaster didn’t push for it because he didn’t see the need. Everything was already working wonderfully well. You can encourage this behavior on your own team by complaining loudly to your ScrumMaster and team members if they try to hold a retrospective. Tell them that it’s a waste of time to sit and talk about a project that’s going well. Tell them that retrospectives only make sense when things are going wrong. Over time, things at StatusQ started to slow down. The rate of change and the growing code base were creating maintenance problems. Changes to the system from the customers were supposed to be a benefit to them, but the code couldn’t keep up. Code stability became so bad that the project seemed to be moving backward. Finally company management stepped in, put a halt to the changes, and finished the contract at half price. This team had unknowingly demonstrated our next two guidelines for failing at agile. guiDeline 17: Don’t continually improve. guiDeline 18: Don’t change the technical practices. Company process issues that at first seem unrelated to the project can have a negative impact on morale and motivation. Consider the case of Dave, an up-and-coming artist who worked for a mobile phone game developer. He welcomed his company’s adoption of agile, as it made a lot of sense to him. The new agile teams consisted of programmers, artists, designers, and a number of other people from numerous disciplines. Everyone relied on each other to create iterations of their game. If the artists did a good job, then the entire team looked good. Dave often dropped what he was doing to help his teammates iterate on the art to improve the game. This often came at the expense of his own work, but, for Dave, team goals came first. Dave’s team did a great job and produced a hit title that sold many thousands of copies and earned the company substantial profits. At the end of the year, Dave had his first performance review with the company’s lead artist. Dave was shocked to learn that his yearly bonus was small. Dave was told that he was judged by the senior artist in the company to have missed his art production goals. As it turns out, the senior artist was counting the number of iteration task cards that Dave completed and based his judgment on that rather than on the real amount of work Dave completed. Chagrined, Dave returned to his team vowing to make sure his task cards took priority over the needs of the team. Guideline 19 can be your backup plan for any enthusiastic agilists in your company. guiDeline 19: Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility. A tenet shared by all agile processes is that work is prioritized based on the value provided by each feature. Other factors, such as risk and knowledge creation, are considered, but the amount of value delivered remains the dominant factor. A sure way to fail with agile is to ignore this tenet and instead follow guideline 20. guiDeline 20: Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter. There are, of course, other ways to fail in addition to those collected here. In your effort to undermine a successful agile project, you may have already discovered some on your own. Of course, you are probably keeping quiet about them because it’s critical that the sabotage not be detected until the bridge is blown. We are confident that, through diligent application of the guidelines here or those that only you know—or both— you will be able to plot the downfall of your next agile project. {end} 28 BETTER SOFTWARE JULY/AUGUST 2008 www.StickyMinds.com 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.