Twenty Tips to Help You Avoid Success

The agile process is 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 ensure agile failure. 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 agile failure, 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 pursue that goal and provided with ongoing guidance from a product owner, an agile team can become truly high performing. Don’t give your team that opportunity! If micromanagement isn’t your style, follow guideline 3.

GUIDELINE 3: Equate self-managing with self-leading and provide no direction to the team whatsoever.
While support for using agile may come from the highest levels of a company, often the adoption of agile will be driven by the agile team itself. Don’t worry. You still have plenty of opportunities to create failure in those cases, especially if you are the manager. You may want to start by undermining the evangelist on the team—the one who has read all the agile books and is taking the chance to promote agile. Brush off the rules he is asking you to follow. Interrupt the daily scrum with new directions. Change the priority of the iteration goals. It works well and is encapsulated in guideline 4.

GUIDELINE 4:Ignore the agile practices.
They don’t apply to management. If you want to be sure that agile doesn’t take root, go straight to the agile team members themselves and let them know you think agile is a fad. Some of them will be skeptical to begin with, so it won’t take much to convince them to ignore the practices. Remember, like Barney Fife, you have the power to nip this thing in the bud. Just follow guideline 5.

GUIDELINE 5:Undermine the team’s belief in agile.

Team Issues

Not all of us are managers. Don’t worry, non-managers can wreak havoc at the team level, as well. Just take the case of the NotQuite agile team, tasked with developing inventory-management software. This team shows the power of consistency in bringing down an agile project. For its first iteration, NotQuite committed to completing six items from the product backlog; it finished four. Because it was the first iteration and most teams overcommit in their first iteration, the product owner cut the team a little slack. This didn’t faze the NotQuite team.

For the second iteration the team again planned to finish six items; it finished five. The slight improvement only lulled the product owner into a false sense of security. NotQuite continued to chronically overcommit, falling short in the third, fourth, and fifth iterations. Soon, the product owner learned not to trust the team, and this undermined any success it may have had with agile—a fantastic implementation of guideline 6 for agile failure.

GUIDELINE 6:Continually fail to deliver what you committed to deliver during iteration planning.
When falling short, don’t make the mistake of going all-out on every iteration, reaching the last day panting with exhaustion time after time. A team like that could almost be forgiven for never quite delivering what it planned. A key to NotQuite’s failure was its cavalier attitude toward missed commitments. Team members made it clear that it really didn’t matter if something was finished on the last day of the iteration (as had been committed) or a few days into the next iteration. What’s a few days between friends? Remember, a few days here and there can add up to quite a lot. If an agile team continually misses its commitments, it makes it impossible for the product owner to make plans and external commitments. This leads to guideline 7 for how to fail at agile.

GUIDELINE 7: Cavalierly move work forward from one iteration to the next.It’s good to keep the product owner guessing about what will be delivered.
Perhaps the best way to cause an agile project to fail is to follow guideline 8.

GUIDELINE 8:Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
Merrilynn was able to use this guideline to kill her company’s pilot agile project. Her organization was developing an application that would have separate Windows and Web-based clients. As a development director, Merrilynn had control over team composition and was able to create three separate teams: a Windows team, a Web team, and a test team. This team structure worked against the goals of agile. If Merrilynn had wanted to succeed, she would have instead created three teams that each included Windows, Web, and test skills. Because Merrilynn kept the teams separate, she made it impossible for any team to deliver the working software that an agile team is expected to deliver at the end of each iteration. Nicely done, Merrilynn.

Another option open to Merrilynn was putting all twenty of her people on one team. This would have violated the standard agile advice of creating teams of five to nine people. She could have justified it to anyone who questioned the decision by stressing the unique twoclient nature of her team’s product. If she had chosen to create one large team instead of three reasonably sized teams, Merrilynn would have substantially increased the communication overhead of her team. This would have slowed progress and created complaints about how all the conversations in agile were a tremendous burden. If separating teams is too hard to justify, you can bog down a project very easily by following guideline 9.

GUIDELINE 9:Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup.

Product Owner Issues

As you can see, agile failure at the product owner level is easily achieved through miscommunication, general ignorance of the team’s progress, and lack of education.

If the management and team guidelines aren’t available to you, there is another route to take: Consider a takedown from the product owner angle. A product owner has many options at her disposal to bring an agile project to its knees.

Take Kathy, for example, who was the product owner for a team working on a video game. The team was making great progress on features with every iteration and showing more player “fun” every time. Kathy let team members keep thinking that this was all they needed to do. She never attended reviews, rarely tried the game, and requested stories that were meant to steer the game toward the product she imagined. If that weren’t enough, Kathy didn’t share her own vision with the team or the other customers to whom she reported (such as marketing).

