New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Common Mistakes in Agile Adoptions

| by Shane Hastie on Nov 14, 2010. Estimated reading time: 8 minutes |

A number of commentators have written about common mistakes and anti-patterns of Agile adoption. They have posted “Top X” lists of things to avoid and mistakes they have seen in Agile implementations across a variety of organisations.

Michael Dubakov of Target Process wrote two blog entries about of the “10 Most Common Mistakes in Agile Adoption”  (Part 1 & Part 2). He maintains that “Companies are making the same mistake during agile adoption over and over again.” 

Here is his list of common mistakes:

1. Start With a Tool
Agile development is something different. A tool will not provide immediate effect and will not solve most of the problems by the mere fact of its existence. Moreover, you will put effort into tool adoption, shading more important goal — agile adoption
2. Start With a Process
Most companies start with a process. It is a less serious, but a more common mistake. So you read about Scrum, it looks easy initially. You apply all Scrum practices and after some sprints see that development somewhat improved, but not as drastically as expected. Excitement goes away and process degrades.The first thing any company should do before trying any process is to focus on agile values such as: communication, collaboration, feedback, trust and passion. It is nearly impossible to apply a good development process if you compromise any of these values.

3. Development Practices Are Enough
Interestingly, that developers tend to apply technical practices like TDD, Continuous Integration and even Pair programming, but pay less attention to such things as communication, integral team, having customer on-site and retrospectives.
4. Scrum is Enough
The true mistake will be to rely on Scrum solely as a process that will solve all the problems. It can do that, but only if you are open-minded and willing to try various things: from pair programming to BDD. Best coaches believe that Scrum should be adopted in tight pack with XP technical practices
5. CSM Knows Everything
Certified Scrum Master is not a demigod. Yes, he has some basic knowledge about Scrum, but in many cases that’s just it.
6. CST Knows Everything
Certified Scrum Trainer is not a God. Yes, he knows a lot and has a decent experience. There is a high chance that he may be a capable person to help with agile adoption, but only help. He may know nothing about your domain, about your unique situation and about root problems of your organization. If you rely solely on CST and delegate agile adoption to him, it will fail.
7. Functional Departments Should Survive
There are absolutely no reasons to keep functional departments and functional teams. People should work together as a team whenever it’s possible. Definitely, when you have testers in US and developers in India, it is hardly possible. But it is just plain dumb to NOT have cross-functional team if everybody sits in the same building
8. We Can Live Without Customer Feedback
Agile is mostly about fast feedback. Feedback from customers is the most important. If you build something with wrong methods, that’s bad. But if you build a wrong thing, that’s just terrible. Why? You will have to throw it away later. Regular (and fast!) feedback from customer is like a sailing direction in a bay with reefs. You constantly correct the course based on wind change and other factors. Customer is the most valuable team member and should be treated accordingly.
9. Self-organization is Easy
Pure self-organization assumes that a leader will emerge. That’s not happen frequently, in many cases team will stagnate and fluctuate around mediocrity without a leader. Leader sets a vision and pushes team to the right direction. Leader empowers confidence, passion and self-reflection. This leads to self-organization eventually.
What happens when leader leaves the team? In most cases it falls back or degrades slowly. This is a clear sign that self-organization was not there. True self-organized team will keep its values and progress without a leader.
10. False Goal (e.g. Customers asked us to be agile)
If you have a customer who insists on agile process for his project, you should praise Heaven for this gift. Use this chance as a turning point for agile adoption.
Unfortunately, many companies just try to “emulate” agile adoption with a desire to get this contract. They send some people to CSM courses, purchase an agile project management tool and apply Scrum superficially. They do all that without deep goals and culture change. They do all that without passion. 

 Mike Griffiths of the Leading Answers blog wrote about “Agile Adoption Anti-Patterns” and gives a list of five common mistakes he has seen:

