Watered-down to waterfall

Watered-down to waterfall

Crippling your great ideas to fit corporate logic

Remember when MVP meant validating your most radical assumptions as soon as possible? Nowadays it’s just slang for Phase 1 of the Gantt chart.

Remember when agile software development was about improving the speed and quality of your products? Now it’s about mandatory meetings and JIRA.

We’ve seen a lot of attempts to break away from the 90’s software factory assembly line logic, but while they start out as radical improvements, they end up as bland more-of-the-same approaches.

There is an insidious process that kills these great initiatives.

Step 1: introduction

A new radical idea is launched. People discover the benefits of e.g Pair Programming

Step 2: development

Fans of the concept try out different variations and discuss their experience. In the mean time adoption in the industry is limited to a few visionary companies that have great results. All of a sudden, Pair programming is hot.

Step 3: consultant adoption

An Agile consultant reads about the popularity of pair programming and starts blogging about it. Whenever she or her colleagues try it out, management starts to complain: it’s twice as expensive!

Step 4: management appeasement

In an attempt to match the progressive vision of the community with the conservative views of management, the consultants start making stuff up. This always ends up in lazy compromises. Maybe we don’t have to do unit testing anymore since 2 coders already looked at it?

Step 5: industry adoption

All of a sudden you are working in an office where you HAVE to pair. Nobody can tell you why. It’s just part of scrum, guys! The benefits get lost and another dogma is installed. It’s somehow worse than it was before.

What went wrong? It’s another game of Chinese Whispers where the Why of the practice got lost in translation.

That’s the reason why you HAVE to estimate in Story Points. That is why your sprints are 2 weeks long. That is why you need 100÷ code coverage.

As long as management doesn’t understand the Why, none of these radical ideas will fly.


Building software is hard, but don't let that stop you.

If you're building a product and feel like you could use a supportive techie in your corner, let's set up a quick chat to see if I can help you.