Better Software - July/August 2008 - (Page 25) A gile processes are now accepted as valid alternatives to traditional software development processes. Most people who adopt agile do so to realize the benefits of faster delivery, higher quality, products that more closely match user needs, and so on. Not everyone is so enamored of agile. Some teams and individuals balk when a mandate to “become agile” is passed down from some “higher-up” in the organization or when some young go-getter decides to start an idealistic grassroots movement to effect change. A switch to agile often conflicts with personal goals such as maintaining the status quo, avoiding career risk, working no harder than necessary, or maintaining a large fiefdom of direct reports. It is to these individuals—those who have to become agile but don’t want to—that we would like to direct our advice. Don’t worry. We’re not going to try to seduce you into trying agile, convince you of its merits, or tell you how to succeed. No, we’re going to help you fail with agile. Then you’ll be done with it and can go back to your comfort zone. Although there are many ways to sabotage your agile project, for convenience we have grouped them into four categories: management issues, team issues, product owner issues, and process issues. In each instance, we will cite an example of someone who successfully caused an agile adoption to fail, list the general guidelines for failure that the example is meant to demonstrate, and then list alternative techniques you can try to help you replicate the process. We hope this approach will allow you to fail quickly and avoid potential success. Management Issues Drew had seen management fads come and go. In his mind, agile was no different. A quick learner, he read a number of books and even took a class on agile. He didn’t trust it, but, as a team player, it was his obligation to give it a try. Drew picked team members and told them to “be agile.” He told them that they would need to meet daily, estimate their work, and produce versions of their product (a database tool for storing artwork) every month. Since Drew didn’t trust agile or his team’s ability, he attended every daily scrum, paying close attention and pointing out what the team was doing right and what it was doing wrong. Soon the daily meetings became a model of brevity and procedural correctness. As a bonus, no one spoke up about problems—especially in front of Drew. Drew had successfully followed our first guideline to agile failure. guiDeline 1: Don’t trust the team or agile. Micromanage both your team members and the process. To no one’s surprise, the team did not produce impressive results. It didn’t meet all of its iteration goals and was no more productive than it had been before. Drew conducted retrospectives that did not reveal any problems that he could fix. As a result, Drew threw away all the books he had read and directed the team to return to the old way of developing the project. Drew was following guideline 2. guiDeline 2: If agile isn’t a silver bullet, blame agile. While Drew went to one extreme by micromanaging his team, it is equally effective to go to the opposite extreme and not provide any guidance at all. Remember: While self-organizing agile teams are also self-managing, they are not self-leading. An agile team needs the type of leadership that provides a vision to work toward and motivation for achieving that vision. A strong agile leader, often in the form of a product owner, knows how to motivate a team with a description of an extremely desirable product that is just beyond what the team may think it can do. Freed to www.StickyMinds.com JULY/AUGUST 2008 BETTER SOFTWARE 25 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.