Squeezing the waterfall - yet another TL;DR rant about flexibility

This article is nothing new, it doesn't provide any new insights nor give you any new framework to work with. It's about rephrasing methods that work to understand the mindset of how you can do meaningful things to your customers and users instead of doing something that will be rewritten, forgotten or driven to deadlock of legacy. It will think things in software industry perspective, but heck, you can apply the mindset to anything.

This is not a framework or new ideology, it's not restricted to software. What it is restricted is product mindset instead of project mindset, I am a product professional and haven't been using this mindset to projects over and over again. If you think about projects or consulting, there might be some pitfalls, which I just didn't take into account. So product peeps regardless of your field of expertise, prepare to apply something that isn't given as a framework or ultimate thought. For god sakes, it's just a mindset, feel free to disagree and improve.

Starting to squeeze

So, why am I writing this? Just because I think agile is dead and should be deprecated. Not because it really is a good mindset, but the amount of misunderstandings and interpretations have killed the basic ideology behind agile principles. To be agile, you should only have one tool to follow - the agile principles. That's why I prefer using "flexible" instead of "agile" in this post, since in the end it's all about how flexible you're about to do things.

In my 15+ years in software industry I've seen a lot of people running towards the next silver bullet that provides you a ready-made meal of agile just to consume and become agile in some magical way. Organizations are constantly waiting for the next framework or process that makes magic happen and with a flick of a wand the whole organization is agile. But usually these superimposed frameworks end up being some sort of waterfall and not giving the edge organizations are looking for.

This is why I prefer that waterfalls should get squeezed instead of "transforming organization to agile". Even if you think about it, that's what it is, it's making things continuous instead of sequential. And the mindset of reaching it is by taking small iterative steps to reach the minimum amount of waterfalling to reach wanted outcomes faster. As a mindset "Squeezing the waterfall" is much easier to grasp as continuous development than just "turn to agile" or "take agile in use", because that's what it is - a continuous process of learning getting better in what you, your team and your organization does. It's about learning and developing through iterative experimentations. There are models and frameworks, but they lack the most important - learning through experimentation. Squeezing the waterfall is all about people getting in and learning, there's a massive difference.

Don't get me wrong. Frameworks are not all bad. They are really good starting point to start improving processes, but when you learn to ride the bike, the training wheels become useless and start to hinder your progress.

So how to identify waterfall?

A lot of you already will say that "I know what waterfall approach is and I surely can spot the difference between it and agile". I bet you do. But please check the list below, which for me are certain places to identify waterfall, and then tell me you do identify it:

• You write requirements or specifications to hand over to developers.
• You're updating product roadmap constantly, since schedules change and they don't reflect to your estimates.
• You're estimating everything beforehand on detailed level.
• You're padding the estimates with the factor that you think is uncertainty. It might be 3.14..
• Customer/user has been onboard in last meeting a couple of weeks ago or at worst, latest seen on contract negotiation.
• You are forming business cases where you are guessing things.
• You think developers are "the team". Also marketing, sales, finance and everyone else is their own team.
• You CAN work alone and most of the time you spend your time like that.
• You have a code freeze or some other freeze for testing thoroughly/manually before release.
• Your release cycle is longer than couple of weeks.
• Someone says that "It needs more specifications" or "I did it as specified".
• You have shipped a feature, but don't track how it performs and if it is even ever used.
• Most of the ideas are included as specifications when they sound like they fulfill a need.

Sounds familiar? Even though this was only a small smoke-test (I could go endlessly with these), I think you might have found out you are in need of a little squeezing.

The grand idea

Since I could write a book about this, I'll try to keep it short in this article. The grand idea behind this all is the mindset. It's about identifying the possible places where waste occurs and make them a continuous part of the process to deliver meaningful things to users/customers throug fast iterative loop.

As I said, it gives you nothing new. This has exactly the same elements or mindsets (at least partially) that is behind growth hacking, lean, agile, customer experience and <you name it>. It's about putting the customer in the center of the process and drive something useful to customers through experimentation (would say value to users/customers, but hell, it's another widely misunderstood term - please don't let me rant about MVP's).