A year into development, the game was demonstrated to a group of executives who were shocked at the direction the game had taken. It was not what they wanted to market. The disconnect between Kathy, the team, and 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 agile 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 agile 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 enusre agile failure 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, agile 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.

Process Issues

Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.

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 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 agile failure.

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 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 agile failure.

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 agile failure.

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 fire way to ensure agile failure 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 and ensure agile failure.

Would you like to include comments?

Tagged:

About the Author

Over the course of twenty years, Clinton Keith has gone from programming avionics for advanced fighter jets and underwater robots to overseeing programming for hit video game titles such as "Midtown Madness," "Midnight Club," and "The Bourne Conspiracy." He introduced the video game industry to agile development is now helping creative teams adopt agile. Clinton is the author of "Agile Game Development with Scrum. His web site is www.ClintonKeith.com

Mike Cohn is the founder of Mountain Goat Software, a process and project management consultancy that specializes in helping companies adopt and improve their use of Agile processes and techniques. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is also a co-founder and current board member of the Scrum Alliance. He can be reached at [email protected]

Damn, i think investing 20 mins into it was worth it. A good read.At first I thought there is no point in reading as the title itself says how to fail :DI'll add something.The first thing to do is to understand the goals, challenges and how automation fits within the overall product development lifecycle. The product lifecycle and your plan for automation should go hand in hand.Ref.: https://blog.appknox.com/5-ste...

Posted by Kartik Jha on 2016-10-13 04:55:33

Hi Ines—

It sounds like you’re facing a number of problems. A couple of suggestions: a) No matter what the sprint length, you have to get the team in a mode of finishing what they think they’ll finish. What I do when they aren’t is I take the number of hours they missed by last sprint, double it, and commit to that many fewer hours this sprint. So if they missed by 50 hours, I’d commit to 100 less in the new sprint. Usually that is enough to break the pattern. If it does, increase the hours a bit in the next sprint and one after that. A team doesn’t need to make it every time but they should make it most of the time. It’s good for them and the predictability aids the business. b) You have to talk to your stakeholders and let them know that the team won’t finish everything. You’ve probably done that already but this is critical for the team and the stakeholders. There is evidence that shows teams do best when they have slightly aggressive but realistic deadlines. Your team knows they can’t finish on time so they really don’t even try. (They may appear to try but their hearts aren’t it so they don’t try very hard.) Drop enough scope to be realistic and it’s likely velocity will go up a bit. c) Discuss micromanagement with the team (as you have). Tell them that they need to find ways of finishing what they say they will and you’re there to help. You’re not micromanaging because (presumably) you aren’t yelling at them when they’re wrong. You’re just holding a mirror up to their own inability right now to predict what they can complete. If they have a good idea of how to get good at that without looking at hours, tell them you’re open to it. (And I’d be open but using hours is, quite frankly, the best way to learn how to get better at estimating). Offer the reward that as soon as they meet their commitment 2 (3?) sprints in a row, you’ll stop asking them to estimate tasks in hours. And you won’t ask again as long as they finish everything almost every sprint. (Miss it two sprints in a row and—bam!—they’re back to estimating in hours.) Also, once they get better, confirm they really do want to abandon hours. Convince them that the hours are for *their* benefit, not yours. A team that is good at doing what they say they will, will have a lot more credibility if they ever need to tell the business, “Sorry, but we can’t do that much by then.” That’s valuable. I hope some of that helps. Good luck!

Posted by mikewcohn on 2013-12-02 15:32:41

Mike, according to GUIDELINE 6, I have this symptom. "Continually fail to deliver what you committed to deliver during iteration planning."

I have started with a team where is being very difficult to achieve the sprint goals. The team continually fails to deliver what committed to deliver. Given this issue, I reduced the sprint duration to 1 week. I wanted them to be able to commit at least 1 week but they still failed. We have a due date that won't be achievable with the current team velocity. After 8 sprints, the team is very demotivated since we are not achieving the goals, not even close.

I use to handle sticky notes in my scrumboard representing 1/2 o 1 day tasks, I prefer this rather than estimating in hours. But in this team, it hasn't worked. Then, we have started to make estimations in hours for each task. They are hating this. They are feeling I am doing micromanagement, measuring each hour and each task and they are right, I'm doing micromanagement because I don't find any other way to make this team self-organized. At this time, I'm not expecting them to burnt X points per sprint, I just want them to be able to commit 1 day. That's it.

How to avoid this this sympton and without needing to make micromanagement?

Posted by Ines Robertson on 2013-12-02 10:21:07

Hi founder--THanks. I'm glad you liked this article. It was fun to do--especially with my co-author, Clinton Keith. I'm honored my books are there between Martin Fowler's and Robert Martin's. You've definitely got a good list of additional causes of failure. Thanks for sharing them. I agree with all of them.

Posted by mikewcohn on 2013-07-24 20:47:18

