10 Most Common Mistakes in Agile Adoption. Part II
10 Most Common Mistakes in Agile Adoption. Part II
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
In Part I I’ve described 5 mistakes in agile adoption, this part has 5 more.
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.
Everything should start from the culture and people. It means everything should start with you. You should share agile values and support CST with all the passion and force you have to make agile adoption a success.
7. Functional Departments Should Survive
You are starting a new agile project. Design manager delegated one designer to the team, but refused to re-allocate his desk. QA Manager delegated several testers, but refused to re-allocate them. Developers sit together, but all the other team members are separated by walls. Sounds familiar? Most likely there is no cross-functional team there, and agile adoption will suffer.
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.
Cross-functional teams have so many positives, and no negatives. With cross-functional teams you improve communication, reduce functional competition, simplify problem solving, enable ad-hock process improvements and creativity. Again, there is NO reason to work with old traditional functional teams.
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.
Extreme programming recommends to have customer on-site. While this is a great tip, it is rarely practical. Still, you have customer available remotely all the time to answer questions and communicate about a product. If you can’t have feedback in a reasonable amount of time, agile methods will not work. You may build a technically perfect product, but yield zero customer’s satisfaction in the end.
9. Self-organization is Easy
Scrum heavily advertises self-organization. Complexity theory has something to say about it as well. Self-organization is based on a set of (simple) rules, non-linearity and interactions between agents (in our case between people). As a Scrum Master you should just set some (widely known) rules, protect the team and expect the team to self-organize. Right? In reality it is not that simple and no, it will not work out. I’ve never seen self-organization working with just a set of rules.Self-organization in a software development team needs more, it needs leadership. I believe that self-organization can’t happen without leadership.
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. They do all that with a false goal. Almost inevitably there will be the following symptoms:
- Sprints fail. Always.
- No commitment.
- Scrum Master assigns people to user stories.
- Testing phase in each sprint.
The result of “false goal” agile adoption is failure and a long-term disappointment with agile software development.
I encourage you to share another mistakes in agile adoption!
Published at DZone with permission of Michael Dubakov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.