Now let's move on how to apply. I think this article is already lengthy enough.

Step 1 - Admit it!

The first thing is the hardest! You have to admit that you're waterfalling things. It's like the 12 steps of AA - We have to admit that we are powerless over waterfall - our work has become unmanageable because of that. After you admit that you do waterfall even a tiny bit, you can proceed. Until that it's just fighting the windmills. I'm sure many of us waterfall without even noticing it, it's just so central part of many frameworks and ways to work that have been in use for tens of years that even the most agile people tend to go back to it in some form. Start identifying it and you will notice when you slip.

When you start seeing waterfall in your process, you can start to incorporate those as continuous activities. Just squeeze it until you improve, when you succeed, take the next step and iterate. Take it as continuous action instead of one-time activity. Beware that the most work you probably have to do is brainwash other people to believe that "agile" is the thing. So, evangelize the idea and make others do it too. It's a cultural change, which is always hard. Cultures tend to change most easily when ideas and good ways to work cross-pollinate to other teams.

As you see, I'm not going to give you any certain activities on how to reach the oblivious flexible processes and ways to work. If I did, it would be framework or a model, that just doesn't work. Everyone in the software industry knows the "Spotify model" - I think that it's some kind of agile wet dream of every software team, but implementing the model doesn't make you any more agile if you don't embrace the learning incorporated in the development of that model. I think even Spotify has evolved from the model to better working organization after seeing the problems in there. They're continuously discovering and delivering their process changes. Even they are constantly learning.

Step 2 - Share and automate

When you have identified the places you are water falling, stop doing it and find another way of doing those tasks through adding shared understanding and automating. I'd almost guarantee you that your work will come easier when people have the option to participate instead of reading and commenting documents. Don't leave anything undone or just skip the step, there's usually some sort of brainpower that has reasoned why things are done. Being agile doesn't mean you don't document or test - actually it's quite the opposite, need for testing and documentation might even increase.

My rule of thumb is to find exact opposite of what sounds the most reasonable thing to do. Usually it works - reasoning tends to drive towards waterfalling. And yes, I've tried and always ended up in polishing the diamond until doing the opposite.

For example when the release is always fighting in the last weeks/days. There's a fear that customers wouldn't end up in 404 or the features you ship wouldn't bring maintenance issues to next release. The easy way is to prolong the release or add some sort of "testing freeze" to the end, which means that you end up fixing bugs you created for a couple of months. Oh yeah, and you're finding them now, because well, did you test them in real environment before? Well anyway, I think these both are waterfalling the problem to the next step instead of taking it "the teams issue" in the beginning.

In these cases I love aiming for shortening the release cycle. The less you can do, the less you can do harm to yourself. I have had a pleasure to work with teams that do even tens of production updates per day and encapsulate their work so that every production push is evaluated and validated with a subset of customers before pushing it visible to all. That way they have the option to even push new features early on to customers for validation and iterate quickly. They own the requirements, specifications and the product instead of just acting as a medium for coffee that transforms into code. I know, it's not always possible, but short release cycles for sure is something you want to aim for. This is the key on how to save time and shorten the time to money instead of just shortening the whole waterfall cycle.

The last words

You can do things differently by just focusing your effort to improving the culture that drives the discovery-delivery exploration forward, stopping on any crossroads to ask where the next crossing could be. There are alternative paths to unknown locations than just the one you decided to take and walk stubbornly from start to finish - even if you run out of money or fail drastically on your optimistically defined estimates.

Just focus on building the team and their capability and the cross-functionality by breaking silos. It isn't just the devs thing, it's incorporating everyone in the same cycle of discovering, learning and delivering constantly to serve the users and customers. If you find out hand-over documents, initiate a story mapping session or something around it and make sure things go to living documentation throughout the process instead of it all rapidly decaying to soil of non-updated requirements. Make it a team issue.

This has been longer article than I thought, probably in terms of doing what I preach, it would've been better to slice it to shorter parts. Probably there is more to come, I don't know yet.

Hope you enjoyed reading!