While the agile methodologies - like scrum - in themselves are relatively simple, implementing them is not. During most implementation projects, typical "bad practices" and other hindering elements appear, giving bad solutions to problems appearing along the journey - called Antipatterns in short. Antipatterns are not evil by nature, they are most often created with good intentions, yet they hold back transformations significantly. Well, the road to hell is paved with good intentions as they say. By learning from experiences of others you can anticipate their arrival and treat them on-site, or even prepare for and prevent them from appearing in your next projects.
In our experience, they come from two main sources:
1. Pre-agile working methods and hierarchy
2. Forgetting about being agile in order to progress quickly towards doing agile
Although several antipatterns may emerge from these main sources, we collected the four most common ones that we experienced during our agile transformation projects:
1. PO as a boss
In new agile teams, the PO quite often wants to still manage, or even micromanage the distribution and delivery of every single task within the squad. At the same time, the squad members are almost waiting for the PO to give them tasks to the same extent, or at least ask for his/her confirmation beforehand. This issue is very typical in squads where the squad setup is very similar to a previous team setup where the PO was the manager. If this has worked well and everyone was comfortable with the previous setup, the lack of tension makes them hard to convince and slows down abandoning the old hierarchical habits.
2. The need to standardize everything
Whenever you start hearing “we need a standardized solution for this”, start listening very carefully and start asking questions to uncover if the standardization creates enough value to mitigate its sacrifices. Big organizations just love to standardize everything, and they tend to apply the same in their agile adaptation approach. This is quite counter-intuitive, considering the first value of agile is being Individuals and Interactions Over Processes and Tools. While we agree that some harmonization is needed in case the company runs many squads, you should always ask the question whether it is more important than the efficient and effective work within the respective squads. If an organization chose to use scrum, it also chose to empower teams to be more efficient. And giving them a standardized list with dozens of elements on how you should do your daily work doesn’t feel very empowering, nor will it lead to higher efficiency.
3. Jumping into quick solution mode
An organizational transformation is a turbulent time, during which many questions, problems, and management requests arrive. It is natural, that people want to answer these quickly, especially if they have the newly-found rewarding sensation of putting them into Done status. This phenomenon is very close to winning the ‘mother of all antipatterns title’ because it creates so many new ones. But how is it a problem if you solve all issues arriving quickly, you ask? In itself, solving them is not a problem, but solving them without asking back, clarifying them, and thinking about the root cause/main goal can create a lot of bad practices in a very short time, exactly because they were solved too quickly. The main idea is not to solve the issues coming in right away, but to regard them as symptoms of a core issue, dig deep and address the underlying need leading to that symptom and start working on that. Also, you don’t have to solve everything, very often taking a problem to the team is the best approach. The reason is simple, they know their work best within the organization, and when you build on this knowledge plus inspire them by the relevant agile values and practices as their SM/AC, they can translate that to actual things to do in their way of working.
4. Using T for 'This is not my task'
The squads are responsible for delivery. Yet, T shaped skills are typically shaped when they start working together, so every task created during the planning has a hidden likely owner, which can very easily lead to statements like the above. Roles and responsibilities within Job descriptions are often not updated instantly, and even if they are, developing the skills necessary to perform in other professional areas takes time. However, there are overlapping competencies in lots of teams, not being used to do some tasks types is not equal to not having the competencies to do so. Learning by shadowing peers or working closely together can quickly develop some knowledge to jump into a neighboring business area if needed to substitute or to help another squad member. And even a little help can mean a lot when the demo is getting close.
Nevertheless, we can all agree that change is always hard and it does not happen from one day to another. Change takes time and effort and paying attention to eliminating antipatterns can prevent the emerging transformation fall backs to the old habits and familiar processes.