This document provides guidelines for sabotaging an agile project in order to ensure its failure. It describes examples of individuals who successfully caused agile adoptions to fail by micromanaging the team, undermining belief in agile practices, failing to deliver committed work, separating teams by function, and miscommunicating or ignoring the product vision. The guidelines are organized into categories for management, teams, product owners, and processes, and emphasize lack of trust, blame of agile processes, poor direction and oversight, and premature customization of practices.

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