Great articlte. I got ur book also (all of them). I think these are classics and must reads. These book are positioned between Fowler and Uncle bobs books and some other classics..

What i learned in the past related to failing agile:

Lack of commitment by higher management due to culture of fear is also a big no no.

I see also that Agile/Lean will fail if it cannot coexist with more traditional parts of an organisation.(big enterprises).

And like u already mentioned: learn technical practices. And learn them good and use some common sense. I have see project fail at some degree to bad written and maintainable unit-tests.

The people in the teams should be motivated and read learn an practice to excel. Management on the other hand should also give time for learning so people are not always in a sort of survival mode setting.

The concept of a certificate:Certificates can be misused. A certificate doesn't mean that a person is a master on that topic.

Posted by founder on 2013-07-24 17:18:06

Those are great additions, Skip. Thanks!

Posted by mikewcohn on 2013-07-02 20:49:17

because no list should ever be simple,

GUIDELINE 21. Use flexible scheduling to your advantage.

Make sure some people arrive and leave early while others arrive and leave late. Arrange work schedules so that the chance of one person being in the building at the same time as another team member is 50:50. This minimizes the available 'core time' available for collaboration, assuring that mismatched assumptions creep into the product.

GUIDELINE 22. Maintain discipline integrity.

If someone joins the team from business analysis, make sure that person is never asked to do anything except requirements. Likewise with developers or testers. We may be cross-functional as a group, but we don't have to help each other as a team. No one should be expected to do anything she doesn't have years of experience perfecting; no one should ever be asked to share any of his skills or techniques with someone from another background.

Posted by Skip Pletcher on 2013-07-02 16:58:52

Hi Badger and Karis--Thanks. I'm glad you liked it this way. Sarcasm like this is always tough as there are always people who misinterpret it. Thanks for letting us know you found it helpful.

Posted by mikewcohn on 2013-06-19 15:29:26

Thank you for this article.Not only did it help me release some stress from coworkers using these guidelines, but also helped me realize where I was sabotaging a process that I want to succeed. Having it written in this way helped me understand where my actions didn't line up with agile/scrum, and now I have concrete examples to avoid. Thank you again.

Posted by Badger and Karis on 2013-06-19 15:17:06

Thanks, Greg. I'm glad you enjoyed the article.

Tip #1: "Don’t trust the team or agile. Micromanage both your team members and the process" probably covers what you're describing. That's a very common problem.

Posted by mikewcohn on 2013-04-21 22:36:36

Hey Mike! Great article. I am working on a criticle project right now where most of those involved are new to Agile. Unfortunately, I am getting beaten down by #3.

One thing I didn't see in the list that I am finding with several projects, is the Scrum Master trying to manage the team and micromanaging the teams tasks. Does this fall under one of the items in your articleIn fact both the PO and the SM are trying to manage the team.

Posted by Greg Fox on 2013-04-20 11:11:24

Thanks, Ajeet.

Posted by Mike Cohn on 2013-03-11 13:48:56

Nice article Mike. thank you.

Posted by Ajeet on 2013-03-11 12:36:42

Thanks, Venkatesh.Posted by Mike Cohn on 2013-02-25 09:23:10

This article hits the nail on the head..I am sure all agile practioners would find it usefulPosted by Venkatesh MV on 2013-02-25 05:00:01

This was hilarious and more instructive than anything I've read yet about the subject. Thanks!Posted by Dave on 2012-12-11 15:06:56

Hi Alex--
You're right. We definitely could have include a "guideline" about testing. Thanks.Posted by Mike Cohn on 2012-12-02 11:31:08

Hi,
I missing a guideline about forget testing. How needs a regression test? Its all about delivering faster.
Br
AlexPosted by Alex on 2012-12-02 08:50:01

Thanks, Bhavin. I appreciate your kind words. It's always nice to mix a bit of humor into writing.
Yes, I think the things you list are all classic causes of failure. Ego (as in excessive ego), in particular, is probably one of the biggest problems. Some programmers won't test because it's beneath them. Some people won't accept an idea they didn't think of. Others aren't open to learning from others. All of those problems are ego driven.
A friend told me something really interesting lately. He said he hates being wrong but loves that he's able to admit when he is. I thought that was a great attitude. I'd try to have the same attitude---but I'm never wrong. ;)Posted by Mike Cohn on 2012-10-04 15:27:51

Thanks Mike, that was crisp, clear and to the point.! Humor mixed with warning signs - your articles shows that we don't need to add tons of jargons to clearly communicate :).
A few cents from my experience - I am an agile coach and i often find myself in a situation where people come and ask me, there are multiple vendors and I, as a vendor want to implement agile testing. I don't really know or care what the development vendor does. At times, organizations that follow hierarchical way of leadership are also prone to failure due to various reasons like ego clash, miscommunication, lack of ownership, I vs. WE factor etc.
Classic recipe to failure Mike??
Thanks again for your article.Posted by Bhavin on 2012-10-04 07:37:29

