Agile versus project management

Recently, Jørn Leonhardsen from the Norwegian Tax Administration made headlines on Linkedin claiming that “sometimes project management is better than product teams”.

His examples weren’t relevant to what product teams ever was invented to solve though, so the headline didn’t really match the content. But it still stirred the old pot again – fuelling those that dream of the old release weekends, toll gates and boards …

Because it’s a never-ending battlefield of opinions, biases, culture and … fear. And the sides are as far away from each other as the petrol heads and EV owners.

But why …? 

Found ourselves at war

When banks started on the journey, we knew we needed to do things differently. And we knew this felt right.

We sent our teams to training camp to become product owners and scrum masters and evangelists. We became certified. We learned how to run ceremonies and walk the board.

But we came back and found ourselves at war. Like agile was our rogue discovery, without any proven track record.

Check our tech vacancies here!

Fought tooth and nail

The organisation fought tooth and nail. Both passively, by not shifting procurement and PMO and reporting processes to align to this new way of working.

And actively, people going out of their way to say that agile was lawless and chaotic. That it reduced accountability and created too much freedom in all the wrong places and not enough governance to catch it before it breaks things.

Agile done badly

But it is all excuses.

First of all, it’s not like the old way of working worked very well. And secondly, what they are describing is agile done badly. Agile not being true to any of its principles. Why are they so convinced that it will be done badly if we do this?

I hated to hear those excuses then. And I hate them even more now.

Too much freedom in the wrong places

Because they were sort of prophetic. Big organisations either bastardised agile, marrying it to waterfall processes and creating confusion and overheads and paperwork galore, creating ‘nimble’ or ‘rapid’ hybrids that felt more comfortable.

And the result?

Well. Sadly, some got it wrong in exactly the ways the nay-sayers said they would. In all those ways. Exactly. It pains me to admit it but it’s true: if deployed carelessly agile can lead to too much freedom in the wrong places.

But … that is agile done badly. And we know it can be done well. And we know the results, when it is done well, are amazing. So, what does doing it well look like ”true agile”?

Welcome to Norwegian agile!

Many foreigners coming to Norway starts talking about “Norwegian agile”. It’s a joke when agile never has deadlines (said as a principle), and autonomy of product teams has gone so far that they are literally like visiting different companies.

It explains some of the misconceptions we have about agile and why we tend to believe it can’t be controlled in larger engagements.

But it’s not agile, it’s us.

And it’s our old culture shining through.

In the old project management and siloed application landscape, you were your own island all the way until it was your turn to test and deploy.

Agile doesn’t work like that.

Lack of clarity and fear will eat trust for breakfast

Agile needs constant cooperation and alignment to gain speed, integrity, and consistency. Because even if you are three teams or twenty, you are all still delivering on that one customer experience, and if you aren’t aligned on all the right places – that experience will feel disjointed.

So how does it scale to larger engagements?

Well, first it takes clearly defined processes, roles, principles and discipline. And both knowledge about the why, and experience on the how. Because discipline requires trust in the models, the roles and the processes. And lack of clarity and fear will eat trust for breakfast.¨

Bugs and cake

When you have trust, you can let go of the believed control of project management and experience a new way of getting control through a very fast-phased, but a lot more precise delivery culture.

It’s very enlightening, and very logical at the same time. But fast-phased means work, small portions, continuously. It’s a big change if you’ve been part of the slow and steady burn of the project management rig before it ramps up to the release date and the weeks of “post release” chaos of fixing bugs.

Then cake. (But the cake was a lie, wasn’t it…)

Agile is not slow burn. Agile is fast, but smooth. Smooth when the roles are clear.

The glue that holds it all together

One key role is the Delivery Lead. It is the role that glues it all together. But it’s not a role you just give to someone; it’s a craft. And like all other crafts, not everyone is fit. Sorry.

As hard skills a Delivery Lead should as a minimum have a technical or analytical background, worked as a scrum master (certified) or similar position in agile teams for a number of years.

But it’s the soft skills that are most important. You must be both interested in humans, in technology, in business, in customers and users, in performance and analytics. And have that positive, motivating “get shit done” mentality. Knowing what good looks like in all roles that is part of the process of bringing delivery to the customers is also core.

"Take the elevator"

To do that, you must be able to “take the elevator”; be able to talk to the devops engineers, the architects and tech leads just as naturally as the product manager, the management and the steerco’s.

You must understand both what they all say, and what they need to hear when you have time to talk with them and they with you. What you need to say and what they need to hear to keep momentum. Enabling them to make qualified decisions on all levels. From management to code.

Back to the core

It all goes back to the core of technology and software development; enabling the engineers to ship quality code to the users as efficiently as possible. To do that, they must always have access to facts, clarifications of dependencies, frictionless environments, and as little meta-work as possible.

Those facts must come from the product owners’ product backlogs. And the Delivery Lead will make sure they are coordinated across and aligned, and taking part in all ceremonies to provide the engineers with exactly what they need to hear to do the next cycle, and holding back the information that is not relevant here and now or not mature enough to take action on yet.

In the other end they are present in all standups and retros to get feedback on the last cycle to plan the next both for that team and others with dependencies.

Extremely powerful delivery setup

By implementing, enabling and trusting this machine, you get an extremely powerful delivery setup – and the elephant can be chopped into consumable parts that is prioritised, verified and fed into the backlog of relevant teams for deployment. With total control of the larger picture.

An as a bonus, you will get developers that thrive – because they are always shipping code towards clear requirements.

Does it scale?

Definitely. A mature and fast phased engagement we ran in London for DNB had approximately 45 experienced devs and 3 Delivery Leads. After just south of 30.000 dev/hours they had produced solutions with functionality and integrations that had previously taken other teams north of 140.000 dev/hours + admin of the project management. Now we have 130+ devs just in Corporate Banking, and towards 1200 in total in DNB.

Can we do this all over Norway? Of course, but not without added competence to our workforce. The number of people who have worked like this at large scale nationally is staggeringly small, and it would be quite an operational risk if any of them fell off while in motion.

To learn from others

Does that mean it’s something wrong with product teams and agile at scale? No, it’s us. But we will get there. The benefits are too many to stay behind.

And from my point of view it’s the social responsibility of the likes of DNB, The Norwegian Tax Administration, Schibsted, Telenor, Equinor and our likes to make sure that journey is travelled instead of keeping us back by running deliveries as projects.

In DNB we choose to do just that. And with our international presence we can get access to knowledge, experience and expertise within both technology and ways of working – to make sure we learn from others and grow in our abilities and culture, also nationally.