What Happens When We're All Agile?

** the following is a fictitious diary entry designed with comedic purposes in mind.

Dear diary: Today was a busy day. I had to attend the Board's Agile Board Level for the Enterprise (ABLE?) kickoff before my day-long Sales Agility workshop. I don't know how these folks manage to get up at 5am for it, but holy smokes, I couldn't do that every day.

The good news is that the Board managed to get their 3-year strategic plan carved in stone in half the time thanks to the ABLE? framework, so now it's just a matter of selling it to the rest of the organization.

Last week all the C-Level folks went through their Leaders 4 Agile? training, so they should have no problem executing that plan as soon as this next fiscal year is done and they've met their previous objectives. It does suck that most of the new objectives will undo what they're working on now, but given my NDA, I can't say anything.

I am looking forward to this Agile Sales workshop, though. Sales people are an absolute riot to work with! The VP of Sales bought the new Sales Agility (SA?) method, but it's kinda funny because the operations team is based in South Africa so there's a lot of confusion around when she's referring to the "SA" Ops team and the "SA" framework. It's kinda like that scene from Good Morning Vietnam when Robin Williams throws all those acronyms around...but anyway.

Hopefully, once the sales folks are done with this workshop, the marketing people won't think they're lagging behind the rest of the organization anymore. Marketing started their agile transformation three years ago, and they were all fantastic to begin with, so I'm not entirely sure why they decided to transform in the first place. They just get it. Either way, that was easily the most fun part about this gig so far, especially when compared to the IT security's agile transformation that was done a few years earlier. Man, that one was rough, but now those security folks are 100% agile.

I guess the hard part will be getting the product division to change its 3-year product roadmap based on the Board's new direction. The VP of Product has never liked this agile stuff to begin with, and it's obvious given how he acted in the last Leaders 4 Agile? retrospective so he's going to live and die by that roadmap no matter what the new objectives say.

At least things are rockin' in the delivery organization. The Wild Testing Agile Framework (WTaF?) that the QA organization started using last year makes regression only take a month instead of 2 months so the developers don't have that long to forget what the heck they worked on when QA logs bugs in the BEAST? (Best Enterprise Agile Software Tool)

Oh, I almost forgot, BEAST? is entirely customizable, so since the product people hate it, one of the developers made a skin to make it look like their project planning tool. Too funny!

Well, that's about it...oh, almost forgot another one! When this month is done, everyone will have completed the Agile for Individuals? (AI) mandatory mindset training that the change team is rolling out as part of the Agile HR's new annual performance management targets. It'll be so nice once everything thinks in the exact same way. Crap, maybe they won't need me anymore?!?!? Reminder: polish resume.

Anyway, kudos to those change folks; how they keep track of all these scorecards and frameworks is beyond me, but there's no doubt once they publish the new strategic direction from the Board, we'll be primed for the new Business Advanced Agile Method (BAAM?) they plan on pushing through next year!

Exciting times are ahead!

Disclaimer: This is what folks in the comedy biz call exaggerating the premise.  Any representation to a living framework is purely coincidental. No agile coaches were harmed in the typing of this story and yes, quarantine is slowly driving me insane.

Serious question though; What happens when we're all agile?

Anyone who's been around Agile long enough has seen the trends. You might even be old enough to know the big Agile conference hosted by the Agile Alliance used to be called the Agile Development Conference before 2004, and most, if not all, of the talks and workshops were about XP! 

As the agile community learned that technical practices weren't enough, the Agile Executive forum was created in 2011...as a separate event hosted simultaneously in the same venue, which left some agilists scratching their heads.

By 2017 the XP Conference returned, and the Deliver conference was created which was about whole team delivery, not just technical or business stuff.

Today, I can't even keep track of all of the agile events where I live!

You can uncover a glimpse of the trends by looking at the history of topics from the Agile Alliance conferences. If you have some spare time, read the session list from the 2004 conference here, and then the session list from the 2019 conference here, and you'll see how much has changed. It is quite interesting to see how quickly 'agile' has gobbled up everything in its path since the early 2000s.

The basic pattern I've noticed is that pre-2011, more or less but not a truism, the topics were about making change within existing structures. For example, topics included better code management, testing, better project management (IE: moving from fixed scope to variable scope as a result of fixing time/cost due to Scrum) and more. Again, the premise of most talks were all about changing how these existing structures (hierarchy and processes) work.

Post-2011, more and more topics expanded into changing those organizational structures or speaking to boundary spanning and making hints that an agile transformation = a reorg.  Over the years, especially post-2014, more and more topics about bringing humanity back into work and the interconnectedness of organizations took centre stage over technical talks.

Perhaps the best talk I've ever attended was Craig Larman's talk on LeSS. In only the way he can, Craig, setup a perfect scenario about the mess we're in due to decades of functional thinking. By the end of this talk, instead of giving the answer or promoting LeSS as the saviour, he said: "Everyone here knows why their organization is in the mess they're in. Everyone here knows how they can get out of it, but nobody wants to talk about it."

If I were a betting person, I'd wager a small fortune that once this latest round of <agile> + <whatever> runs its course, organizations that have been running agile transformation programs for over a decade and don't really need to transformation will be right back in the spot they're in now because two things will never change: Competition and innovation. The more we innovate, the more we increase competition and the more we increase competition, the more we need to innovate.

Ransom Olds knew this in 1901 when he invented the assembly line. How he did that without googling "how to make my business more agile?" is beyond me.

The lesson: As change agents we're in a rush to change those people or to enable new behaviours when really, we should be changing our view of change. We should be focusing on the interactions in the system whether that means how functions intersect with each other (the symptoms of which provide a great clue about what functions should merge with other functions, or stop existing completely), or how the organization interacts with the ecosystem it serves.

Case in point, while working in an enterprise many years ago, agile teams were created with the freedom to release when necessary. Instead of supporting it, Operations decided to put more control in place making it more restrictive and harder to release because the other constructs in the organization didn't change (IT change management, audit, procurement, management structures etc)

That was the pivot point, and that was the organization's way of saying a centralized Ops team made no sense anymore and that function needed to be merged with the teams. Had we gone that route, plenty of people would have needed to be let go and a substantial reorg and process re-engineering would have needed to happen.

So what happens when we're all agile? Probably nothing because the relentless pursuit of <making this function more agile> likely has us looking at the wrong problem.