Mr. Waterfallon and Mr. Agilero – Episode 2

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


Mr. Waterfallon and Mr. Aguilero recently met after years at a conference. They used to work together in the past. By chance, they are now again working together on a project.

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

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

Mr. Waterfallon

I must admit I converted to agile! Since we met the last time, I had the opportunity to be part of a large scale agile project. And you won’t believe it, and I am fully convinced now.

Mr. Aguilero

Somebody pinch me please, I must be dreaming. What happened? Did you read the agile manifesto for the first time?

Mr. Waterfallon

I knew the manifesto probably even before you did, but I believed it was about fairies and unicorns. Now I know it is the American Dream of the IT industry. Make the team believe in it, and they will accept any additional pressure. We did Scrum, and I learned to love it. It turned our team into slaves.
Full commitment, direct personal responsibility and accountability, daily stand-ups with full transparency of individual failures, and all the blame went to the product owner. It was wonderful. You know as in old times, and I know you are used to this, so let us do this in our project. Please be my product owner.

Mr. Agilero

A slave team? A scapegoat product owner? What the…?

Mr. Waterfallon

As said: it was great. I’ve never seen that kind of absurd control over a development team. Although a lot of time was wasted because the scrum master in charge, the product owner, and the developers were on different planets. Due to the pressure and transparency, all mistakes became public. The developers wanted to cover their errors and compensated by overtime, and the provider added extra staff no one was charged for. The customer did not have to search for an Achilles’ heel. It was served to him on a silver plate.

Mr. Agilero

I am speechless!

Mr. Waterfallon

And now comes the catch: There was even the choice whom to blame in each situation. Where there is Scrum, there are backlog items. Its the product owners responsibility to write them – and everyone knows the POs of the world are neither qualified nor do they have the time to do it. So one could choose whether to blame the developers or the product owners for screwing it up as I said: excellent!

Mr. Agilero

Well… The gods created the earth and hades. They also established an outpost of hades on earth to prepare some of us here on earth – I have no idea where I got that bad karma, but it is the way it is… They called this Fegefeuer Product Manager, Product Owner, and Business Analyst.

The pressure a team allows is within their control. It is the old prisoner’s dilemma they must overcome. This is where a scrum master, a real team player, can help. I somehow envy them because the various agile frameworks have some tools for them. It is also solely focused on the team itself, which lowers the overall complexity.

The product owner or business analyst approach is a different beast.

But please, be my scrum master, and I will tell you my plan to survive.

Mr. Waterfallon

You can call me your evil scrum master from hell. I can’t wait to heat the fire!

Mr. Agilero

So first of all, Agile is currently at the peak of the hype cycle. Your arguments are the best evidence for this.

Agile is not about controling. It is about collaboration. You can control a contract, but then you will need a plan that is carved in stone. You will get what you asked for, and each change will have a high price, as everything is predefined. Sticking an agile tag on this project perception and perceiving it as a tool to squeeze the last drop of blood out of the team is exactly what agile is trying to prevent. It responds to change, and the result is better as the initial plan since business, development, and users are working together to build the best solution.

The development team has to be perceived as part of the solution. Right now, in the best case, the development team is kept at arm’s length. This is contract thinking and not collaborative – therefore not agile from the very beginning! Most often, the development team is just a bunch of slaves, and the business expects execution only. I have seen this too many times: the senior management likes agile, as it is suitable for marketing but still asks at the end when all features (which they always can remember from the kick-off) are going to be delivered – of course at the same fixed price.

The architecture is an epic story for itself. It has to be in place as a solid foundation when we are talking about a service life cycle of more than two years, which should be hopefully the standard. I think we agreed on this last time we met. Today I see MVPs, and the architecture is just a documentation of a very early prototype – so the business and the development team is doomed by technical debt right from the start.

The development team should have a personal interest in building the right solution. Idealy they will use it for themselves. This knowledge is 20 years old and can be found in the famous cathedral vs. bazaar article from 1997. It is a good starting point for a product manager or product owner to sell the vision. This might not work for every solution, but at least for some aspects or components. It will require a leader and not a boss.

Last, not least, you need to cover more than just frontend, backend, and design. At the very beginning, there must be a strategy in place. You will need to understand your users truly, this is an ongoing process. Technology and implications must be outlined – this maps directly to the architecture. Production and operation must be thought out from the very beginning. The best frontend user journey is useless in terms of business value when the support tools suck. This links to an essay from Jesse James Garrett back in 2003. When those roles are in place, agile project management really kicks in and delivers.

Mr. Waterfallon

Nice sermon. You know too well that all these prerequisites have never been observed in corporate reality. So shall we heat hell now, or what?

Mr. Agilero

Damn it. Yeah, heat hell!

Author: Kydroon

Explorer, Mad Scientist and Foodie

Leave a Reply

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

You are commenting using your 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.

%d bloggers like this: