managers can become leaders
but expect it to be hard on everyone
My clients often expect me to solve all of their problems by helping them adopt agile ways of working (and usually, that means Scrum). They have fallen in love with all of the buzz about agile without taking the time to understand why agile is as successful as so many of us in the community claim it is. There is so much that is different about working with agility from more traditional leadership and project management styles, but what many managers hear is, ‘More, cheaper, faster.’ As a result, they don’t understand the differences and their part to play in the changes required.
Traditionally, managers are used to hearing bad things at the end of a project. In their experience, when someone has brought bad news to them before the end of the project, then that news must be catastrophic. I’m certain that to many minds, the earlier they hear bad news, the worse that news must be. This is somewhat problematic to the cultural change piece that agile transformations have to handle. After all, Scrum (agile) won’t solve your problems, but it will make them visible.
To the mind of an agilist (and surely to anyone who thinks rationally rather than reactionarily), as soon as anyone in a project is aware of a potential issue or risk, that awareness should be shared as widely as possible. It may be that the person who discovered it knows how to solve it, but it’s just as likely that they are not in a position to be able to do so. Surely it is better to find out that we are at risk of not meeting a deadline four months before and not the week before. Not only is there more chance that we can handle the risk, but it also helps us to avoid building around it and making it an even more considerable risk.
On more than one occasion, I have seen managers who recently (and sometimes not so recently) have been thrown into agile ways of working getting very nervous when it is suggested that talking about the risk to the wider organisation is a necessity. Scrum values transparency. Agile values customer collaboration. We want to share our potentially bad news with as many people as is reasonable so that we can access all the possible solutions. A risk being surfaced could result in anything from the customer saying that part of the system isn’t so important given the new knowledge, to an entire package of work needing extra talent and resources to tackle it. Either way, you’re going to need time to mitigate it.
Management and leadership need to be strong at this point. It’s all well and good to ask teams to improve their agility, but the whole organisation must also improve to facilitate the teams. Agile is all or nothing within its value stream. If some point of the process wants or needs to be agile, then the whole process will have to adapt too. Management has to support the teams to resolve risks and issues, and not criticise that risks and issues exist. We all know that projects, especially those complex and complicated ones in which agile thrives, have emerging problems. Leadership teams must learn to be supportive and grateful that teams have come for the benefit of their expertise and authority.
Scrum aims to give much more information than traditional project management status update meetings do. If you want to know how the project is going, you only need to turn up to the right place at the right time. Find out from the source what is happening, and invite any interested parties to join meetings such as the sprint review regularly so that they also hear what’s happening and don’t fall for Chinese whispers. If you hear something along the rumour mill that doesn’t sound right, then it’s time to show some curiosity. The first reactions of leaders set the tone for how a team goes about finding the solution.
Unfortunately, what so often happens is that managers revert to type. They buy into the fear, anger, and whatever other emotions are on display from stakeholders, and with little to no thought about how their perception deviates from reality, they start throwing their weight around and passing the emotion on down the chain of command. They attempt to generate solutions rather than understanding the problem, and dictate what needs to happen, how it has to happen, and of course, that it should have happened yesterday.
This behaviour is completely understandable, but ultimately counter productive. Expressing such negativity, even only mildly, will cause a stress response in most people. This means a rise in cortisol levels, which blocks off their ability to access higher brain functions. (That’s where creativity happens.) We all have to ride stress occasionally; I’m certainly not advocating a stress free life. However, if you want the best out of your creative workforce, you need to create an environment where they can be their most creative. When managers cause repeated amounts of stress like this, it impacts people’s physical health. I don’t think any of the managers I’ve met want to make other people ill, yet they continue to do so without realising it.
And during an agile transformation? Then we take this to the systemic level. When managers show this response to ‘bad news’, then people understand that bad news shouldn’t be broadcast. After all, why would anyone choose to go through such a stressful situation repeatedly when they could just keep quiet about the risks and issues along the way and deliver them in one go at the end? This can almost instantly shut down any progress towards agility. If there’s no psychological safety, then there can be no agility.
When an organisation really wants to embrace agility, it can only do so with the support of its managers. The Scrum Guide hints at this by talking about how a Scrum Master serves the wider organisation, and the same is true for Agile Coaches. (What are Agile Coaches, if not Scrum Masters floating around an organisation unanchored to a team?) I still find this one of the hardest parts of the role. Like so many I know, I am thoroughly triggered when managers come knocking on the door with all kinds of assertions that are only vaguely based in reality. Having the self-awareness and self-control to take a step back and realise this dysfunctional behaviour is the system declaring itself unable to cope takes a lot of time and energy that most of us would rather put directly towards building a successful thing.
And so to what our role needs to be in this situation. I’ve tried covering my head with pillows, and it wasn’t very successful (though it did comfort me for all of five minutes). At Barefoot Coaching, I was taught to be a non-directive coach. I’m glad I learned how to avoid guiding people through something I thought was beneficial for them because it also taught me how to guide people through something I think is beneficial for them. Agile coaching is much more directive than pure business coaching. We are here to show people how to do things in a way that is aligned with the agile manifesto.
If I don’t see what I should be, then it’s time to coach by demonstration. We need to take time to sit with the managers and guide them through a process of curiosity, so they can learn to stay calm and dispassionate when confronted with potentially stressful situations. Hopefully, your team’s product backlog is up to scratch so that you can walk them through current and upcoming events. Show these potential leaders how any risks and issues have revealed themselves to the team, what you’re currently doing to mitigate them and how they can support you in doing so, and give them the narrative that it’s ok to be talking about these things at any point of time in a project (but hopefully at the moment you find out about them).