Becoming agile is a business imperative

There has often been a lot of soft talk about agile. In its early years “agile” has been sold rather touchy-feely. That has changed. As Jeff Sutherland says, agile is about delivering twice the output in half the time. It’s all about output. Not only is it about becoming faster, as much it is about delivering what’s of real value to the customer. As we’re in business, output is all that counts in the end. But honestly, quite a portion of what we do and how we work is less about output than it is about process as such and utilization. Yet process is of no value as such and utilization doesn’t guarantee effectiveness and efficiency. My favourite example comes from Gregor Hohpe: if your calendar is completely full, back-to-back meetings all day long, you’re 100% utilized but you get nothing done at all.

Well, acceleration is certainly good in the first place but you might argue that one can succeed your traditional way still. Problem though is that others (aka competition) do accelerate. And others might no longer be the traditional ones. Competition today extends towards startups, other industries and especially technology companies. And they definitely are working agile already, meaning they get twice the work done in half the time.

I like the story Christian Finckh, Chief HR Officer of Allianz, presented once; – based on the legendary Rumble in the Jungle.

“In the dressing room before the fight, the reigning heavyweight champion, George Foreman, bowed his head in prayer. In a few minutes he would defend his title against Muhammad Ali in a bout dubbed the Rumble in the Jungle, held in Kinshasa, Zaire, and broadcast around the world. The stakes were high for both fighters. They would split a $10 million purse—the largest to date—and the winner would hoist the championship belt. Foreman and his corner men did not pray for victory; they took that for granted. Rather, they prayed that the champion would not seriously injure his opponent. Muhammad Ali, despite his vaunted ability to float like a butterfly and sting like a bee, entered the match as the three-to-one underdog.”
Source: https://hbr.org/2009/02/how-to-thrive-in-turbulent-markets

The outcome made history. Ali won spectacularly by knock out in the eighth round. The simple line of argument would be that agility beat brute force. The HBR article though makes the fine point that in the run up and during the fight Ali complemented his capacity of dancing and stinging by utter resilience and that it was (and is) the combination of both that makes the winner. Well, that’s at least hope for pretty resilient incumbents!

Finally, after all, the people side. Daniel Pink’s perspective on what motivates us: Purpose, Mastery and Autonomy.

Fake Agile

There are a lot of delusions around agile. More than I can write about. Here are my favourite ones. “Favourite” especially in the way that they prevent us from becoming truly agile.

It’s a culture thing (only)

Have you been in these meetings that are about (agile) transformation? At a certain point, someone will say: “It’s a culture thing in the first place”. All of a sudden, all the participants will lean back, stretch and cross their legs, relax and chime in: “Yes, it’s a culture thing …”. This has two implications. First, everybody’s notion is: “It’s them, not me. I certainly embody the right culture. If only my peers, superiors or reports would get it”. Second, some kind of order materializes: change culture first, then we can start working agile. As a corollary, responsibilities follow. Changing culture is primarily the task of a) the Board, b) of communications and c) of HR … . Thus, let’s wait and see until they have managed to change the culture. Of course, agile is a culture thing (too). But action shapes culture as much as the other way around. There is a solid line of reasoning that it’s only a change in behavior that might have the potential to change attitudes or culture (if at all). Thus, the only valid course of action is action. Stop talking “agile”, begin working agile. Unfortunately, that’s the more difficult course. It needs consequence and discipline. It won’t work within your current conditions. And it’s not “them”, it’s “us”. Especially the role of leadership is affected.

It won’t work here

In giving talks or trainings about agile the question arises rather sooner than later: “Give me a framework where to apply agile and where to go waterfall”. Unfortunately – from my point of view – we too easily comply to the temptation to actually answer that question: Low complexity, highly structured, less ambiguity, low-tech … equals waterfall. Uncertainty, ambiguity, advanced technology … call for agile. Favourite example for the waterfall way is building a house. The usual agile suspect is building an app. The problem is that the very attempt to categorize already limits our thinking. Much more can be done in an agile way than we might think in the first place. You can automate testing in in rather un-advanced technology environments. You can deliver continuously there. So you can in – say – communications. The question should not be about categorization but about how to make agile work in our specific environment. The true limit might actually be organizational readiness.

By the way, we built a house some years ago and I can hardly imagine a more agile mode of operation. Yes, there was a plan of course but having a plan doesn’t go against agile – on the contrary. The delivery was completely agile: the work was done by teams of about three people. Every morning we had a stand-up meeting between these teams and the product owner (myself). We discussed what was to be done, changes to the plan (there are lots of changes in the process of building a house), support needed and impediments to being removed. Each expert team delivered their products in short iterations autonomously and the product owner signed them off … .

We are already agile

Walking around any organization today, most everybody will claim to being agile already. But quite a few of these statements are nothing but self-delusions. Here are some challenges.

… is it real or just “scrumerfall”?

… where is the customer in your setup?

… do you deliver shippable products?

… are you measuring velocity?

… do you co-locate, dedicate resources?

… you still have these committees?

Get started

At this point, the way to getting started is pretty obvious: just get started!

First thing in that way is to very diligently think about “What’s your product?” – Not a process to get to something like that product, not a concept or (in most cases) a deck of slides, not a sequence of committee meetings … real OUTPUT! Ideally not something that’s done for good after three or four weeks but can be continuously (and incrementally) developed and shipped. A product, not a project.

Second, organize around that desired output. Assemble your team by the question “Who contributes to that output?”, aka “Who does the work?” Collaboration and communication are not values as such. They only are relevant in as far as they contribute to creating high quality output. Team autonomy is of the essence and pure stakeholders are not team members.

Third, start small and simple but properly. Adhere to the methodology, don’t do without a proper product owner, stick to the rules, co-locate … discipline, discipline, discipline! Don’t try that “distributed scaled holacratic disciplined …” framework before you have internalized the basics. Lang Lang still practices scales.

(author’s note: this post ist largely based on one I posted on LinkedIn 20 April, 2017)