Mr. Waterfallon & Mr. Aguilero – Part 2

# Stage

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 death match 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, I am fully convinced now.

# Mr. Aguilero

Somebody pinch me please, I must be dreaming. What happened? Did you read the [agile manifesto](http://www.agilemanifesto.org/) 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](https://en.wikipedia.org/wiki/American_Dream) of the IT industry. Make a team believe in it and they will accept any additional pressure. We did [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development) and I learned to love it. It really 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 mistakes and compensated by overtime and the provider added extra staff no one was charged for. The customer did not have to search for an Archilles‘ 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 worls 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: great!

# Mr. Agilero

Well… The gods created earth, elysium and hades. They also created 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 prisoners 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 totally 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](https://en.wikipedia.org/wiki/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 percieving 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 percieved as part of the solution. Right now in the best case, the development team is kept at [arm’s length](https://en.wikipedia.org/wiki/Arm%27s_length_principle). 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 business expects _execution only_. I have seen this to many times: the senior management likes agile, as it is good for marketing but still asks at the end when all features (which they still can remember from the kick-off) are going to be delivered – of course at the same fixed price.

The architecture is an [epic story](https://en.wikipedia.org/wiki/User_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 2 years which sould be hopfully 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 a good solution. Idealy they will use it for themselves. This knowlege is 20 years old and can be found in the famous [cathedral vs. bazaar article from 1997](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). 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](http://www.lifehack.org/287785/10-differences-between-boss-and-real-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 truly understand your users, 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 [front-end user journey](https://en.wikipedia.org/wiki/User_experience) is useless in terms of business value when the support tools suck. This links to an [essay](http://adaptivepath.org/ideas/nine-pillars-of-successful-web-teams/) 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?