Do You Make These 5 Mistakes in Agile Adoption?
You should know that Agile methodology is not something you can implement, it is an approach that you can try to achieve. So, you do not apply Agile, you just employ techniques that help you become agile; that gives you the ability to make good moves and to become adaptable and resourceful. So what is the real development direction for many individuals and companies?
Many developers and organizations have faced an organizational dysfunction that leads to fragile agile. It’s very important to notice – Agile and Scrum are not about software; they are about people.
1. You don’t have an experienced Agile/Scrum coach
There will be large efforts for organizations trying to adopt the Agile methodology. Simple training a few team members/ project managers to Scrum methodology is not enough to obtain the level of change required for success. You will need a few experienced coaches – dedicated professionals who have not only conducted such a transition successfully but understand the growing problems and trouble spots described here.
In small companies, a good coach may be external and could be engaged on a part-time basis. It is possible to find an Agile/Scrum coach on a contract/ agreement to help you introduce Agile, or even make some progress. For larger companies, you should have an employed Scrum master and Product owner.
2. Your team does not accept re-organization
Your CEO-s and managers may not give you a support to adopt Agile, not only due to skepticism of what is viewed as an innovative methodology but also an unwillingness to distribute control to teams. This change in management approach would mean to lose the ‘carrot and stick’ method, which the company was used to apply.
The development teams should like, and should be very excited for the chance to employ Scrum and move toward Agility. In general, there is nothing more poisonous to a developer’s working habits – than meetings and other layoffs. There will be some team members (developers) who would prefer to stay behind a manager and disliked the openness into their every day’s activities that is required by Agile. Possibly, a few people may quit, but that will create room on for new team members – willing to accept this type of work. You should expect to lose some people during this transition.
3. Lack of consensus
Team consensus is a fundamental step in Agile/ Scrum. A high-dedicated Agile organization will structure teams to manage and organize their work. As a rule – nobody knows better the team functioning – than the team itself. The consensus will bring accountability. The team should be at the center of the universe, and the managers will have a support role, (removing obstacles for the team). As the team gets results (successful outcomes), its sense of consensus is stronger.
The development team un-effectiveness could be due to one obvious weakness – the Product Owner. If the Product owner has only small product knowledge, and the project is high risk with a strict deadline – the owner will become only a proxy for his superior manager, and a cinch to the stakeholders. The consensus will prevent this in both aspects. You should ensure to put the right people in the right positions, or the project will go to abyss.
4. Don’t following the Scrum schedule
The 4 basic iterative events in Scrum are: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. You should know that the Sprint Retrospective produces some of the most valuable, but toughest for implementation feedback. Thus, the main role has the Scrum Master to not only effectively facilitate the meeting, but to remove bottlenecks for the team.
The Scrum Master has also a tutoring role. When the team has endeavors, the CEO looks to the coach, not the team. Scrum Masters are not Project Managers. An inexperienced Scrum Master will try to manage the team – instead of leading, coaching, and guiding the team. A command / control management style is not suitable for Scrum and Agile Methods. The Scrum Master who assigns tasks and pushes effort – is not only breaking the rules of Scrum but will also obstruct your team. The best Scrum teams are self-organizing, with their Scrum Master functioning as an assistant leader.
5. Don’t have a pilot project and people
Agile methodology will not be suitable for all environments, and if it is good for you, you shouldn’t apply it at once. You could minimize risk with a trial project. You will have a successful approach if you understand that Scrum produces best results – only if practiced with an engaged team. Results could improve the outlook and – in turn, the outlook will improve the results iteratively.
If you start with a trial project – it will be far less critical than the project that delivers some value. Whichever project you choose, you should ensure that it’s not bringing new problems. This may seem unreasonable and risky, but you should always start with ideal projects in which the basic nature of Scrum can give quick results. An opposite situation is a 12-month waterfall project, where failure is visible only at the project closure when all the time and money have been spent, and course corrections are impossible to make.
