Originally posted July 25 2022
10. Top-down implementation of Agile
I know organizations that implement agile top-down. The top of the organization tells the teams that they will have to be working in an agile way and will also establish the how and when. But agile is about teams that self-organize to create valuable products.
It makes sense that management communicates the goal. However, finding the best way should involve both management and teams. Together, they should embark on the journey. Every team is unique, as is every product. This calls for teams to decide what works for them.
9. “Implementing” culture of change
Closely related to the top-down implementation of agile is the idea that you can simply implement a culture of change by publishing a culture handbook or creating some new procedures.
It doesn’t work that way. The culture of an organization is something that has been developed for years and years by everyone who has been a part of it. You can’t simply change the culture. But you can follow up the culture handbook (ideally created with the help of employees) by showing the desired behaviour yourself and supporting exemplary behaviour from others. And you need to be patient.
8. Focus on output
Many companies have agile teams that are totally focused on creating and delivering items. They focus on time-to-market and test automation and CI/CD to deliver quicker and quicker. But the focus on output alone is an agile anti-pattern.
Because it doesn’t matter that much how fast you deliver new items when these items aren’t what the customer wants. Often new features remain unused because there’s no need for them.
What really matters is the impact you make with the output.
7. Ignoring customers and users
Many agile teams only have a vague idea of who their users are or what their customers want. They are never in contact with these vital stakeholders. They may have their regular demos or reviews, but the attendants are internal stakeholders only. It’s already considered a success to see sales there. But sales are a proxy. They are not the customer.
Teams build their products for customers and users. Customers and users need to be involved. The whole idea of agile is that you verify your product with your users regularly. Without this verification, there’s no foundation for your agile journey.
6. Agile is IT only
Agile is often mistakenly considered to be IT only. That IT should be agile and the rest of the organization doesn’t need to change. This ignores the fact that apart from IT many other people help to create a customer experience. And without alignment, the customer will not be served well.
IT is only a part of the product experience, the experience the user has with the product. It also includes things like sales, support, policies and third parties. They all are in the same boat of maximising the value of the product as a whole in an ever-changing environment. This calls for collaboration between these people and fast feedback loops. It means that they all need to be agile.
5. Agile on team level only
One of the greater misconceptions is that agile is only applicable to the teams that build the product. As long as the teams are agile, everything is deemed to be fine.
But it doesn’t work this way. Teams work in an organization and are constantly impacted by that organization. When the organizations show anti-agile behaviour, this can do the teams a disservice. It can hurt the potential of that team to create value.
Management, leadership, HR and others should foster the teams. Help them to be effective agile teams. Also, the entire organisation should be aligned on how they create a product experience and achieve its objectives in an agile way.
4. Agile is about faster delivery
“We want to be agile and deliver faster”. I have seen this statement made by the top management of a large company. It immediately shows they don’t know what they are talking about.
Agile is not about faster delivery. It is about understanding that you can’t know everything upfront; therefore, you will create small increments to inspect with your users. It is about faster feedback and then having a better idea of what to do next. It is about knowing as soon as possible what works and what doesn’t. In collaboration with your users.
Focusing on faster delivery and ignoring the feedback loop makes you a feature factory. You are very good at creating output. But you are certain to create products people don’t want.
3. Implementing Agile in a Waterfall way
The journey to becoming agile is not served with a lengthy analysis and detailed long-term plan with phase-gated workflows.
An agile way of working is a clear shift from traditional “Waterfall” thinking. Teams will not over-analyze their work but instead learn from building new increments of product. They will gain insights into the value of the product faster and also find better ways to collaborate.
You wish to set objectives at the start of the agile journey and find the best ways to achieve your objectives. You want to learn from things you did, from what worked and what didn’t. You wish to do this by involving the teams as a joint effort.
2. Implementing immutable processes and tools
One of the most painful ways to become agile is to implement an approach out of the box. Teams may be instructed to use Scrum, work with a certain pre-configured tool (like Jira), have a fixed length Sprint and be instructed to use a pre-set velocity. The same disastrous introductions happen with SAFe. But then scaled from top to bottom throughout the organisation.
Scrum and other agile approaches aren’t meant to be carbon-copied on organizations. Every team is different and every product environment they work in is too. Teams are bound to feel restricted by the standard processes. They may have areas to improve. But when they aren’t allowed to work on these improvements, they will become less and less effective.
The introduction of an approach is only the start of the actual agile journey. Because through this, teams should be enabled and also expected to seek improvements. This is what it is all about. Agile is about embracing constant change, and constant improvement. Challenging the status quo. However sacred a procedure is.
1. The desire to be agile
The number one mistake organizations make is the desire to be agile in the first place. Agile should not be a goal. No one will decide to use your product because you are agile. Being agile means nothing to the market and your shareholders. It’s only a word. If anything, it can even be harmful. Because you show you are a laggard. You are showing you are dated because the late majority arrived at this stage more than 5 years ago.
Instead of aiming to be agile, organizations should focus on the impact they wish to make and set goals to achieve this impact. You want to ensure that everyone in the organization aligns with the goals. You wish to enable your employees to do whatever they deem necessary to achieve the goals. And you are going to help the people to remove impediments that prevent them from doing so. This can include removing silos, overlong processes ad other types of waste.
It doesn’t matter what you call this. Perhaps this isn’t even important because your users and shareholders will judge you on your impact and your revenue. Not on you to call yourself agile.