Develop Agility for business reasons
If your company is making shoes, then the Agile transformation should improve selling or making shoes. As Peter Drucker once said, "companies don't make money, they make shoes." At all times you must be able to provide an articulate answer to the question "how does Agility improve our business?".
"If your company is making shoes, then the Agile transformation should improve selling or making shoes."
Too often the Agile transformation is initiated for fuzzy reasons not really connected with business imperatives. Sometimes we want to "do Agile" just because the company next-door is doing it. On other occasions the need for Agility only addresses a local issue such as "we must deliver this project faster" and fails to connect to concrete business reasons. Obviously, if it is disconnected from business reasons then it has little chance to impact the business in a lasting way, which should be the goal of any transformation.
Consider this good example of the need for Agility inspired by one of my clients: "Our growth is declining by 5% per year because our banking products and channels are not attractive to growing customer segments such as millennials. We have shifted at strategic level but execution does not follow fast enough. We still have tedious annual budgeting, big projects for which we want to understand everything upfront, and rigid governance consisting in several committees involved in micro decisions. Our ability to deliver value fast and pivot is very limited."
You can see that the person has given serious thought about why Agility matters for the organization and how it could address real business challenges. We should strive to reach this kind of statement from day one in order to set the transformation wheel in motion.
How do we achieve this concretely?
Have the Agile transformation expert interview key stakeholders to understand why agility matters for them, what is their perception of Agility, and what is their sense of urgency. The interview process will also help establish trust between the Agile transformation expert and key stakeholders.
Design a simple visual connecting agile capabilities with business challenges. This visual also helps define what Agility means for the organization. Indeed although Agile puts forward a common set of principles, context is king and Agility should always be defined within a context. In particular, by explicitly linking Agility with business challenges, we avoid the typical pitfall that stakeholders believe Agility is limited to IT teams doing Scrum. Below is an example for a Telecom organization, based on Agility Board's four A's framework.
Then have the Agile transformation expert run a workshop to present findings - which are but hypotheses at this point - and elicit a shared vision, sense of purpose and urgency with key stakeholders.
Grounding the Agile transformation in compelling business reasons creates awareness and desire to transform, which incidentally are the two first steps of the ADKAR model (awareness, desire, knowledge, ability, reinforcement).
What could happen if we don't do this at the start?
Stakeholders will have different perceptions of the business situation (awareness), vastly diverging views on Agility (from Scrum to strategic agility and everything in-between), and varying degrees of desire to take action (from "looks interesting, we should think about it someday" to "we must do it now, we're already late"). As a consequence, the transformation will probably not hold or will be severely downsized to the point of not being transformational anymore. Remember that in a system made of interconnected people, the pace and depth of change will usually be set by the slowest, least committed among key stakeholders.