Common Mistakes in Agile Adoptions

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?