Mr. Waterfallon & Mr. Aguilero

Home » Blog » Mr. Waterfallon & Mr. Aguilero

Mr. Waterfallon & Mr. Aguilero

…[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 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 knew neither cared it was impossible and did it anyway.

Raise the curtain for another round in the ring of death match 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 really miss to work and debate with you, you know? Talking about debate, what are you talking about?

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

The method war is over. _Everybody_ I see today is agile. Even large organizations that are taking pride in ignoring any innovation and looking beyond the quartely [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 the Mr. Aguilero I remember. Once you realize I have a point – you start throwing smoke grenades. I admit, agile eventually works in start-ups 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 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, because then it is already [best practice]( or even worse it became 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 really overstressed civil engineering and machine scheduling as best practices for software development. Burj Khalifa is simply not as complex as new software typically is. You have stories and you have rooms. Both highly repetitive and please consider: mankind does this for some thousand years now. Burj Khalifa is a nice [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 exactly 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 capitol cities never get finished even though those have been thoroughly planned.

Please do not get me wrong! I do not advocate _no planning_, I just want to avoid the _control illusion_ or [cognitive bias]( the [managerial caste]( sometimes suffers from when initiatives mutate into a projects.

I agree that in IT _and_ business buildings are built on top of wooden block houses and quite often a sky scraper is added on top of it.

# Mr. Waterfallon

Sure the Burj Khalifa is just stapling rooms. That reminds me of some educated statements I heard from a scrum coach lately who tried to manage a complex IT projects with _independent_ user stories. 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 create plans that lay out 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 really 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 fully 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…

About the Author:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

Durch die weitere Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn Sie diese Website ohne Änderung der Cookie-Einstellungen verwenden oder auf "Akzeptieren" klicken, erklären Sie sich damit einverstanden.