1. Agile as a silver bullet - Yes, agile methods can save time, increase business buy-in, and create a high quality product, but they are no silver bullet. They will not bend space or time and allow you to deliver more work that is possible within the constraints of limited time, budget, and resources.
2. Agile as an excuse for no discipline – Contrary to some people’s beliefs, agile methods do not abandon discipline and jump straight to coding without the need for plans and estimates. Agile methods involve many high discipline activities and techniques like Test Driven Development, Wideband Delphi estimation, and bi-weekly iteration planning and estimation sessions take a lot of discipline.
3. Agile without explanation – Projects and teams do not exist within a vacuum; they have interactions with many other stakeholders in the organization. While it might seem easier at first to keep the agile practices to your team, a domain you have more influence over, but there comes a time when you need to explain the working practices to others.
4. Shallow Feedback – Agile methods rely on feedback on an evolving system to confirm understanding and gain acceptance of work done. Typically new features are demo’d to the business and left with them in a test environment for their trial and feedback. It is tempting to think that if we receive little or no feedback then the users must be happy with what we have developed. However it is far more likely that they have not really looked at it properly or tried it with real data or scenarios.
5. Agile Process Fixation – People get passionate about agile methods which is generally a good thing, but if people start to focus too much on the process at an expense to delivering business value then we have a problem. Projects are usually undertaken and funded to effect some business change or improvement. We are not in business to practice perfect methods, the ultimate goal is delighting our sponsors and users, not obsessing on process or building resumes.

Craig Larman and Bas Vode wrote an item titled “Top Ten Organizational Impediments to Large-Scale Agile Adoption” in which they “asked a group of agile development experts working in and with large companies about the most challenging organizational impediments”  

Their top-ten list contains the following entries:

10. Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments the main obstacle in large organizations
9. Peter Alfvin, an experienced development manager involved with introducing lean principles at Xerox, and Petri Haapio, head of the agile coaching department at Reaktor Innovations, both mention centralized departments looking for cost ‘savings’ and ‘synergy’ that leads to a local optimization as an impediment.
8. Sami Lilja, global coordinator of agile development activities at Nokia Siemens Networks, noticed that some organizations consider learning a waste of time and money.
7. Larry Cai, a specialist at Ericsson Shanghai, mentions functional organizations (single-function groups) as one of the largest impediments. They create barriers for communication and abet finger-pointing among units.
6. Esther Derby, consultant, coach, expert facilitator, and author of two books related to organizational learning, considers systems that foster local optimization over global optimization a major barrier. She gave several examples, including Management by Objectives (MBO) and budgeting systems.
5. Mike Bria, a former agile coach at Siemens Medical Systems, mentioned “do-it-yourself home improvement” as an impediment. He highlighted the problem attitude of “we know how” after people read one or two books.
4. A. (name removed on request), a Scrum trainer at one of the largest e-commerce sites, mentioned individual performance evaluation and rewarding as a major obstacle. They frustrate developers and managers, hinder team performance, and foster command-and-control management.
3. Lü Yi, a Scrum trainer and department manager of a large development group in Nokia Siemens Networks in Hangzhou, considers “commitment games” and unrealistic promises to be the main organizational obstacle. They lead to shortcuts, continuous fire fighting, and legacy code.
2. Diana Larsen, expert facilitator and, together with Esther Derby, the author of Agile Retrospectives, simply stated, “Assuming it’s all about developers.”
1. Almost everybody cited “silver bullet thinking and superficial adoption” as a major impediment.

In addition to the points listed by others, Larman and Vode mentioned two additional impediments they see regularly:

Craig thinks that a culture of individual workers rather than real teams and teamwork is a key impediment. He visits many groups of individuals that are ostensibly adopting Scrum, and sees symptoms such as “Jill does Jill’s tasks, Raj does Raj’s tasks” and so forth, rather than a movement to “whole team together,” pair work, and multi-learning within the group. 

Bas considers the gap between people in management roles and those doing the hands-on work to be a key impediment. Frequently, changes made at the management level have no impact (or at least, no positive impact) whatsoever on the actual value work. Similarly, decisions by hands-on developers are often not aligned with the direction of the organization.


