Mr. Waterfalon & Mr. Agilero – Episode 1

All characters appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.

Stage

Mr. Waterfallon and Mr. Aguilero meet again after years during a conference. They used to work together in the past. Mr. Waterfallon is one of those seen-it-all been-there-done-it guys with lots of project experiences – good ones and bad ones. Mr. Aguilero is a hot-shot. He is the one who did not know either cared it was impossible and did it anyway.

Raise the curtain for another round in the ring of deathmatch arguments on business, IT and all the rest…

Mr. Waterfallon

Mr. Aguilero! Nice to meet you again after all these years! Guess what: I still can not wait until agile is heading south on the hype cycle and stabilizing close to zero.
I am looking forward to us all getting back to work and get things done again!

Mr. Aguilero

Mr. Waterfallon! What a pleasure to see you again. I miss to work and debate with you, you know? Talking about the debate, what are you talking about?

We are all agile now! …and history loves to repeat as we know.

The method of war is over. Everybody I see today is agile. Even large organizations that are taking pride in ignoring any innovation and looking beyond the quarterly event horizon are now adopting agile.

We are so agile, even the definition of agile becomes agile leading to a funny infinite regression towards who cares at all!?

Mr. Waterfallon

That is Mr. Aguilero, I remember. Once you realize I have a point – you start throwing smoke grenades. I admit, agile eventually work in startups and small independent teams. But it fails to deliver in the large corporation. Adopting? Ha! The CTOs of the world just found out that it is easier to blame the business if you call them product owner. Shit hits the fan ever since.

With agile, the IT just turned the fan around!

Mr. Aguilero

Hmmm, why do I have a bad feeling about being again on the wrong side of that famous fan? However, Relax and let’s look at your statement: It works in small but not in large. Now please help me to understand what you mean.

What do you mean by works and what is the context of this?

For me, agile is just one step in the right direction to free visions from quarterly earnings.

Do you remember the five-year plans of the soviet union? The laughing stock for the free markets on the other side of the iron curtain?

Business planning of today is by far more ridiculous! Free markets? Bullshit! Take a look at the ratio of goods traded through free markets with real pricing system vs. corporate-wide internal accounting with fixed funny numbers.

I do not want to just optimize by some mere percents. I want to build new stuff! I want to generate new money! By definition, this can not be proved or planned, and because then it is already best practice or even worse, it became a commodity. Long term plans made to freeze innovation – spiced up with market research that may work for soap but not for software.

Mr. Waterfallon

Yes! This is the core question! What context are we talking about? New money is earned by new products. New products are bought by old companies as soon as there is no longer a risk. This is where agile – especially lean startup ideas kick in. Plan, build, verify, and adapt in short cycles. Build MVPs not the has-it-all-solution in the first place. This works fine for small projects. The team may be independent entrepreneurs or employees of a large corporation that protects them.

But whenever agile is sold as the solution to heal large scale project failures, I get headaches. Imagine they tried to build the Burj Khalifa using agile. This example is extreme, but the majority of IT projects and products require careful planning and architecture – you can not just leave it to an agile team making decisions on the go – while blaming the customer for delivering insufficient user stories.

Mr. Aguilero

This example painfully reminds me of Mr. Werewolf, our old boss. He overstressed civil engineering and machine scheduling as best practices for software development. Burj Khalifa is not as complicated as new software typically is. You have stories, and you have rooms. Both highly repetitive and please consider: humankind does this for some thousand years now. Burj Khalifa is an excellent cathedral, but the surrounding bazar that was required to build it was far more complex.

The user story is always the same: build many big rooms to impress all underlings. The epic story is staple stories to make the building visible from far away and impress all enemies.

However, when you take precisely the architecture example, you will see that it miserably fails when there are more complex epic stories behind. Hospitals get operation rooms that do not allow to push in beds, railway stations are big and impressive but have only one track for taxis to drop of their passengers and airports for capital cities never get finished even though those have been thoroughly planned.

Please do not get me wrong! I do not advocate no planning, I want to avoid the control illusion or cognitive bias the managerial caste sometimes suffers from when initiatives mutate into a project.

I agree that in IT and business buildings are built on top of wooden blockhouses and quite often a skyscraper is added on top of it.

Mr. Waterfallon

Sure the Burj Khalifa is just stapling rooms. That reminds me of some prepared statements I heard from a scrum coach lately who tried to manage complex IT projects with independent user stories. The complexity derives from dependencies. No method can remove the dependencies – only the architects can do that. So I agree if there is bad architecture, it doesn’t matter which project management method is used.

But hey what about that: let the architects do their homework and tell them to create great stuff with as few dependencies as possible. Then let’s develop plans that layout whom we need and when, and what needs to be done in which order to respect the remaining dependencies. And then – I almost refuse to believe me saying that – let’s use agile to manage the teams that are going to build it!

But guess who is the product owner then? Right! It’s the architect, not the customer! Or does this idea hurt your agile manifesto cortex?

Mr. Aguilero

I almost refuse to believe me saying that, too – Agreed! Just let me add – I need the last statement – this is even more important for business than IT:

The architect there is usually called Product Manager or Business Analyst. The poor guy that has to orbit at CEO level on visions and survive the pressure of the Mariana Trench of business and technical details.

However, the bravery of people willing to adequately care about the whole thing, visions, products, or solutions is something we should discuss next time. Feuding stakeholders and information overload let them shine bright as they quickly burn out.

Let us get some Gin-Gin Mules and share some gossip from our disrupted markets my old friend…

Mr. Waterfallon

I knew, at some point. You surrender to my arguments. And yes, let’s get the party started.

…to be continued…

Author: Kydroon

Explorer, Mad Scientist and Foodie

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.