Middle Management — Infinite War
Sometimes work is not about what’s right. Sometimes work is about who is right. In corporate life the interpretation of being right lies beyond anything that’s measurable and beyond what people would call facts. It lies somewhere in between the ladder’s steps and b-vitamins.
My story starts where common sense has stopped. Once upon a time, I thought being a Scrum Master would be easy going. I thought I could focus on my team first, then watch out for some pitfalls in their close environment, and finally add some agility on the organizational level. The question I asked myself was pretty simple. A question a (supposedly) good Scrum Master would ask in a corporation on the verge of starting their first agile projects.
How can I make a group of people become a team?
It was their first time working in a Scrum team, for some the first time of working in a team at all. We had a few rules we needed to follow. We had to use Scrum as a framework and we had to keep up with the other teams by working 2-week sprints. Everything else would be up to us, probably a great chance for a greenfield approach in self organization. And even though we started working in the commanded iteration times, we managed to do a retrospective every week. I could use these retros for coaching and team building. There wasn’t too much of a process, yet, therefore I could focus on the team getting to know each other and getting to know the new practices and the framework they had to use. Every once in a while I tried to mention, that it’s not the best approach to start with a framework instead of building a mindset. But being aware of this fact, the team managed to develop an agile mindset themselves. A little naïve, a little unexperienced, but still better than one would expect in a super-conservative corporate environment.
One thing, I have not mentioned yet, is that the team was with our client. Thus, me and two of the developers joined the team as externals. But no worries, the team worked pretty well on an interpersonal level, we all got along very, very well. As I’m a big fan of the Laloux cultural model, I decided I’d take my team a step further. Whereas the agile movement — especially Scrum — is based on values such as respect or courage, I wanted to have the team a set of rules and guidelines that are not too interpretable. In one of the first retrospectives, I asked two questions. What does the best team you can imagine do? What does the worst team you can imagine do? I had them work in two groups on these questions and present have them present the results to each other. Based on the results, I asked them to work together on a team manifesto covering three topics: values, goals, what to avoid. Values in this case wouldn’t be as openly formulated but rather be more tangible as in the manifesto for agile software development. Goals would be things the team strives for to achieve or even keep up. And stuff to avoid, well, would be stuff they wanted to avoid within the team.
The team came up with what they valued the most and we hung the manifesto in our room to have it visible for new members but also to keep an eye on transparency and even on how we would live this manifesto ourselves. As I mentioned, our team consisted of two different companies. Therefore, the first value stated “belonging to the team over belonging to a company,” to emphasize on delivering value for the project before following (hidden) company-internal agendas that might cause trouble between team members.
What would you expect to happen next? Exactly.
A large corporation preaching about scaling agile and creating environments suitable for multidisciplinary teams, even trying to talk about value streams and product focus can’t cope with a single team representing shared values as a team. After I left the project, I found that middle management was not able to handle our team manifesto. It somehow (quote) left a sour taste in their mouth. (Based on assumption from here on…) I guess only a one-way transparency happened. They read the manifesto but never talked to the people who wrote it. Instead, they would immediately escalate a misinterpretation (or as it’s called in the Trump era: their version of the truth) of the manifesto to some higher ranked officials. They, as in “we don’t want things to change,” would try to create a misconception of agile software development. They would goad on other middle management people to also embrace all negative aspects they would find around all teams. They would try to protect their comfortable chairs instead of developing a growth mindset that would help them handle the new challenges instead of condemning them.They’d rather send some more emails attached in emails (yes, attached — not forwarded) to protect their stand and involve random people along their hierarchy instead of communicating directly with the actual people involved. They would rather start an infinite war to contain the little sparks of agility instead of letting change happen to be prepared for the next 10 years to come.
But I guess that’s evolution. Some companies will evolve, some will not. Some will understand, some will not. Some will finally be agile enough, some will not.