Thanks, John. A common problem is that many specialists take an attitude of "Agile sounds great for everyone but me. If everyone else iterated after I came up with the perfect [database design | technical design | UI design], it would work great."
I'd recommend pointing your technologists toward these two blog posts on Balancing Anticipation and Adaptation and Agile Design: Intentional Yet Emergent as well as my Succeeding with Agile book which addresses those concerns further.Posted by Mike Cohn on 2012-08-31 16:06:14

Very good article. I am a product manager trying to bring Agile and Scrum techniques into the organization. My technologists tell me that our products have too much infrastructure to adopt the Agile and Scrum. "We have large databases with way too many tables and fields that must be defined before we start to code". Posted by john barry on 2012-08-30 09:19:26

Thanks, Ken. I'm glad you liked it. We recently re-organized content on the site and one of the goals was to make old articles more visible and to allow comments on them. On the earlier version of the site, articles were buried so no one was seeing them.Posted by Mike Cohn on 2012-07-17 09:06:18

Mike, An excellent article. Rings so many bells! I am ashamed that its been around since 2008 and I have only just found it!Posted by Ken Duffill on 2012-07-17 04:05:35

Thanks, Mukesh.Posted by Mike Cohn on 2012-06-18 13:50:22

Awesome article Mike, this is really helpful.Posted by mukesh on 2012-06-18 02:52:14

Hi Tom--
The point with #16 is that it may be enough for a team to start out by going through the motions and just doing something because they've been told it's a good idea. But eventually the team needs to really understand the real reason they are doing that practice. Otherwise, it won't necessarily be that practice that gets them in trouble but their lack of fundamental understanding will cause them problems, or at least an inability to discover new practices.Posted by Mike Cohn on 2012-06-10 13:58:03

Hi Sean--
Good luck--If you do all this, I'm sure you'll succeed at failing. ;)Posted by Mike Cohn on 2012-06-08 13:34:07

Thanks, Ubbe. I think your Don Quixote reference is an appropriate. I think we all have days where we're ready to pack it in, thinking we just can't break through to a team or teams. It's worth sticking with it, though, because when a team does break on through to the other side, it's wonderful.
Helping businesses make more money is one thing; it's even better though when we can do that plus help people get so much more enjoyment from their work lives.
I know you will, but stick with it.Posted by Mike Cohn on 2012-06-08 13:19:36

Hi Roshan--
You're absolutely right. When I talk about having multiple product owners I make the point that they must "speak with one voice." I then give the example that the team cannot be thinking, "Mom said 'no'; let's go ask Dad." With product owners like that, the project will be doomed.Posted by Mike Cohn on 2012-06-08 13:07:38

The story of the newlywed wife isn't really working for me for #16.
Could you include a real example of someone slavishly following well established agile practices and by following those agile practices getting into trouble? Did the type of project change?
I think the tension between #15 and #16 is very real, and the roast example doesn't solve it for me. I think the idea of "understanding" is a real sticking point.
What you call "understanding" of agile enough to change the process I am inclined to call (borrowing from Dr. Deming) "profound knowledge." This is a bit more difficult to obtain than "understanding." :-) Posted by Tom on 2012-06-08 10:05:54

Well, it's hilarious - to say the least - I'm going to slavishly try to implement all these on my "magic path planned processes" and see if I can get an Agile process started. I'll let you know either way (or apply for a post on your next Agile project).
Great post really, convinced met on the benefits of AgilePosted by Sean on 2012-06-08 05:30:01

Hi Mike,
Great article that is really spot on. I've seen these "guidelines" in practise so many times since I started teaching/practising Agile thinking (back in the 90's).
From time to time I'm even considering throwing in the towel (well, just briefly), thinking that some people don't want to succeed.
...then, I remember I care too much for "the Agile way" so I continue fighting the Guidlines above even if that would finaly turn me into some sort of Don Quixote character. ;)
Great wisdom in your words, as allways.
I'll be sure to spread the word.
Take care,
UbbePosted by Urban Bäckemo on 2012-06-06 18:24:40

Well I have seen another reason why agile fails at a program level.
When you have multiple Product Owners each responsible for a scrum team .When these Product onwers don't communicate at a program level and share backlog the full picture is lost and hence the customer needs gets ignored.
On the top of this if these product owners again have a reporting structure I have normally seen the reportee product owners never take descisions and drive to do the right for the customer .Posted by Roshan on 2012-06-06 05:24:54

Thanks, Deepa.Posted by Mike Cohn on 2012-06-06 01:44:13

Great guidelines. Kind of an eye opener for who want to succeed with agile but unknowingly are following one or more of these guidelines! Posted by Deepa Shrivastava on 2012-06-06 01:34:55