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.
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.
What are the common mistakes and problems in implementing Agile techniques? How can teams and organisations avoid them?
And what about 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
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!
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.
Is agile the best methodology for all types of project?
- 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 - setandbma.wordpress.com/2010/05/04/when-deliver...
Practice vs Principles
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?
- 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