WIREDGOV

Adrian Pyne has led or rescued transformation programmes widely from Telcos to eCommerce, mining, aviation and public sector. Following his well-attended session at the Power of Projects Takeover virtual event, he talks to APM about the finer points of implementing an agile approach.

Which is most important for implementing agile: people or the organisation?

I don’t necessarily differentiate. If you don’t have a supportive organisation, you cannot possibly work in an agile way. The best example I can give is from a major bank I went into about five years ago and they wanted to take agile outside of IT to use as the basis of its transformational work. I carried out an organisational cultural analysis and I came back to them to say that agile just wouldn’t work. Their toxic was culture to agile. They wouldn’t delegate enough and they wouldn’t make subject matter experts available when they needed to.

An organisation has to be willing to adapt the way in which it governs projects and programmes in order to be successful at agile. That’s the procedural bit. Then there are all the cultural bits: behaviours, engagement and collaboration. An organisation has to be willing to do all those things. If it’s not, it can’t be agile.

What are the biggest mistakes people or organisations make when trying to implement an agile approach?

The biggest one is thinking that agile software development techniques are the same as project management. Things like Scrum and SAFe were deigned to develop software. They are not designed to run projects…It’s a bit like saying ‘I want to put a shelf up on the wall’. You could use a hammer and nails but it’s probably not a good idea because, although they’re tools, they aren’t ideal for that task. You’d probably use wall plugs and screws. The first thing is ‘use the right tools’.

Another mistake organisations make is that they frequently like the idea of agile because they think it means leaving stuff out: not planning, not managing risk, etc. If you do that, you will fail. To a lesser degree, people think that if you’re going to have an agile project, it has to have an iterative lifecycle. It doesn’t.

Apart from software development, what is agile particularly well-suited to and why?

Anything that’s product development – whether software or anything else – can be very well suited to, because product development tends to go in fixed periods.

Also, agile is very useful in areas where you have quite a high degree of uncertainty in your outputs and you therefore need to do an R&D approach, a prototyping approach or a timeboxed design-build approach. Where the stuff you’re building is very well known, a waterfall approach carries very little risk because you know what you’re going to do and you know how you’re going to do it, so there’s very little risk in the management approach you’re using.

Is it possible for people to ‘be’ agile without realising it?

It’s actually incredibly common. I have a firm belief based on vast amounts of observation that real project professionals are agile by their nature. Good project, programme and portfolio managers never do more management that they need to. A key principle in agile working is doing just enough. If you’re a project manager who is saying ‘I’m doing just enough to maintain control of my project’ you’re being agile. So even if you don’t set out to be agile per se, if you set out to become a really effective project professional, I firmly believe you’ll become agile by accident.

Can it be challenging to shift people’s mindsets to accept that doing ‘just enough’ is ok?

Yes, because you’re challenging people’s attitudes. Psychologists will tell you that you can change an attitude and you tend to do it by changing behaviours first. If a new behaviour is seen as being of value then people will adopt it. In time, that new behaviour will become embedded, and an embedded behaviour is an attitude.

A lot of it is not necessarily soft people skills – it’s about saying ‘let’s looking at requirements in order to build a just-good-enough solution’ and identifying what that needs to be. If those requirements are well developed – if you can properly test and assure that what you’ve built matches the requirement – then it’s fit for purpose. It might not be as good as you can build it, but if it meets the very specific requirement, then it is good enough.

READ MORE: WHAT IS AGILE PROJECT MANAGEMENT