One of the most common myths about Agile and Scrum is that it’s something that only affects the developers. People, in particular executives and directors, believe that undertaking an Agile transformation means project teams change the way they work together and the rest of the organization just reaps the benefits. While this may be true in the short term, it’s often leadership and management that have to make the biggest changes for Scrum to be successful.
I was inspired to write this post after a chat with a friend who works in an organization that has been using Scrum for a few years. He told me that it didn’t take long for the weaker leaders to struggle as the organization adopted Scrum. He also said that the changes to how teams worked and were led created natural leaders who stepped forward and took the reins, sometimes even people no one expected.
I’m going to explain this with a rather facile example.
A meal is needed for an event. The chef collects information about the context and theme of the meal, budget constraints, dietary requirements and preferences of the customers, the skills of his team and the materials available. Based on this analysis he decides that the meal will be vegetarian pizza with no olives. He develops a list of tasks such as acquiring the ingredients, preparing and delivering the meal, and cleaning the kitchen and works with his team to get them done.
A meal is needed for an event. The chef collects information about the context and theme of the meal, the budget constraints, dietary requirements and preferences of the customers, the skills of her team and the materials available. She sits down with the team and provides this information. The team brainstorms some ideas. The chef goes back to the client with a few additional questions the team came up with. The team agrees to make 2 varieties of vegetable curry, one spicy and one mild, with na’an bread on the side. The team and the chef develop a list of tasks such as acquiring the ingredients, preparing and delivering the meal, and cleaning the kitchen.
The first example is the way we all expect to work. The second is subtly different, but it’s how leadership has to work in a Scrum environment, and for some people it’s a very difficult shift.
First of all, leaders who feel that their value in the organization is their expertise in devising solutions often feel that their importance has diminished in Scrum. They’re right to some extent. Instead of relying on the creativity and innovation of a small number of experts, Scrum leverages the creativity, knowledge and collaboration of the teams. Leaders identify areas where the team can provide value, they communicate clearly what the vision and constraints are, and then leave the solutions to the team.
Second, it’s not just the team members who have to emphasize face-to-face communication in Scrum. The friend I mentioned is on the leadership team for an effort that involves multiple scrum teams that reside in Quebec and Alberta, two time zones apart. He spends most of his days attending sprint planning meetings, sprint reviews, team design meetings and even daily scrums. He also does his best to be accessible at all times to answer questions and provide clarification on the vision and constraints. It might sound like he’s a product owner, but he’s not. He works with product owners, but he’s a producer. This is a hard adjustment for some leaders to make, if they’re coming from a role where they spent most of their time in their office and in meetings with other leaders.
Third, and probably the hardest to tackle, is that the leadership has to foster a relationship of trust. Teams need to feel comfortable enough to propose and explore new ideas without risk of being judged if the idea fails or is in adequate. Teams also need to know that the direction provided by the leadership is reliable, which means that the leadership has to maintain a level of openness with the teams about not just what the vision is, but why. Leadership also needs to be accountable for mistakes.
There is a lot more to say on this subject, more than can be written in a blog post. Part of the reason that leadership has to change its style is that Scrum, and other Agile techniques, often require some flattening of organizational hierarchy in order to improve communication and collaboration. It’s also easy to spout catch phrases like “learn to lead, not manage” and “open all channels of communication” but harder to find practical ways to execute this in the real world. However, if an organization wants to enjoy the benefits of being agile, its leadership had best be strong and willing to change its style.
Why are requirements so hard? 