Focusing Large Scale Agile Transformation

With all the hype surrounding the new ways of working (though calling them ‘new’ is dubious at best), you can still find some dinosaur playing the old game. Fixed scope software projects, infrastructure changes, provisioning of new services – all done the old way: loaded with project managers fighting over ‘resources,’ massive multitasking, and complete obscurity of accountability. Yeah, it still happens. I find it amazing that companies with core parts working like this are still afloat. 

The moment they notice their momentum is not limitless, the new begins. Sooner or later, large businesses realize that change is necessary. Then the transformation begins. I will not go into specific frameworks or approaches (though you can see my view on the best Agile framework in existence), but areas of focus.

As an agile coach, who should you work with the most?

The typical answer is obvious – put your effort on teams. After all, there can be hundreds of them. Even a large team of seasoned coaches will need quite a while to equip them with minimal viable agility, not to mention doing it right. Though it’s hard to expect an agile coach with any work ethic whatsoever to stop at the bare essentials, they will be pressured just to get it done. According to the plan. On time. Waterfalling Agile transformation will never get old.

Not to mention that focusing on teams will not yield the best results. Just think about it – as per the Agile onion idea, it’s not really about Scrum, Kanban, or (God forbid) Jira. These are just a means to an end, nothing but tools. Sure, you can train two hundred teams in Scrum, but unless you have very assertive and mature Scrum Masters with a mandate to do something useful, nothing will change. No increase in effectiveness. No shortening time to market. No twice the software in half the time.

For sure, though, your organization will become leaner. Your best people, those of the highest market value, will get frustrated with false promises and transformational tornadoes and quit. If that’s what you’re after – way to go!

Back to business – if transformation is not about the way teams work, what is it about? It’s the mythical mindset, which means what you should aim at is a cultural change, not process and tools one. And who shapes the culture? Everyone above the teams in the pyramid. Line managers, their managers, group managers, directors, executives. Culture radiates down from the top and is almost impossible to change bottom-up – and every attempt to do so will inevitably raise the bar of frustration on all sides.

Where should you focus your transformational effort first? All the management impacting teams (it will usually go higher than you expect). They should be the first to realize that multitasking is often a waste of time and money. They should measure their lead times and actively work on shortening them. They should do daily meetings and hold retrospectives. They should have transparent backlogs. Otherwise, they will be rightly perceived as fake, pushing yet another brilliant idea to their teams.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln, weirdly relevant

The best thing is that investing some time to work on management first will shorten the duration of the whole transformation. The culture and environment for teams to become Agile will already be there – no disappointments, no surprises, no frustration. I can’t think of a reason not to do it – and if you can, comment here (or PM me here).

Okay, there may be one reason – if you don’t want to transform. 

That’s always an option: comfortable, safe, short-lived.

Minimum Viable Agile

For years, I have lived in a belief that complex problems require complex solutions. If we’d like to hugely improve our business with agile, we should use some complicated framework, with multitude of tools, approaches, and processes designed to address every possible scenario. It backfired on me several times. The wake up call was almost three years ago, during Agile Portugal 2015 conference.

You might know it or not – 2015 was year of agile at scale. If you wanted to be treated seriously as a speaker, consultant, or coach, you just had to share your experience with it. Everyone was into scaling. Because, clearly, we all knew how to do it right on a team level… Obviously, having quite a background at large scale agile, I joined the bandwagon. My speech in Porto covered exactly this topic.

Then, during a break following my presentation, reality hit me with a sledgehammer.

You all talk about agile at scale, which is great, but we’re startup of ten people and want to do it. How?

If I remember correctly, my answer actually made sense. Something along the lines of starting small, using the least processes and formalities possible, just the kind of basics that make sense. Regardless, I was dumbfounded enough to quit corporate job two years later and joining a very small company to see how it really works.

But there’s more to it.

Just at the end of 2017, I was contracted to run series of trainings on basics of agile to over one hundred employees of a large state-owned conglomerate of very traditional sector. As if it wasn’t challenging enough, majority of the participants had little to none exposure to IT terminology, processes, and industry. Trying to grasp and convey the essence of what agile is was quite tricky.

To make things worse, I’m not really sure if they stand a chance to actually make it with the transformation. Reading between the lines, it was clear that management buy-in was dubious at best. Agile was yet another great idea they had, following (and perhaps preceding) series of other spectacular transformations.

Yet, I wanted them to benefit from my trainings regardless of what future could bring. Then, out of the sudden, I had my eureka moment. I found the Holy Grail of the least you could do to get all the benefits in the world. And it was hiding in plain sight, disguised as one of Scrum ceremonies.

(I seriously dislike the official, semi-religious terminology of Scrum. Artifacts, ceremonies, masters…)

Retrospectives, in their simplest possible form, are Minimum Viable Agile.

It’s that simple. Get your team for half an hour and ask them the most basic and most profound of questions: If we had a second chance to live through these last two weeks again, what would we do differently?

Hell, you don’t need to wait few weeks. You can ask this question every morning. The benefits will astonish you.

Why?

First, as human beings, we hardly ever reflect on our lives. Not to mention, on a regular basis. We only do this when things either radically change (think: you’re about to have a baby), or when they go really, really wrong. If neither of these conditions is fulfilled, we just fly ahead with staggering mindlessness. Nothing weird about that, we’re just humans, perfect in our imperfection. It is worthy to shed some light on whether we’re going the right direction or not.

Second, no currency is worth more than our time. Not only you cannot buy more of it – it comes in extremely limited supply. Given you’ve reached this sentence of this post, you’re about four minutes closer to your death than you were at the beginning of it. It’s one of the most uncomfortable facts people are ever faced with. You will have no chance of reliving yesterday. If you did something stupid, or pointless, or in an inefficient way – you will not have a chance to change it.

You do have a shot of making it differently today. Otherwise, tomorrow you will be even closer to your demise, with yet another wasted day. That’s your choice.

Third and the most important reason for starting with Minimum Viable Agile – it will get you somewhere else. Yes, there are thousands of prophets saying you must use Scrum, Kanban, or whatever else. Each of them has numerous examples of how, to a different extent, these things worked in the past. They are perfectly right about that! These approaches, in that particular conditions, in these particular businesses, gave very specific results. That’s a fact.

However, extrapolating these past experiences into your business can be nothing but a false prophecy. No company is out of the box, so applying off-the-shelf framework can only work to an extent.

By regularly inspecting and adopting the way you work, day by day, you can create your own agile. Tailored and customized to your specific needs, to the way your people work, to the very DNA of your business.

All it takes is to start small.

So, if you had second chance to relive yesterday, what would you do differently?

Personality Trait to Enable Agility and Leadership

Just previous weekend, I had the opportunity to share my thoughts on “that whole Agile thing” on a conference in Cracow, the capital of Poland for majority of its known history. While explaining the Agile onion concept, origins of which I couldn’t find (though I would love to buy whoever thought it out a beer or two), I made a comment that the single personality trait that makes the actual agility possible was humility. Which, contrary to what you might think, is nothing about religion and is not, in any way, related to modesty. Especially the popular, false one. Coincidentally, I have a strong belief and evidence that humility also enables one to be the proper leader.

Isn’t that what we all want? Agility, leadership – widespread, across our workplaces? Now, that would make sense, wouldn’t it?
Continue reading “Personality Trait to Enable Agility and Leadership”