Throughout the years, many people have learnt to implement agile but are still struggling with how to run big transformation programs. Many big organisations take initiatives building a central team of coaches for transforming the whole organisation into agile, but there are some mistakes that should be avoided.
While working with big organisations as a member of an agile transformation team, I have learnt some anti-patterns that I am going to elaborate in this article.
- One size fits all.
- Too long preparation time
- All at once
- Ignorance of supporting environment
- Ignorance of technical practices
- Vendor management and distribute team excuses
- Agile as a delivery engine
In this article I am explaining the first anti-pattern:
One size fits all
Each product is different from another in terms of complexity, team structure and vendor association. How then, do standardisation of tools and practices work?
This is one of the most common anti-patterns of agile transformation programs. Many organisations try to standardise agile practices, tools, and behaviours.
In my experience, I have seen people recommending, or worse, forcing teams to use enterprise-level best practices or tools.
There is no best-practice, because the best practice does not leave a room for improvement; which is against the agile principle of continuous improvement.
Secondly, recommending standard practices defeats the purpose of flexibility in agile, which was the original reason of not making agile frameworks prescriptive.
For instance, there are many big organisations that write their own agile methodology and prescribe all the practices, tools and how to implement them. Also, they call it “<company name> + Agile Methodology”. Often this appears to be a compromised version of agile.
Similarly, organisations choose one standard agile tool for all teams without knowing if it would be comfortable and suitable for teams. The most common pattern is using one electronic tool for all teams that use Kanban. However, there are better tools available to serve the purpose. For example, recommending Atlassian Jira in the whole organization can lead problems for kanban teams. Instead, they might use Swift Kanban or Trello which are a better fit for Kanban. The more alarming situation is when the teams are co-located and can use physical boards, but are forced to use the electronic tool because it is a recommended standard enterprise level tool.
Why is Standardisation Harmful?
As every human being is different and forcing them to behave, talk and work in the same way can be counter-productive. Having a standard agile methodology in every situation proves to be harmful.
I have seen support teams struggle with fixed iterations, novice teams struggle with a continuous flow of work and support functions struggle with writing user stories. Hence, standardisation only leads to frustration in people and compromise in business benefits.
It mostly happens when people focus more on practices rather than on values and principles. Moreover, not having trust on teams for experimentation and not letting them choose their own suitable way of working can harm productivity.
Custom Fit
As you might be convinced by now, “one size fits all” does not work. What is then the solution?
The answer is “custom fit”. The first step is to understand the context of the team, product nature, people, and business expectations. Then, choose your framework, set of practices and principles accordingly. Try and continuously learn from your mistakes. This way, the method will evolve over the period of time and you will find the “suitable model” for you. Don’t stop improving!
Please share your experiences. Do you use standard tools and practices? Are they working for you? Have you evolved your method over the period of time?
Stay Curious!
