Agile Transformation — Gaining Executive Leadership Support

As an executive leader, I know Agile can produce great results. Why would I not want to jump on board the bandwagon? My organization can do more with the same amount of people. All we need to do is change some processes that we use.  

I encourage or direct my groups to implement a new framework to accelerate all the above improvements and come back to me with a budget for what it will take. The opposite side of the coin can also be proper. Why would executives expect that implementing Agile would take this level of change? Did anyone tell them how the organization needs to change and how much they will need to be involved in the transformation? Probably not.  

Leaders usually request funds for training but need help getting the education behind what it will take to succeed. At a high level, the executives expected that they would have to train their people and they would instantly become Agile.  

They didn’t know that a mindset from the executives down to the recently hired needs to change, and it’s the executive's job to lead that transformation. The executives are the only people in the organization that can pivot without mercy or guilt and steer the ship in a new direction.

Leadership participation is necessary; however, comprehending the change management that needs to occur is paramount.

Many organizations will start small and implement Agile or Scrum in a few teams to see how it works. There are many eyes on this in these experiments. You have two specialty roles in Scrum: the Product Manager and the Scrum Master. The rest of the team members are called developers. A developer is an all-encompassing, cross-functional name that covers development, design, and testing.  

The Scrum team is supposed to be self-organizing and self-leading. This is fine until external dependencies with other teams are not working on the same priority or schedule. This is an example where if the organization was all on the same page and the leadership led the transformation, the scrum teams could work much better and not be slowed down by these impediments.  

The scrum teams continue to work well until the point where the organization has not changed slows them down. This is also where the naysayers, even those in the Agile Teams, say Agile will not work.
Another example is the product owner (PO), who should own the team's backlog of work. The PO will create stories and prioritize the work the team should be working on. Unfortunately, they could be working in a functional silo and be unaware or not in sync with the Product Management team's needs and priorities. On top of the impediments already identified, the team will still be required to follow the governance around deployment and release. The beauty of a Scrum team is that the team should be able to make the decisions and deploy their work.  

The organization's release management may be set up to only minor monthly releases and quarterly product updates. This again adds more delays to the overall cycle time of the team.  Additionally, the metrics the team may need to capture for the enterprise may no longer align with their framework. The Scrum teams feel powerless and unable to communicate upward to effect the necessary change.

If someone is brave enough to address the concerns of the Scrum teams with the executives, they will most likely state that they have always supported what the team has asked for. In the mind of the executives, they paid for the retraining of the Scrum teams to act differently. The executives had no concept that they would need to change and effect it across the ecosystem to allow these Scrum teams to succeed.  

The Scrum teams see the executives as not supporting them. The executive feels that they did what was asked for. Where is the disconnect? The Executives were at A, and the Scrum Teams were at Z, but the organization never went through B to Y, nor did anyone tell them they needed to. What would be worse is that the organization knew they needed to do B to Y but chose not to because the executives were not leading them to do so.

The most important question is, how do you make the executives want to lead the organization through steps B to Y? That is an easy answer, find out what is most valuable to them that you know you can deliver by implementing Scrum. For instance, SAFe promotes implementing the outcome of predictability above everything else. If you have predictability, you will naturally improve the speed to market, engagement, productivity, and quality of the products you deliver.  

If you take a lean approach to eliminate or lessen waste in our processes, productivity and market speed will increase. How do you lessen or eliminate waste? An example may be empowering your Scrum teams to deploy on their own. Another example may be having dependent teams working together in cadence and synchronization. 

The Scrum teams see the executives as not supporting them. The executive feels that they did what was asked for. Where is the disconnect? The Executives were at A, and the Scrum Teams were at Z, but the organization never went through B to Y, nor did anyone tell them they needed to. What would be worse is that the organization knew they needed to do B to Y but chose not to because the executives were not leading them to do so.

Leaders must pay more attention to how long these process changes can take. Every organization is different, and no exact estimate works well across all. Bringing in trainers is an excellent first step, but what do you do once the team is out of training? The organization needs to understand that a rebuild of the way the organization works may be in order. A coaching group that leads organizations through what needs to be done and what needs to be accomplished is paramount. Please reach out to an experienced Agile Coaching organization.