#93-Empowering the Agile Champion

An Agile Champion within a Waterfall Organization needs assistance, and that may have to come from you.  I'll discuss this week various approaches I've taken to accomplish this

Transcript

Empowering the Agile Champion in a Waterfall Organization 

As a consultant, when I've been brought in to assist with an agile transformation, I always know that there is someone within the organization, at least one individual, who is championing this effort and needs some assistance. 

If you are not a consultant but have caught wind of the fact that your organization is contemplating such a transformation then almost certainly there is someone, somewhere that has decided agile is a good idea. If you agree then you may wish to lend them a hand.

This “agile champion” will almost certainly be familiar with the agile manifesto, may have gone through an agile transformation in a previous job, and now in the current situation is dealing with fixed scopes, predetermined project measurements, and strict gating before progress can be made. 

In my experience, they're likely encountering difficulties because they've made some pretty classic mistakes. Very often they will have decided that simply forcing scrum ceremonies on the team, renaming the project manager as the Scrum Master, and changing the language used at meetings is all that's needed to make agile successful. What they will run into is resistance to change, which is very much a part of human nature. 

If they truly want to champion the agile transformation, then it should be made clear to them that they need to model agility to the organization even before the systemic elements are ready to change. 

This is because the real problem is that waterfall organizations have momentum that has built up over time. This momentum rewards compliance over curiosity, adhering to a plan over responding to evidence, and predictability as more important than continuous learning. Trying to fight that momentum directly will usually lead to a burnout or to the person being reassigned, or even let go. 

The agile champion typically does not have the authority needed to make the organization change, but they can obtain leverage. I will provide some examples here of different ways they can do that, but I'll acknowledge that this often has to be taken on a case-by-case basis. 

The first leverage point that is almost certain to meet with little or no resistance is to increase the visibility of the work. Visual information radiators, metrics about the flow of value through the system, and a clear indication of the definition of done from an agile perspective, are all things that management can benefit from and will appreciate. At this point they should stay away from the word agile entirely but simply point out that they are seeking to make it possible for management to have a clearer view of where the work currently stands. This visibility builds trust, and once trust is established there may be room to experiment. 

I strongly recommend that the agile champion does not try to promote agile processes as creating velocity. It's not only because that's not always true but also because waterfall leadership is not looking for velocity, it is looking for predictability. So agility should be reframed as earlier feedback, smaller commitments, and a more rapid detection and correction of failure. 

This becomes a leverage point too because these are all things that management will value inherently. Also, if you can emphasize the importance of strong teamwork then all you need is permission to empower the team. Once you have that you can help each team self-organize within the constraints imposed on them, they can be encouraged to own outcomes not just complete tasks, and you can create psychological safety allowing them to raise issues early. This empowerment will increase the success of the team, and this competence will earn credibility. 

My final leverage point is to act like a bilingual translator, similar to someone working at the United Nations, taking waterfall concepts and equating them to agile principles.

The notion of a sprint review should be re-framed as early feedback from stakeholders. 

Backlog refinement can be positioned as a review of risk and prioritization. 

And the ceremonial retrospective instead becomes a discussion about process improvement. 

It's not that we're trying to hide the agile mindset, it's that we're trying to make it understandable before we even call it agile. 

What follows is usually enough acceptance to allow the agile champion to request an experiment be done on a small project. If that happens then the next focus of the agile champion should be to prove the value of that project to management.

Next week I will talk all about that. I hope you'll join me.