When I work with clients to help them transform towards higher organizational agility, I get lots of negative reactions to agile key principles. To many, these principles seem counter intuitive to their current way of working. But what disturbs the agile opponents the most is the need for transparency, which is one of the fundamentals in e.g. Scrum and Kanban. And, by the way, a prerequisite for improvement.
Even if most buy in to the idea that if you cannot see what happens in your system, i.e. your project, your department, your team, etc., you do not have a baseline for improvements and you cannot react sensibly and timely to whatever is disturbing the flow (=progress) in your system. I often experience that people resist to show what they are working on and how. This happens at the individual, the team, and the managerial level. But why?
Well, mainly out of fear of making it visible that:
- All – managers too – make mistakes
- We may not handle dependencies very well
- We do things that don’t really make sense
- Some are not as busy as they should be (and pretend to be)
- We are not in control of our processes
- We do not produce the results we could
To cut a long story short, many don’t want to know, and are afraid of discovering what is really going on. When you can see the “bad stuff” in your system, it will most likely point to something you or your team could actively do something about. Transparency makes it difficult not to react on what you discover and just let the “bad stuff” continue. It’s much easier to pretend that everything is OK.
Where does fear of transparency come from?
Well, 3 answers apply:
If errors are not accepted in your company, you will most likely want to hide your mistakes. Transparency makes that impossible.
If top-down management is the norm in your company, you are not expected to question the orders you get. Even if you can clearly see that they will lead in the wrong direction. Managers that thrive on this management style will work against transparency, as this would put a big finger on the sore spots of their decisions, strategies etc.
If it is (silently) accepted in your company that not all employees are equally busy, and that some do not assume responsibility or show leadership, then your not-so-busy colleagues will oppose to transparency. They don’t want to be “found out”.
If any of these three situations apply, agile will probably not be the right choice anyway, so don’t waste your time and money.
The Spice Girl Question: “Tell me what you want, what you really, really want!”
If, on the other hand, you have decided that you do want improvements in:
- employee satisfaction
- customer satisfaction
which are examples of good things that an agile approach usually brings, you need to carefully think about and understand what is driving your wish for higher agility. It might be one or more of above examples.
And WHEN you know what is driving the decision, you need to decide what method and approach can best get you to the desired end-point.
Agile looks deceivingly simple, but….
Whether you will succeed in making e.g. Scrum, Kanban, or SAFe work in your context will depend on whether you and your colleagues succeed in changing the company culture, old habits, and – not least – your mindsets.
You don’t put on an agile shirt on Monday morning, and “bang!” you are agile. Changing behavior is a big thing, and affect people on the personal level. You might need to change habits that are 5-10-20 years old. This does not happen overnight. It takes practice, will, courage, and time.
Once you know why you want higher agility and how you intend to get there, you need to train people. No matter how simple Kanban, Scrum, or SAFe looks on the surface, they are all quite complicated systems. Getting a new method to work requires training at all levels in the organization.
Don’t fall into the trap of educating only a few Scrum Masters or Product Owners, or sending a few on a Kanban or SAFe training course. A few people don’t stand a chance when it comes to changing a company’s culture, habits etc.
Agile systems only work when managers know how to interact with their agile teams, when business people understand the need for their availability for prioritization, direction, etc., and agile teams know what is expected from them.
Going agile requires investments, stamina, and time. But the investments will be paid back many times, if only you have a bit of patience.
So to sum up: Do ‘go agile’ – it really works! – but do it consciously!