There is no Shame in "Wagile":The Challenges of Introducing Agile into a Corporate Environment

Nichole Brinsmead, Director, Enterprise Applications and Transformation, PWC Australia

Nichole Brinsmead, Director, Enterprise Applications and Transformation, PWC Australia

Agile is not a new concept, it’s been around as an approach to software development for 15 years. At its core, it promotes concepts such as minimum viable product (MVP) and eliminating activities that don’t contribute to working software principles all geared towards delivering value to customers more efficiently than waterfall techniques. Trying to move to an agile methodology from a traditional waterfall project environment can be a monumental task. However, if you have the fortitude, the commitment, and willingness to make concessions to the purist principles of agile then here are my six tips for those thinking about making the shift to agile.

1. Agile is a cultural change, so have a well articulated and compelling reason to change

Agile is not just a software development methodology, it’s a mindset and a culture. It needs to be tackled with the same rigor as when starting any cultural change. Have a clear and compelling vision on why you want to adopt change, be clear on the outcomes you are looking for.

2. Agile is a whole of organizational change, not just a technology thing

Adoption of agile can be a lot more successful if it’s driven by the business teams rather than IT alone. Whatever the source, you’ll need a strong business sponsor, even evangelist, to be actively advocating for it across the organization.

3. Be agile with your agile implementation

Today’s various agile approaches have adopted a lot of principles from “lean”, and many people use the words agile and lean interchangeably. At the heart of “lean” is incremental continuous improvement and the removal of waste in your processes. In some cases it’s actually lean you want to adopt rather than a different approach to delivering value through software development. Regardless, approach your agile/lean adoption with small incremental steps of continuous improvement.

4. As a leader, protect your teams from over-bearing corporate governance

It can be difficult to provide your organization’s governance bodies with upfront evidence on how an agile methodology will deliver organizational benefits and value to your customers. Agile can demonstrate value but it generally doesn’t do so in the same way that an organization is set up to track. Unless governance processes are adapted, delivering agile projects is very challenging, which is why “wagile” (waterfall agile) is a common project delivery methodology in many organizations. As a leader, your job becomes the interpreter and mediator between your agile project teams and the governance bodies that want to ensure you are managing your budget, scope and benefits.

5. Don’t underestimate the need for good old fashion stakeholder management

The obvious resisters to agile adoption are generally those who govern the processes that are in place today. At an individual level people intellectually understand and embrace the concepts. However, when applying governance processes resisters will challenge agile approaches. The likely suspects such as those in finance, audit, risk will need close stakeholder attention. The ones that can take you by surprise are teams like enterprise architecture, HR, change managers and senior technology managers. When groups perceive “their” responsibilities have been taken over by agile teams or that their policies are challenged they will naturally resist: one person's empowerment is another’s loss of authority. Keep these people close as they can be powerful enablers.

6. Accept that there is no shame in “Wagile”

Most of the agile purists whose blogs you are reading have probably never had to face an audit committee or a funding board and are generally operating in small to medium size organisations. The type of governance structures you find in large organisations and highly regulated industries find it difficult to make large-scale commitment to an agile approach. Highly governed organisations take comfort in documentation that “proves” that the enterprise is managing risk and investing wisely. When first embarking on an agile approach, the creation of this documentation is hard to justify since it’s seen as waste: in other words, not contributing to working software. This is why I believe there is no shame in Wagile, a hybrid of waterfall and agile methodologies. I have seen it work effectively in large organisations where you can satisfy both the need to justify investment upfront, and the creative desire of the business and technology teams to deliver value as quickly as possible. It takes good stakeholder management, resilience and an unshakable faith that an agile approach will deliver more value to your customers and stakeholders than the traditional ways of doing things.

The agile community has recognised that it needs its methods to scale if an agile approach to software development is going to be embraced and implemented successfully in larger organisations. The release of the Scaled Agile Framework (SAF) is an example of this. Agile and lean methods will provide a better and efficient business outcome, but it can only do this at scale if the broader realities of the organisation are addressed. As waterfall isn’t going away anytime soon, “Wagile” can be a highly effective synthesis of the old and the new, and there is no shame in it.