Agility

Transitioning to caled Agile is an experience. It does seem a little overly complex, and it has yet to live up to the promises.

Agility
Photo by Roger Chapman / Unsplash

If you’ve been around for a while, you probably know that The Dude has been through a few “agile”transitions. Alas they have been mostly related to software, and software that supports hardware. But the latest one is, for want of a better word, unconventional.

A little back story is in order.

In The Dude’s six years here, there have been 5 top executives in our Business Unit (the title is VP/GM). Each of them has had a strong opinion on how to fix our ills, improve our business, and streamline the creation of value.

Needless to say, there has always been some asymmetries within the organization that prevent these lofty ideals from being a success.

The latest leader is no different. She joined us about 18 months ago (and that makes her nearly the longest tenure) and after some adjustment and learning, she came out and said that we would fix all our ills by adopting Agile methodologies.

At first, the attempts were spun up by internal teams who were trying to do scrum based agile, and frankly, this failed badly. They were uncoordinated, and there wasn’t any real cross functional participation.

It was bad.

Of course, some consultants were hired, a couple of new directors who had experience, and one internal person who had done a similar transition and it was off to the races.

In one of the early skip level meetings with our new VP/GM, The Dude was told by her that our development of content was going to be greatly accelerated, and because we were going agile, we would do more stuff.

The Dude kept his mouth shut. That was almost a year ago.

Scaled Agile

What are we deploying?

Glad you asked. We are now a SAFe house, 4 rounds of training, the identification of Value Streams, set up an Agile Release Train, move people into roles like Release Engineer, Scrum Masters, and Product Owners. We have now three, and soon to be 5 Agile Teams, and a single backlog that we (as Product Managers) fill out with Epics, and compliance with our “Definition of Ready” to bring to the Program Increment once a quarter for the Agile Teams to plan their commitment for the next 3 months.

We have had two PI’s to date, and the results are interesting.

The teams delivered an underwhelming amount of output. They were far more optimistic as to what they could accomplish, and truth be told, they delivered less than half what they would have done had we not been following SAFe.

But, at least the Dude is now SAFe PO/PM v 5.1 certified, all official and shit.

What have you heard?

… about SAFe? There are tons of people who have spilled ink on the issues. That there are a lot of meetings, meetings about meetings, and tons of overhead.

It is attractive to larger organizations as they claim that SAFe is a way to map “Lean-Agile” to your existing org structure, and operate in an agile way.

But our org structure is odd, we have a lot of moving parts to build something (unlike in a software or cloud environment, we have a plethora of hard deliverables, with cross organization dependencies, and non-sequential process flows that look like a third world telecom wiring mess.

That makes it very difficult to accurately estimate effort, and that leads to stories being stalled in the pipeline, and that cascades into delays, and failed deliverables.

Soon, you are coming to the end of a PI, and far less than 50% of what was committed is done. And in the next increment, you begin again, planning that will lead to further failed commitments.

I was told we would do things faster…

Alas, the original quip by our VP/GM that we would get more stuff done faster because we are going agile comes to mind.

Every time The Dude has been involved with an Agile transition, senior leaders have this perception that Agile == Faster.

And every time, The Dude has to clarify that Agile =/= faster. It means that we can be more responsive to changing business and market needs, and fewer surprises at the end of development.

Nothing more, nothing less.

Yet, there remains this myth that Lean Startup, Agile, DevOps (CI/CD) will magically make everything better without addressing the underlying structural issues that cause dysfunction.

Last comments

While The Dude has to be somewhat cagey about where he works, and what the circumstances are, there is one thing that is striking.

Our top leader is adamant that the entire business will go Agile (and in a way, the Dude respects this commitment, our Cortez moment of burning the ship at the beach to prevent any backsliding) The Dude is seeing subgroups of our business carving out exceptions, using the flimsiest fucking excuses. “We have commitments to other BU’s”, or “we don’t have the time to move to SAFe”, or “this is too heavyweight, so we will do our own thing” and it really pisses the Dude off that they are getting away with these cockamamie excuses.

If The Dude gets to have this fun, so should the whole organization. Alas, if we can’t all play by the same rules, then how the hell are we going to get well?