Hello manager. We might know each other, or we might not. In the end, it would not make a difference. Because, no matter if we knew each other or not, there would be things I’d be hiding for you. That might sound strange to you. There is a big change you see yourself as a person everyone can talk to, every time they need it. No matter how much you believe this, I don’t have the feeling this is the case. And there is a big change a lot of people that work for you will share the same feeling. No, it’s not you. It’s Agile. I love Agile. But Agile and managers, it’s just very often a difficult situation.
What I would like to tell managers about Agile
Trust
Almost every Agile method and maybe even every method is based on the trust in the Agile team. An Agile team should be able to work mostly independently of you, the manager. Make their own decisions, determine their way of working. In theory, it sounds perfect. And with an experienced, good working Agile team it will probably work.
What I see is that managers like you most of the time take one of the following positions: you either completely trust the team or you either completely don’t. In the first situation, when there are problems, you follow Agile to the letter when it comes to independence. But if a team is not experienced enough to handle problems the right way, people have no one and nowhere to turn to. In the other situation, you completely don’t trust the team. You keep an eye on them all the time. You are probably right that the team is not experienced enough. But if you keep telling them what to do, how to plan, and solve every problem for them, they will never get the experience to be independent.
The improver
When you want to introduce an Agile method or want to improve this way of working, most of the time you will not have the time to do that. So you will find an improver. Most likely you will choose someone that is not too critical of the changes you want. That’s understandable, since giving improvements to someone that doesn’t want them, will probably not lead to a good result.
The problem is that a lot of people who are not too critical, will often not feel responsible for the result of the improvement. Yes, they will do what you ask them. But when there are complaints, objections, downsides (and I only mean the ones that are true), they might not handle them. Their goal might be too much to do what the manager or the Agile method tells them to do. Not to improve the company.
People who feel responsible for the result, often are critical. And because of that will ask questions. And make the start of the improvement very well a lot more difficult. But when they start the improvement process, they will not only do what they are told, they will also make sure it’s really an improvement for the company. Because they don’t want an Agile company. They want good working teams, a good product, and/or reliable planning.
No step-by-step handbook
Most things you learn in IT you learn step-by-step. When you program or test you begin with something easy. And then, step-by-step, it becomes more difficult. And a lot of learning in IT is done the same way.
Except for Agile methods. As far as I know, all Agile methods force teams and managers to adapt every part of the method at once. And being Agile is very difficult to learn. Both for you as a manager and for the persons in the Agile team.
Yes, you can hire an expert to help you. But even then people will have to learn a lot of difficult things at once. They might succeed as long as the expert is present. But when the expert is gone, they might not be able to anymore.
And because it is difficult, you or your employees might want to make it easier. Skip steps, make meetings shorter, or get fewer people involved. But, since you and your employees are not so experienced, you might miss the benefits of the steps, long meetings of involvement of a lot of people. And the weighing of downsides and benefits might not be properly done.
Why I don’t tell managers
Distance
Agile is a method without managers. This is on purpose. But it creates extra distance between a manager and his/her employees. When you, as a manager, have to approve every decision and every problem is discussed with you, you probably have a lot of contact with a lot of people. If teams make their own decisions and solve their own problems, there is almost no reason to talk to you. So you become the person they don’t know. And that is a difficult person to go to when there is a need.
Safety
I have had good managers and bad managers. But even with good managers, I found it difficult to feel safe talking to them. Safety for me is a combination of the right persons, the right place, and the right way.
I know you probably expect me to ask questions during the general meeting, either for the whole company or the whole department. But those meetings are not safe. I have only 1 minute to ask a question. The answer also can not be too long. And when I don’t agree, it’s not the place to discuss it in detail. Because of all that, it’s not the best place to mention problems.
But, you are probably thinking: ‘you can always come to me with problems and questions’. You are probably right, but do you understand that ‘problem meetings’ are not safe either? A safe meeting is a meeting where both the good and the bad are discussed. This is to prevent a person from becoming ‘the person that is always negative’. When I come to you once with problems, no, there are no problems. But if most of our conversations are about things that go wrong, it’s not going to give a good impression of me. The problem for me is: when things are not going wrong, I might not have a reason to talk to you. So how can I let you know that part?
Official knowledge
I have around 15 years of experience in Agile. I’ve seen teams fail and teams succeed. And, because of that, I’ve seen what has worked and what has not. But officially I have no real Agile knowledge. I’ve not been a Scrum Master or Agile coach. I have not had an education in ‘How to introduce Agile in the company’ or ‘How to make a team more Agile’. Most of the time I was ‘just the tester’.
When you, as a manager, want someone to tell you what is right or wrong in the Agile ways of the company, you are probably going to look for someone who had the right functions or the right certificates. I don’t have that. So, when I talk to you about Agile, you might not be open to it. Because, looking at my CV, I do not have official qualifications to tell you how Agile works.
No answer
I would really like to give you an answer that solves all of these problems. But I know I can’t. And I know I shouldn’t. I can make you aware, but you have to find your own solutions. While I do know things that help, I’ve never worked for a company that solved one of the mentioned problems completely. It’s very likely that is not even possible.
Also, if you ever want to be truly Agile, you should learn to solve these problems yourself. In a way that works for you and for your employees. Just like your employees have to learn in their teams. You have to learn how to really see if the solution has the desired effect. And has no unexpected downsides. Just like your employees have to learn in their teams. You have to learn the exact same things as your employees have to learn. And I hope you will help each other see improvements and see mistakes. Good luck!