Several years ago I worked with a management team that wanted to implement Scrum in their organization. At the time I was a trainer and coach for scrum teams.
The plan was to implement Scrum for the software, electronics, and mechatronics engineering teams. Because of leading by example I started with the management team.
It didn’t take long before I ran into resistance. Not surprisingly, some managers tried to convince me that the stand-up meeting wasn’t for them and that they could skip it. Additionally, they were sure it was impossible to get all of them into a room at the same time every day.
I challenged them and asked: “What do you mean? You’re trying to convince me you are not in control of your own calendars?” Next, I asked them to commit to a two-week experiment. This gave them a safe exit strategy. After the two weeks, we would evaluate the situation, and they could stop if they still thought the standup meeting didn’t add value. The experiment was accepted for three days a week. Not precisely what scrum prescribes, but good enough to get started.
It soon turned out the standup meeting was the most valuable meeting the team had in years. In the first few days, they learned how little aligned they were. Someone was organizing a workshop, and another manager was trying to do the same thing. They weren’t even aware of each other’s work. It didn’t take the entire two weeks to learn that a lot of the confusions in the engineering teams was caused by mixed messages from the management team.
The standup meeting helped them to learn what each one of them was doing (and why). One of the managers noted that it was saving him a lot of time. The standup meeting was taking less time out of his calendar than several lengthy progress meetings (not to say that the standup meeting is a progress meeting, it’s not). Additionally, it gave him more insights into what everyone was doing and what needed attention.
The experiment was a success. I didn’t need to convince the management team to continue. After a while, it became clear that the managers were speaking more with one voice to the engineering teams and hence required less time for damage control and course correction. One additional win was that they were leading by example. Their engineering teams much appreciated seeing that their management team also was doing Scrum.
The moral of this story is that you should not see agile as a Happy Meal where you pick and choose what you consume. You might actually miss out on something that valuable and never know it.