Executive Patterns: Becoming a Catalyst for Change

In our last newsletter, we conducted a poll asking the following question: “How much executive support do you get for your Agile initiative?” The results were encouraging, as 36% believed they were getting all the support they needed. The remaining 64% had some support, but could use more. Everyone that participated in the poll indicated that there was at least some involvement by their executives. As a coach having supported the adoption of Agile across several organizations, I usually see one of the following patterns when it comes to executive involvement.

The Impulsive Executive

“Greg” is very reactionary in nature and isn’t afraid to pull the trigger on new ideas. After attending a local class, he gets very excited about Agile. In fact, he decides that he wants to go “all-in” and that all teams should adopt Agile practices ASAP. This isn’t the first time for Greg to react this way, as it seems there is a new initiative coming from him every few months.

At first, it seems things are going well as the teams take on Greg’s mandate. After the newness wears off and the teams start running into challenges, Greg is already off searching for the next new thing. Without his support, it is determined that Agile is too hard and teams are better off doing what they did before. Some people are glad they didn’t commit too much effort to something that isn’t going to stick around. For others, it is just another frustrating “strategic initiative” from Greg and raises concerns about what new changes are just around the corner.

The Laissez-Faire Executive

People like “Jan” because she is very laid back and conservative in her approach. Her answer is always the same, “Do what you think is right”. If teams want to work on their own, so be it. If they want to try out a new methodology, practice or tool, go for it. Under Jan, teams can develop their own standards. It’s all up to them to do “what’s right”. They like the feeling of empowerment, but some team members are overwhelmed with the choices available to them and wish things were simpler.

One of the teams decides to adopt Agile, as its members believe it may be a lighter approach to project management. After struggling a little bit at first on their own, they start to make progress and begin to deliver great results. When they run into problems that they cannot resolve on their own, the answer from Jan is always “make it work”. The team does its best to work around the problems, but the biggest challenge is coordinating with other teams. Since the teams are using different methods, tools, and technical solutions, it becomes very difficult to integrate in order to deliver work together into the production environment. Because they can’t solve this larger problem, the team comes back with the recommendation that Agile would only work for very specific projects that are completely independent. Future projects decide not to adopt Agile because they are considered “too complex” to work with that approach.

The Misguided Executive

“Peter” always believes he is doing the right thing, though he gets frustrated that things don’t always work out the way he intended. Over time, Peter has become a little “gun shy” and is more careful about trying new things without addressing all of the risks. While he is excited about the possible outcomes that Agile could bring to his organization, he has also heard that it exposes potential challenges that need to be resolved.

He creates a group to investigate what needs to be done to do Agile successfully. After several weeks, they come back to Peter with a plan. To ensure success, they need to develop a specific methodology tailored to their organization with all of the best practices and tools that are recommended by the Agile community. Peter agrees to the recommendations and also adds another requirement. To save on potential licensing costs, he decides to start out small with a pilot, just in case it is a failure.

Several more months pass, the group develops the “perfect” methodology and all of the tools are in place. After some basic training on the process, the first pilot team is able to get started. Soon they struggle with how “Agile” works. The methodology is hard to understand and follow, the tools are difficult to fit into the process, and the training results in more questions than answers. Isn’t Agile supposed to be lightweight and focused on delivering software? It seems the team spends more time with the process and tools, leaving little time to deliver anything.

Peter originally thought that with Agile, the team would increase their productivity. After only a couple of sprints, the team has come to a halt. Given that he isn’t seeing the immediate results expected, he decides to terminate the pilot. He bans applying Agile to any future projects because of the significant time and money wasted over the last several months.

The Catalyzing Executive

Like others, “Cindy” is very excited about the benefits that her organization could receive from adopting Agile. However, she also has read enough and received advice from the community that Agile would require a significant organizational change.

Cindy realizes that if this change is going to stick, she needs to become a catalyst. As this catalyst, she knows she needs to provide a sense of urgency for others to buy-in to the idea.  She spends time with those on existing projects and helps them see how projects are taking longer, quality is down, and end users are not happy with what is being delivered. She realizes that through these discussions, she is acquiring other champions to further “the cause”. Cindy enlists the help of outside consultants to provide guidance through training and coaching. These coaches focus on reinforcing the principles behind Agile, so that teams can better understand how to adapt the process to get expected results.

Cindy takes an incremental approach to the adoption process by rolling out small waves of project teams at a pace that the organization can handle. She encourages everyone to take chances, try new things, and learn from the results. Cindy works with other managers to address things that are slowing teams down, such as complex processes, a variety of tools, and a lack of big picture thinking. They come up with streamlined automated processes, minimal use of a standard set of tools and technologies, and tighter alignment to strategy through technical and product roadmaps.

Because of Cindy’s efforts, real change is happening in her organization that not only benefits the teams delivering software using Agile methods, but extends to all areas that are learning how adapt to any changes that may come.

Does your executive fall into any of these scenarios?

Perhaps they are like Greg, Jan, and Peter and are less than thrilled with the results of Agile in your organization. Maybe they can learn from Cindy and consider a more direct and active approach to transforming the organization by introducing Agile practices. Want to become a catalyst like Cindy? Here are some questions that you should explore if you want to change the behaviors needed for Agile to “stick”:

  • The meaning of success—Does it mean meeting dates and budgets, or delivering on measurable objectives and delighting customers?
  • Punishment vs. reward—Are people punished for bearing bad news, or rewarded for providing opportunities for learning and improvement?
  • Competition vs. collaboration—Are they rewarded for heroic efforts in a competitive environment, or for working well with others?
  • Decision making—Are decisions made by committee, or are they delegated to those closest to the problem?
  • Time allocation—Is the majority of time spent thinking about what should be done in meetings, or getting the work done?
  • Isolation vs. group thinking—Are you working in a “heads down” environment, or a place where people can interact and share ideas?
  • The elephants in the room—Is most of the time spent working around organizational impediments, or removing them?
  • Multi-tasking—Are team members juggling many projects at once, or are they working on a single, prioritized project at a time?
  • Time for innovation—Do people have to learn on their own time, or are research, training, and experimentation encouraged?