Many organizations aim to be agile. However, only few succeed in becoming truly agile and gaining the benefits out of it.
Let’s take a look at what are the common mistakes in the journey on becoming agile and how to avoid them. This is your mini-guide for success for taking your agile change journey to the right track straight from the beginning.
I found eight common mistakes to avoid. Do you recognize them?
- Doing agile (just) because agile is trendy
- Putting no time and effort to implement changes especially when people are involved
- Not forming tribes around the value
- Thinking doing scrum ceremonies is being agile
- Filling calendars with meetings = no time for real work
- Making only teams agile but not concentrating on the mindset and prioritization on company level
- Having product owners as team output owners
- Having product owners doing everything else but what they are actually supposed to do
In this blog post I’m concentrating on change related mistakes.
Other parts of the series:
Making agile work: Avoiding scrum related mistakes
Making agile work: Avoiding challenges with the product owner’s role
1. Doing agile (just) because agile is trendy
You start agile change because you have heard that it’s trendy to be agile. That is not the way to succeed with the change. Let’s think this very simply: Why people in general would want to change? People want change to see if the “grass is greener over there”, so to say. They want to change because the future might look brighter than today.
If you want to be successful, you need to understand the current situation and the current problems. You should be able to show how the change will solve them. You need to show how to improve the current situation and go forward. In other words, build on top of what you already have today. Never neglect the current situation or crash everything people already have today only because you want to be agile. Don’t make people invent the wheel again from the scratch. Don’t give them a bike if they already have a car.
Here is what you should do:
- Listen to people
- Concentrate on understanding that current situation
- Find out what is the main problem people are facing today
- Build your message about the change around the main problem and focus on explaining how the change will solve it.
- Show how the change will build on top what you have now and take people forward.
I would even recommend to focus more on how to solve the current problems than concentrating on becoming agile. It doesn’t matter if it’s lean or agile or common sense how you fix the problem and make everyday lives better for the people. What matters is that you solve the problem and take people forward, not backwards. What matters is that you make a positive change. At the end, by solving small issues one at a time you actually create a continuous improving culture. That is agile.
2. Putting no time and effort to implementing changes, especially when people are involved
What people have learned related to agile is that in agile you can make changes fast. This is correct. However, what happens often is that couple of people start to do improvements for the ways of working inside the tribe every now and then and they are “implementing” the changes by telling people to just see the new instructions on the intranet. This is where it goes wrong.
We need to remember that when people are involved, the “release phase” does not just happen in a second. Especially this is hard if people are full of work and have no time allocation for new things that keep on popping up. If people need to learn or change their behaviour, it is not as easy as just pushing a button and the change has happened.
More reading on the topic: Where did change curve disappear in agile?
How to put effort into implementing an agile change?
- Understand that people need time and effort for adapting the change
- Allocate time for the change for people.
- Plan and prioritize all the changes that are to come.
- Treat agile as a big change initiative.
Understand that people need time and effort for adapting the change. People normally need some help with adopting the change. Before each release, evaluate the impacts of each change and according to the analysis organise the support needed for the people to adopt the change. The support can be e.g. info sessions, trainings, clarifications what is the change and what to do differently and what to continue doing etc.
Allocate time for the change for the people. Understand that people have limited capacity for change adoption. You cannot just overload people with the change activities just like you don’t overload team members with the daily work in the sprint plannings either. Remember to make the decision about what work can be left out so that the time allocation is real. Create a clear picture of all the changes that are touching your people.
Plan and prioritize all the changes that are to come. As you are agile, create a backlog for this. You can call it transformation backlog or change portfolio if you like. At the end remember to combine this work with team level backlogs to get only one source of work for the teams. As you might remember, the best practise with retro items (=improvement actions for the team, small changes) is to put the retro items into the team backlog. The same should be done with these change items because at the end we are talking about the capacity of the same people and teams here who are building the products for your company.
Treat agile as a big change initiative. Create a vision and roadmap for the change to show people the way where we are going. Measure the change, react to feedback, and follow up the change journey. Start a change measurement to get feedback from your change. Here is one tool you can use for change measurement: Celkee Insight. Systematically check the measurement results and react to the feedback and make improvements.
Communicate to people where you are now with the change, what kind of improvements you are going to do next and how close you are your goal (=this is the roadmap I was talking about). Like this you can show that you are all together doing this change journey and you are really listening to people and wanting to make things work step by step. This practise actually works in all level: as well as in team level as in company level and with all sizes of change activities.
3. Not forming tribes around the value
Very typical thing what happens when companies are changing their structure to tribes (or teams of teams or trains or however you want to call an umbrella above the teams) is that actually nothing else changes but the name. The same line organisation stays but the name is now a tribe. Make sure that you change something else than just the name. We don’t want to just rename our organization, we want to make change!
What to keep in mind before making a final decision about tribes?
Remember that in agile we want to create customer value and be close to the customer. We want to deliver something to the customer as fast as we can to be able to get feedback on how to improve the things we are doing, so that it would even better create value for the customer. We should form our tribes based on the value.
Component based tribes are not actually value based. What happens when you have component based setup is that you start suboptimizing. We don’t want to have tribes that are sub-optimising the wheels. We’d rather want a tribe that would build some kind of a moving vehicle that would make sense for the customer as a whole.
We want a tribe that would deliver something valuable for the customer that customer could take into use right away and give us feedback how it fits the customer needs. That is how we learn what to improve. Only a wheel does not make any sense for the customer. The key for being agile is really forming your organization around the value and thinking this organization from customer value point of view, not from your team or existing organization point of view.
