Adopting agile practices is a step-change for many senior managers and business sponsors. Don’t underestimate the importance of getting them onside early in an engagement, and making it “safe” for them to explore and adopt agile practices.

We want to provide our sponsors with timely, accurate information they can use to make effective decisions about the steering of a project. An agile project provides exactly the data to do just this, but we have to ensure that the people receiving it can interpret and make use of it easily and effectively.

For the team on the ground, agile adoption is a shift in thinking from large chunks of activity to smaller, iterative, highly-collaborative working. This shift can take place quite quickly. With a small, motivated team and a high enough proportion of agile “enablers” in the team (about 50/50 seems to work best), a new team can pick up “proper” TDD, pairing, continuous integration, story writing, etc. in a matter of a few weeks.

The business sponsors, on the other hand, have a rather different journey. They are used to seeing Gantt charts showing percentage completion of development activities, and—shame on us—they are used to project managers being, well, at best conservative with the truth. In our defence, we say things like: they don’t need to know the day-to-day dynamics of the delivery cycle. If we are slipping slightly, let’s just gloss over it—we don’t want to go worrying anyone. And anyway, no-one likes their project to be “amber”, do they?

And then agile planning happens, and all Hell breaks loose. Suddenly we are only reporting actual, delivered features. Things you can prod and make do stuff. Things you can verify. The concept of “80% done” goes away. It’s either finished or it isn’t. And then there is “velocity”. There’s no hiding behind velocity. It’s simply “the rate at which we do stuff”. Some weeks, we’ll have a high velocity, other weeks we’ll have a low velocity. That’s just the way development works: you have good weeks and bad weeks, easier things to implement and harder. Over time, as the team gets better at both estimating and delivering, the velocity will settle down to a regular rate, which is of course where the predictability of agile comes in to its own, but there will still be peaks and troughs.

We have traditionally only ever reported good news. We have a culture of not wanting to upset people (especially people who a) might shout at us and b) are paying our wages), which means those very people are unused to hearing anything but good news—at least until the end of the project when all the ugly truths about overruns and scope creep and the spectacular bug list come to light.

Make sure they are ready for the truth#

Which brings me to my point. As a coach, you have a responsibility to prepare business sponsors and anyone at the governance level (including senior IT management) about how to interpret progress on an agile project. “Bad” news isn’t always bad; mostly it’s just news. The very levers that allow us to micro-steer an agile project can make a business sponsor very uncomfortable, and it is our responsibility as enablers to help them through this transition. They are getting a level of visibility and transparency that they have never had before—far more data points and far better data—at a level of granularity that requires some adjusting to.

We are giving them a microscope that allows them to ask questions about details they’ve never even been aware of before. Of course we can coach the project manager in presenting the tracking information in a form that is more digestable to senior management, but it is always preferable not to have to “dress up” the figures in this way. If we get this right, the business sponsors will have greater control over the steering of a project—in terms of governance, direction, funding, resourcing, etc.—than they have ever had, so it is worth the effort.

There is a tendency to start the enablement process within the development team. Let’s get the developers doing test-driven development, the BAs writing stories and the PM doing agile tracking. The problem with this approach is that the new fine-grained tracking information bubbles up to the governance level in a fairly literal format, and they are completely unprepared for it, which can lead to a knee-jerk reaction that agile “doesn’t work”. For a programme manager managing a portfolio of projects, if the one agile project is the only one consistently delivering “bad news” (i.e. honest, transparent progress) it is likely to cause unnecessary anxiety amongst exactly the people who you want to be sponsoring and championing the transition to agile.

In summary, you should engage the business and technical sponsors of an agile enablement early, and help them make sense of the new, richer, more transparent information they will be receiving. It is also worthwhile spending time with the project manager, helping them have the different kinds of conversations that will inevitably occur as they transition into a new, more effective way of delivering and tracking software projects.

Colophon#

This article has been translated into Russian by Denis Oleynik.