The number 1 thing that is wrong with agile development [FMVP]

I am writing this post to express my frustration with what people refer to as agile development. To me agile is where the business goes through the process of masquerading waterfall development and fudging it in a way they refer to it as agile development.

They really do a good job of masking it too. They plan and conduct 2 week sprints. They have scrum meetings. They have stories that are created and put it into the backlog. They even have backlog refinement. They point stories in a poker game. And the best one yet, they have retrospectives so everyone can tell you how crappy the process was for that 2 week sprint.

Who am I? I am a Senior Director of Engineering for a very large company. This is my story nightmare.

So looking at why one of our deliveries was going so "bumpy" it dawned on me. WE ARE NOT DOING AGILE. STOP SAYING. You hear phrases the QA team, and this is what threw me over the edge, "This isn't waterfall."

Wait, what? What did you just say? This isn't waterfall. You're saying that because of what we're telling you. We're telling you that we are not going to deliver you a broken application in pieces until it is ready.

Ah ha. You don't know, nor does anyone realize you are in fact doing waterfall.

So where does waterfall come from and is it even a bad thing. My answer is no. But what is bad is not realizing you're doing it and trying to everything else in agile and act as if it is all agile.

The problem starts with this 1 single acronym. MVP. Or FMVP. FULL(AF) MVP.

I dawned on me that the MVP word is the issue here. If you give me requirements that are 30 features big. That's inherently NOT agile. You're asking for an entire product to be delivered to you. You're not pieces you're doing the whole entire thing. And this is the issue. You have to work and understand what is an actual deliverable thing.

Testing in an agile way would accommodate that just fine. What doesn't work is saying you're agile, doing waterfall and then trying to test in agile. NO, you have to wait until it's ALL working. You have to wait until we integrate the api's and we add in all the features that you want. Because that's what you requested.

Agile, if you were doing it would take the features desired but then plan deliverables of a usable part of the application.

If the app pulls data and that is what makes the app work, YOU NEED THE DATA WORKING. You can't come in, LOL, and say we're building the data along side our development. What even is that? You can't say you want to deliver this behemoth of an application and target a delivery in the future without at least planning that key items, ahem, data are coinciding with the delivery of the parts of the application. Which did I tell you is around 30 different features.

You my friend, didn't plan out a proper MVP. You planned out an entire application. That's waterfall, NOT agile.

The word flexible is not synonymous with the word agile. The ability to plan out the delivery of an application and remain flexible while doing it and deliver parts of a working application in pieces… That's agile.

I have thought of a way to communicate this and I think we as developers need to add a word, or letter, onto the phrase MVP. B, as in BARE. The BARE MINIMUM VIABLE PRODUCT. As to emphasize that if you go down the path of planning a million features (ok, more than 10) to deliver by a date you will in fact be planning waterfall.

And waterfall is ok, but sticking the agile process in front of it and calling agile – NOT OK. Because what are you going to do?… You're going to go to your delivery date, that you most likely picked out of a hat, and say "why can't we make the date?" or "Why can't QA test it." or "Why can't we give this to QA." or "Why isn't it ready yet." 😦

Because it's not working that's why.

Or better yet, you want to test the api's and give us back those api's you tested per the specs', which wasn't written by the way; that's fine. You want to test the front-end and build your automation scripts on our dummy data; that's fine. But that's not end-to-end testing and that is not delivering to you what we ultimately need to. And that's what our internal QA testing team is doing.

What I'm not going to do is hand you a boat full of features that aren't working yet and give that to QA to run through the application knowing it's not working. Btw, all-the-mean-while blowing past your cat in the hat delivery dates.

I'm not doing that to my development team and I'm not doing that to my internal QA testing team.

Realize what a BMVP is and plan for that. In that way, we can deliver parts and pieces and build the application up from there. In the end, it can be delivered and tested and then ultimately released to the business. And then we can work on other features needed and add those in from there. Agile.

Please, I implore you all, stop calling waterfall… Agile.