Another list by Cory Foy can be found here.

What are the common mistakes and problems in implementing Agile techniques? How can teams and organisations avoid them?


Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

HI~~ by tou cao

nice news datagrid

And what about the root cause(s)? by Bob Marshalll

Nice round-up of opinions from most quarters. Unfortunately, you have only managed to repeat the common problem of listing symptoms of why Agile adoptions fail, rather than getting down to the root cause(s).

Hopefully one day (sooner rather than later, in preference) the Agile community might start to accept that a) Agile adoptions DO regularly fail, and b) become interested in WHY that might be, such that adopters can do some practical things to mitigate their risk(s) and raise their chances of success.


- Bob aka @FlowchainSensei

And now for the way forward by Patrick Verheij

Nice lists of lists to be used as a checklist when assessing what you (or someone else for that matter) is doing. Such list always trigger me immediately to think of ways to avoid these pitfalls and do things right. So I feel very comfortable with for example the second and third entry of the first list (about process and practices), but not really with the first one (tools).

A lot of companies that haul in agile methods or practices will be asking first thing for a way to report progress. Top management that is. From their high rise offices they expect to see dashboards taht indicate progress. The first thing I see a lot of suppliers do is putting tools together to report progress. Before they have even done anything. After that, everything has to fit these tools and its hard to ditch them because management is asking for them.

Another example is the warning that a Scrum Master does not know everything. Many companies that start doing Scrum have only one guy that has attended a Scrum course and is now playing the role of Scrum Master. So he actually is the demon who knows it all. No way around it.

So while I think lists such as these have value in itself, it would be even more valuable to have lists with approaches that one can use to avoid such pitfalls. Like for example "luring upper management to the work floor" so they can see for themselves what is going on. A lot of managers have never done that and are positively surprised to see what is going on and start doing it more often, which makes the reporting tool obsolete. Decent management coaching is a requirement. And in the case of the Scrum Master, he should be made a trainer for his peers and be sent to conferences to broaden his view and be more effective.

So far for my rant. Keep up the good work!

ack by joshua milane

Making Agile something more than it is (a way to get stuff done) has to rank up there. ScrumLeanBan or WaterXP, it comes down to what fits and what works with a healthy dose of discipline.

The illness behind all of this has many symptoms, and one of those is lists. Lots of lists. Lots of documentation. Collaboration is not yelling back and forth and collaboration is not the King telling His subjects how to behave. Fundamental tenet. It is not sexy, but if you want sexy there are other places to look.

Josh Milane

Is agile the best methodology for all types of project? by Udayan Banerjee

I think Agile may not be the most suitable methodology for all types of projects. I have found it useful to classify project into the following categories:
- ROI project
- 7th-Habit project
- O-Ring project
- Hype-Cycle project
- Build-to-Flip project

How agile can be applied on each of these categories differ -

Practice vs Principles by David Lewis

My view is that many organisations fall in to the trap of selectively applying some Agile "Practices" (Scrum, Standups, Retrospectives) because these activities fit with their existing process focused view.

What they fail to do is understand and apply the "Principles" behind Agile.
They get hung up on the "What" & overlook the "Why".

The problem is that the principles are likely to require organisational changes which may be resisted by many vested interests.

what do you think about these? by Andrej Ruckij

i would add following these two:
- people try to apply it by the book, but no to adopt and apply what really works
- agile adoption is implemented only in development department, but not across company

Automating deployments by XebiaLabs XebiaLabs

Thanks for condensing these lists, Shane. Something we don’t see listed as a common mistake in Agile adoption is a lack of automated deployments. Agile creates lots of benefits for a company, especially with the shorter iterations and more frequent deliverables, resulting in faster time-to-market. However, operations teams often can’t keep up and consequently develop a backlog of deliverables to deploy. By automating this process, not only can IT departments stay on top of the faster iterations Agile allows, but can also cut down on human errors resulting from manual processes. Would you agree with this addition to the lists?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you