Focusing Agile Transformation

I remember the first of my employers going Agile. These were fun days. Virtually all project managers, along with some upwards-mobile candidates, were sent to an expensive (more than half of my monthly salary back then) two-day long course. Then, we were all sent link to some website test somewhere. The fact that we all passed should’ve lit some warning lights for me. Back then, it didn’t. As soon as the certificate arrived in my email inbox, I did the obvious thing. I updated my LinkedIn profile. We all did. Officially, we became Scrum masters – hence, by association, the company became Agile.

Damn, I was stupid back then.

I did quite a lot things wrong. I didn’t work in the same room with my team. I focused retrospectives around stupid games picked up at the training. I was, basically, forwarding orders from Product Owner, who was as Agile as Alfa Romeos are reliable. And to all you unfamiliar with petrol-head world, that means – not at all. On time, on budget, works, that kind of thinking.

I actually went further into the abyss. Company management requested all newly assigned Scrum masters to file weekly progress reports. Standardized three-page long PowerPoint presentations, with burn-downs for current sprint, burnup chart for release, major highlights and so on. The idea was presented as a shot for transparency – you know, as a Scrum master, you shouldn’t hide anything. Even more, in this role, you should report everything. If your burndown doesn’t follow the capacity then, clearly, you should explain it. Because, well, we trust you. We’re all empowered and Agile, right?

Which is where I must admit I knew these reports very well. Hell, on request from my boss back then, I created them myself. Because, well there’s Agile, but still, we (the management) need to control it all, right?

Apart from fake empowerment and silly post names, nothing really changed. It was business as usual. In essence, we did it all wrong.

Basically, this is where many transformations fail. They focus on the visible, mechanical part of the process. It seems like working using some fancy tool in two week long iterations, coupled with some expensive certificates and idiotic job titles, essentially, is Agile. Literally, just few weeks ago, at one conference, I saw some company advertising this way. “We are Agile, as we use Jira and work in iterations.”

Idiots, idiots everywhere.

Funnily enough, it is perfectly possible to be Agile working in some medieval, construction-style project management approach. You just need to define the deliverables around business value, not some (more or less) physical product, as you would normally do. You can set up your milestones accordingly. You can adopt along the way. It’s all there.

And if your Professional Integrated Management of Projects – Unified, version 2 (PIMP-U2), or whatever else it’s called, approach disapproves that, just think for a moment. Ask yourself, who is the dimmer? Someone who just didn’t take something into account, or someone that blindly follows methodology created decades ago by fellows who are already retired?

So what does it take to transform to Agile?

It has little to do with frameworks – even though some of them, in some circumstances, given some assumptions are met – do help.

It has even less to do with tools – yes, you can use Jira to run waterfall project. Likewise, you can use Excel to run anything Agile. Some tools seem to make more sense in some occasions – then again, you can use either a hammer or a screwdriver to crash someone’s head. It might be easier with the former one, though the latter could do the job anyway.

Finally, there’s nothing Agile has to do with certificates. I have two for Scrum master – and I would easily recommend at least a few dozens of people to that role over me. In a somewhat different context, someone said that leader without a title is better than title with no ability to lead. Think about it. It’s the same in every area.

(Practical advice – you might want to send people to some training. Just ask around for the trainer, their approach, practical business knowledge. Do some due diligence. There’s nothing wrong about that. The investment is likely to be massive, so make sure it counts. Just few professions in this world are more corrupt than trainers who do just that their all life – and nothing else.)

So, what does it take to actually transform your organisation?

It is, at the very core, a cultural change. One that should originate at the top, as it makes no sense whatsoever to try implementing it rank-and-file. Remember, that way of working across the culture is a projection of mindsets of people at the very top. These are the people you should work with, all the time. There will be time to tackle delivery teams – they’re just not the best place to start with.

It just takes a touch of humility to start. Instill it within the higher management, and majority of your work is done.

Then, work on transparency. It should be easier now that people understand they might not know everything.

Finally, move on to some practices, tools, and frameworks, all along. They’ll make way more sense, given people really understand what each of these pieces is meant for.

What you’ll end up with is a truly Agile organisation, able to clearly bind their decision making to value delivery.

And that’s skin teeth shy of invincible.

Wouldn’t you like to give it a shot?

Opinions are my own and not the views of my employers, customers, or clients.

Failed Agile Transformations ebook

Learn how to spot, avoid, and FIX them!