Talking Agile with the C-Suite
SPONSORED BY NUTANIX
Have you been given the task of suggesting to the C-Suite that it should consider becoming an Agile company? Handled well, it could change your company’s fortunes and make for a better life for its employees. That assumes that your fellow directors buy into the idea. If they have already supported the implementation of Agile for software development and seen good results, your foot is already in the door. With no internal experience of Agile, your challenge is somewhat greater.
Start-up companies have something of an advantage; they can adopt an agile approach from the start. The senior management habitually call in expertise from wherever it’s needed—from other managers and from customers, for example—to form their strategies. They are motivated by delighting their customers as opposed to delighting their shareholders; shareholder value increases as a function of customer delight, rather than it being the primary driver of the business. The important thing when starting any Agile discussions with the C-Suite is to avoid being seen as an evangelist or a zealot.
Nothing will raise barriers more quickly. It’s probably best to admit that this isn’t a silver bullet quick fix. It will take time and it may be that, like Microsoft, the journey will involve a long period of concurrent work practices. There, Agile started in one development department, then spread to three, then 25, then suffused the entire development division. The head of that division then took over as CEO and mandated the spread of Agile through the company. The journey in total was about ten years.
Once the directors realize that they’re in for a calm and reasoned discussion, you can introduce the benefits of Agile. Make sure you relate them to business concerns such as faster time to revenue, improved customer satisfaction, cost savings, delivering increased value, and a greater chance of success. The fundamental difference is a switch from a mechanical approach to delivering results to an organic one. The first works on fixed specifications and “efficient” adherence to that, even though the customer needs may alter over time.
The second focuses on close involvement with the customer and regular “effective” delivery of usable work in progress. With the first, problems aren’t spotted until testing against the specifications, by which time changes are difficult to implement and a further considerable expense. With the second, issues are spotted early and the project details can be altered even if the overall trajectory remains the same. With pricing based on time and materials with a cap on the total, the project will go further, faster, and deliver more value to the customer. In all probability, the customer will authorize further payments largely thanks to the evidence of results and the trust that has grown between the companies. In fact, “continuous improvement” is a hallmark of both internally and externally focused Agile projects.
The C-Suite will need some idea of how Agile working differs from conventional working. The key concept is that teams are cross-functional and self-managed. An example of this is in global bank, ING. One of its teams (squads in ING speak) comprised people from Marketing, Commercial, User Experience, Data Analysis, and IT Engineers.
Through open and transparent collaboration, they were able to guide their project without needing to refer to external managers for approval or instructions.
Apart from being able to deliver results quickly, the squad members were highly motivated and fulfilled thanks to the sense of ownership of their part of the overall project and the fact they were focused on delivering value to the customer (probably internal in this particular instance). In general, this feels a lot better for team members than being part of a hierarchical organization that puts making money for shareholders front and center of their ambitions.
The broader-level direction for the squads comes from their membership of a “tribe.” At that level, priorities are determined, and the work distributed in small chunks to the squads. Each company will decide on how best to organize its projects but the working principles from top to bottom have to adhere to the “Agile way.” Information needs to flow directly to where it’s needed and not be passed through intermediaries. Any lapse back to the old hierarchical approach would threaten accusations of hypocrisy and a consequent dip in morale and enthusiasm.
“Bosses” in the old sense need to switch to becoming helpers and facilitators. Expect their transition to the new mindset to take time—probably months rather than weeks. When it comes to C-Suite leadership of Agile, the Forbes Insights team examined what it takes to become an Agile C-level executive:
- 83% An Agile mindset/flexibility
- 79% Ability to manage and attract talent
- 76% Be a great communicator
CxOs can’t change their mindsets by reading white papers or attending seminars; it has to come from within as the result of seeing Agile in action and coming to acknowledge that this is the best way for their company to proceed.
Agile has been around for twenty years and even before that under other names. The big difference now is that we are all so interconnected, it is much easier to collaborate and share, both inside and outside the organization. We can see changes in the marketplaces and adapt to them. Companies who lost out include Blockbuster, BlackBerry, and Nokia, while those who adapted include Apple, Amazon, and Microsoft. Agile doesn’t guarantee success but it greatly improves the odds. Figures from Standish Group (software-focused) suggest that Agile projects failed (that means abandoned or not used) just eight percent of the time while, for Waterfall ones, the figure is 26 percent. In terms of total success, the figures are 42 percent for Agile and 26 percent for Waterfall. With the Agile facts and stories from the field laid in front of them, the C-Suite will be better empowered to know whether Agile is for them. Or not. And that’s where you come in.