Your SlideShare is downloading. ×
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
How To Fail With Agile
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How To Fail With Agile

1,163

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,163
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
41
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. JULY/AUGUST 2008 www.StickyMinds.com 24 BETTER SOFTWARE
  • 2. A gile processes are now ac- Since Drew didn’t trust agile or his cepted as valid alternatives to team’s ability, he attended every daily traditional software develop- scrum, paying close attention and ment processes. Most people pointing out what the team was doing who adopt agile do so to realize the right and what it was doing wrong. Soon benefits of faster delivery, higher quality, the daily meetings became a model of products that more closely match user brevity and procedural correctness. As needs, and so on. a bonus, no one spoke up about prob- Not everyone is so enamored of lems—especially in front of Drew. Drew agile. Some teams and individuals balk had successfully followed our first guide- when a mandate to “become agile” is line to agile failure. GUIDELINE 1: Don’t trust the team or agile. passed down from some “higher-up” in Micromanage both your team members and the organization or when some young the process. go-getter decides to start an idealistic grassroots movement to effect change. To no one’s surprise, the team did A switch to agile often conflicts with not produce impressive results. It didn’t personal goals such as maintaining the meet all of its iteration goals and was no status quo, avoiding career risk, working more productive than it had been before. no harder than necessary, or maintaining Drew conducted retrospectives that did a large fiefdom of direct reports. It is to not reveal any problems that he could these individuals—those who have to fix. As a result, Drew threw away all the become agile but don’t want to—that we books he had read and directed the team would like to direct our advice. Don’t to return to the old way of developing worry. We’re not going to try to seduce the project. Drew was following guide- you into trying agile, convince you of its line 2. GUIDELINE 2: If agile isn’t a silver bullet, merits, or tell you how to succeed. No, blame agile. we’re going to help you fail with agile. Then you’ll be done with it and can go While Drew went to one extreme by back to your comfort zone. micromanaging his team, it is equally Although there are many ways to effective to go to the opposite extreme sabotage your agile project, for conve- and not provide any guidance at all. nience we have grouped them into four Remember: While self-organizing agile categories: management issues, team is- teams are also self-managing, they are sues, product owner issues, and process not self-leading. An agile team needs issues. In each instance, we will cite an the type of leadership that provides a example of someone who successfully vision to work toward and motivation caused an agile adoption to fail, list the for achieving that vision. A strong agile general guidelines for failure that the leader, often in the form of a product example is meant to demonstrate, and owner, knows how to motivate a team then list alternative techniques you can with a description of an extremely de- try to help you replicate the process. We sirable product that is just beyond what hope this approach will allow you to fail the team may think it can do. Freed to quickly and avoid potential success. pursue that goal and provided with on- going guidance from a product owner, Management Issues an agile team can become truly high Drew had seen management fads performing. Don’t give your team that come and go. In his mind, agile was opportunity! If micromanagement isn’t no different. A quick learner, he read a your style, follow guideline 3. GUIDELINE 3: Equate self-managing with number of books and even took a class self-leading and provide no direction to the on agile. He didn’t trust it, but, as a team whatsoever. team player, it was his obligation to give it a try. While support for using agile may Drew picked team members and told come from the highest levels of a com- them to “be agile.” He told them that pany, often the adoption of agile will be they would need to meet daily, estimate driven by the team itself. Don’t worry. their work, and produce versions of their You still have plenty of opportunities to product (a database tool for storing art- create failure in those cases, especially work) every month. if you are the manager. You may want www.StickyMinds.com JULY/AUGUST 2008 25 BETTER SOFTWARE
  • 3. of her team. This would have slowed quite delivering what it planned. A key to start by undermining the evangelist progress and created complaints about to NotQuite’s failure was its cavalier on the team—the one who has read all how all the conversations in agile were a attitude toward missed commitments. the books and is taking the chance to tremendous burden. If separating teams Team members made it clear that it re- promote agile. Brush off the rules he is is too hard to justify, you can bog down ally didn’t matter if something was fin- asking you to follow. Interrupt the daily a project very easily by following guide- ished on the last day of the iteration (as scrum with new directions. Change the line 9. had been committed) or a few days into priority of the iteration goals. It works GUIDELINE 9: Large projects need large the next iteration. What’s a few days be- well and is encapsulated in guideline 4. GUIDELINE 4: Ignore the agile practices. teams. Ignore studies that show produc- tween friends? Remember, a few days They don’t apply to management. tivity decreases with large teams due to here and there can add up to quite a increased communication overhead. Since lot. If a team continually misses its com- If you want to be sure that agile everyone needs to know everything, invite mitments, it makes it impossible for the doesn’t take root, go straight to the all fifty people to the daily standup. product owner to make plans and ex- team members themselves and let them ternal commitments. This leads to guide- know you think agile is a fad. Some of Product Owner Issues line 7 for how to fail at agile. them will be skeptical to begin with, so GUIDELINE 7: Cavalierly move work for- it won’t take much to convince them If the management and team guide- ward from one iteration to the next. It’s to ignore the practices. Remember, like lines aren’t available to you, there is good to keep the product owner guessing Barney Fife, you have the power to nip another route to take: Consider a take- about what will be delivered. this thing in the bud. Just follow guide- down from the product owner angle. line 5. Perhaps the best way to cause an agile A product owner has many options at GUIDELINE 5: Undermine the team’s belief project to fail is to follow guideline 8. her disposal to bring an agile project GUIDELINE 8: Do not create cross-func- in agile. to its knees. Take Kathy, for example, tional teams. Put all the testers on one who was the product owner for a team Team Issues team, all the programmers on another, and working on a video game. The team was so on. making great progress on features with Not all of us are managers. Don’t Merrilynn was able to use this guide- every iteration and showing more player worry, non-managers can wreak havoc line to kill her company’s pilot agile “fun” every time. Kathy let team mem- at the team level, as well. Just take the project. Her organization was devel- bers keep thinking that this was all they case of the NotQuite team, tasked with oping an application that would have needed to do. She never attended reviews, developing inventory-management soft- separate Windows and Web-based cli- rarely tried the game, and requested sto- ware. This team shows the power of ents. As a development director, Merri- ries that were meant to steer the game consistency in bringing down an agile lynn had control over team composition toward the product she imagined. If that project. For its first iteration, NotQuite and was able to create three separate weren’t enough, Kathy didn’t share her committed to completing six items from teams: a Windows team, a Web team, own vision with the team or the other the product backlog; it finished four. Be- and a test team. This team structure customers to whom she reported (such cause it was the first iteration and most worked against the goals of agile. If Mer- as marketing). A year into development, teams overcommit in their first iteration, rilynn had wanted to succeed, she would the game was demonstrated to a group the product owner cut the team a little have instead created three teams that of executives who were shocked at the slack. This didn’t faze the NotQuite each included Windows, Web, and test direction the game had taken. It was not team. For the second iteration the team skills. Because Merrilynn kept the teams what they wanted to market. The dis- again planned to finish six items; it fin- separate, she made it impossible for any connect between Kathy, the team, and ished five. The slight improvement only team to deliver the working software senior management caused the project to lulled the product owner into a false that an agile team is expected to deliver lose six months of progress. Well done, sense of security. NotQuite continued at the end of each iteration. Nicely done, Kathy! to chronically overcommit, falling short Merrilynn. Kathy demonstrated several guide- in the third, fourth, and fifth iterations. Another option open to Merrilynn lines for how an agile project can fail at Soon, the product owner learned not to was putting all twenty of her people on the hands of a product owner. trust the team, and this undermined any GUIDELINE 10: Don’t communicate a vi- one team. This would have violated the success it may have had with agile—a sion for the product to the team or to the standard agile advice of creating teams fantastic implementation of guideline 6. GUIDELINE 6: Continually fail to deliver other stakeholders. of five to nine people. She could have GUIDELINE 11: Don’t pay attention to the what you committed to deliver during itera- justified it to anyone who questioned tion planning. progress of each iteration and objectively the decision by stressing the unique two- evaluate the value of that progress. client nature of her team’s product. If When falling short, don’t make the GUIDELINE 12: Replace a plan document she had chosen to create one large team mistake of going all-out on every itera- with a plan “in your head” that only you instead of three reasonably sized teams, tion, reaching the last day panting with know. Merrilynn would have substantially in- exhaustion time after time. A team like creased the communication overhead that could almost be forgiven for never One of the tenets of iterative develop- JULY/AUGUST 2008 www.StickyMinds.com 26 BETTER SOFTWARE
  • 4. “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. “ GUIDELINE 14: Start customizing an agile Following these guidelines to the letter ment is the discovery of the value of fea- is a great way to fail. tures being added as part of the whole. process before you’ve done it by the book. GUIDELINE 15: Drop and customize im- This is the reason that every iteration Process Issues produces a potentially shippable release portant agile practices before fully under- of the product. This is in stark contrast If all else succeeds, careful misappli- standing them. to plan-driven projects, which attempt cation of process issues can bring down An alternative to these guidelines is to predict the utilization of resources almost any agile project. Jon is a terrific to dive into the practices without un- so the product emerges complete from example of a process nightmare, and he derstanding why you’re doing them. As all the separate parts only at the end. did most of his best sabotage without coaches, we encounter many teams who When a product owner does not make even knowing he was doing it. Jon was have learned a technique or been told to that change, the team can quickly fail. It the lead developer for a Chicago-based do something by someone and who then is just as critical to educate the product team developing software designed to continued to do it even when they’d out- owner as it is to educate the team. Gener- approve or reject loan applications. In grown the technique (a subtle, yet effec- ally speaking, if you want to fail quickly, addition to being the lead developer, he tive, subterfuge). This brings to mind the avoid training at all. was also the ScrumMaster (note how he story of the newlywed wife who cuts a The crucial role of product owner began by embracing guideline 13, which quarter inch off both ends of every roast often is balanced by someone else who by itself can wreak havoc). Jon and his she cooks. When her husband asks why acts as the team’s ScrumMaster or team were new to agile and were anx- she’s trimming the roast that way, she coach. On many successful projects, a ious to get rid of its unneeded parts. has no ready answer; she does it that certain amount of naturally occurring They immediately dispensed with daily way because it’s the way her mother al- tension exists between product owner standup meetings, reasoning that since ways did it. Curious as to her mother’s and ScrumMaster. A product owner al- the team sat in the same general area, rationale, the wife calls her mother and ways desires more, more, more features. most conversations could be heard over asks why she taught her to cut the ends The coach, by contrast, is responsible for the six-foot-high cubicle walls. of the roast. Her mother says she only monitoring the health of the team. If the They also decided that having auto- does it that way because her own mother team is being pushed too hard and is be- mated unit tests was unnecessary. Since taught her to do so. The young wife next ginning to get sloppy due to fatigue, the theirs was a new application, there was calls her grandmother and asks why she coach pushes back against the product no chance of breaking old code, and cut a quarter inch off the end of every owner’s desires for more. A good way to since all new code would be fresh in roast. Her grandmother tells her, “Be- fail at agile is to eliminate this push-pull everyone’s minds there would be little cause my roasting pan was too small. tension between the coach and product chance of accidentally breaking it. The roast wouldn’t fit any other way.” owner by following guideline 13. However, Jon and his coworkers did We capture this as our next guideline for GUIDELINE 13: Have one person share embrace refactoring and collective code failing with agile. the roles of ScrumMaster (agile coach) and GUIDELINE 16: Slavishly follow agile ownership. Their new rule was that product owner. In fact, have this person any programmer could change the code practices without understanding their un- also be an individual contributor on the of any other programmer at any time. derlying principles. team. They soon learned that refactoring and If you haven’t been able to implement collective code ownership can be very As you can see, failure at the product guidelines 14 through 16 and your agile dangerous without the safety net of owner level is easily achieved through project is succeeding despite your best automated unit tests to make sure you miscommunication, general ignorance of efforts, you can bring even a successful aren’t breaking things while improving the team’s progress, and lack of educa- project to a halt simply by changing them. Jon and his team had unwittingly tion. You can compound that, if neces- nothing. What, you say? Change stumbled on these two guidelines for sary, by having one person act in roles nothing? Follow the example of the Sta- causing a team to fail at agile. that are designed to balance each other. tusQ team. StatusQ, assigned to build a www.StickyMinds.com JULY/AUGUST 2008 27 BETTER SOFTWARE
  • 5. “Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.” new Web-based reservation system, got a negative impact on morale and moti- value provided by each feature. Other off to a good start. Team members were vation. Consider the case of Dave, an factors, such as risk and knowledge cre- new to agile but did a good level of re- up-and-coming artist who worked for a ation, are considered, but the amount of search and sent a few of their people off mobile phone game developer. He wel- value delivered remains the dominant to become certified ScrumMasters. comed his company’s adoption of agile, factor. A sure way to fail with agile is The project quickly benefited from as it made a lot of sense to him. The to ignore this tenet and instead follow the new practices. In a month, StatusQ new agile teams consisted of program- guideline 20. GUIDELINE 20: Convince yourself that had a simple Web site up and running mers, artists, designers, and a number of you’ll be able to do all requested work, so and was able to demonstrate a few key other people from numerous disciplines. the order of your work doesn’t matter. interfaces that gave its customers a lot Everyone relied on each other to create of confidence that their vision of an ac- iterations of their game. If the artists did There are, of course, other ways to cessible and powerful reservation system a good job, then the entire team looked fail in addition to those collected here. would work. good. Dave often dropped what he was In your effort to undermine a successful StatusQ never held a retrospective at doing to help his teammates iterate on agile project, you may have already dis- the end of each sprint. The ScrumMaster the art to improve the game. This often covered some on your own. Of course, didn’t push for it because he didn’t came at the expense of his own work, you are probably keeping quiet about see the need. Everything was already but, for Dave, team goals came first. them because it’s critical that the sabo- working wonderfully well. You can en- Dave’s team did a great job and pro- tage not be detected until the bridge is courage this behavior on your own team duced a hit title that sold many thou- blown. We are confident that, through by complaining loudly to your Scrum- sands of copies and earned the company diligent application of the guidelines here Master and team members if they try to substantial profits. or those that only you know—or both— hold a retrospective. Tell them that it’s At the end of the year, Dave had his you will be able to plot the downfall of a waste of time to sit and talk about a first performance review with the com- your next agile project. {end} project that’s going well. Tell them that pany’s lead artist. Dave was shocked to retrospectives only make sense when learn that his yearly bonus was small. things are going wrong. Dave was told that he was judged by Over time, things at StatusQ started the senior artist in the company to have to slow down. The rate of change and missed his art production goals. As it the growing code base were creating turns out, the senior artist was counting maintenance problems. Changes to the the number of iteration task cards that system from the customers were sup- Dave completed and based his judgment posed to be a benefit to them, but the on that rather than on the real amount code couldn’t keep up. Code stability be- of work Dave completed. came so bad that the project seemed to Chagrined, Dave returned to his be moving backward. Finally company team vowing to make sure his task cards management stepped in, put a halt to the took priority over the needs of the team. changes, and finished the contract at half Guideline 19 can be your backup plan price. for any enthusiastic agilists in your com- This team had unknowingly dem- pany. GUIDELINE 19: Rather than align pay, in- onstrated our next two guidelines for centives, job titles, promotions, and recog- failing at agile. GUIDELINE 17: Don’t continually improve. nition with agile, create incentives for indi- GUIDELINE 18: Don’t change the tech- viduals to undermine teamwork and shared nical practices. responsibility. Company process issues that at first A tenet shared by all agile processes seem unrelated to the project can have is that work is prioritized based on the JULY/AUGUST 2008 www.StickyMinds.com 28 BETTER SOFTWARE

×