Waterfall? Agile? Neither? – The Product Script
I am not one to shy away from controversial topics. My dad used to say to me: “tell the truth and run”. I opted to tell the truth and stay.
In the last 20 years in software development, I have seen how the industry tries to vilify the Waterfall approach. We keep changing the names of what we do, and we really don’t need yet another SDLC method.
I find that in the process of saying Waterfall is not a good way to build software, we also threw the baby with the bathwater.
I am not saying Waterfall is great for software. I also think that Agile/SCRUM is perpetuating something that is simply not true.
To illustrate what I think is wrong, and also how to fix it – I will use a metaphor of making a movie.
No movie gets funded until what?
Until there is a script.
You can NOT begin funding, planning, casting actors, budgeting and discuss distribution until there is a script.
Why?
How can you tell how much money to raise for the production, if you do not know if the movie is a short (15 minutes) or full feature film (90 minutes), or a 6-part mini series?
How can you begin casting if you do not know if this is a biopic or an animated film?
How can you guesstimate the time it will take to produce if you have no idea if most of the filming in on location, in a sound stage, or CGI?
Now, you can say that movie-making in unlike software. Yet, I beg to differ and share an approach that will help teams use the right tool or framework for the right task.
Here is another issue movies face and needs script for – that has a parallel in software design. Do you agree that if the movie has a sequence of scenes, in which the actor falls into a river… that each scene needs to know if the hair of the actor needs to be wet or not?
Otherwise, you have an issue continuity.
It will be impossible to make a movie that have 200 different scenes, and begin in scene 97 – without knowing what happened in scene 96, and what will happen in scene 98. For that reason, I think that Agile is masking this reality by pretending that we can “just start” with an MVP, and we will iterate from there to perfection. Almost like when a clam takes a grain of sand, and simply adds layers on top until you have a pearl.
That is just not going to work for any project that is bigger than a simple feature that is INTERDEPENDENT from the rest of the world.
What happens in many cases, the feature we start with does need to talk to other components, and there NEEDS to be a spec that tells the developer what the gestalt looks like, and not just the grain of sand.
Say that we designed a human being, or an android. We identified we need a head, brain, two eyes, two ears, nose, mouth, two hands, two legs etc.
Do you agree that if we ask the developer of the eye to get going, and we will perfect it as we go – that it will simply not work?
For one, the developer KNOWS this eye will need to fit into the head – so what are those dimensions?
What is the protocol and language to transmit the eyesight to the brain? It is in color? In 4K?
Simple design considerations like these will hinder the developer from making a good eye for this project.
However, if we just wanted to build a prototype of AN EYE, without it being part of a bigger whole – then fine. Have at it, Agile along.
Thus, just like a movie needs a script BEFORE it is made, an android needs a blueprint of the sum of its’ parts – I propose we consider this for software design.
If we did spend some time on “beginning with the end in mind”, we could then get team to develop of the parts with an eye towards the gestalt. You would be able to run faster, knowing that the pieces will fit, and the sum of the components will deliver the value.
So, if this sound like Waterfall all of a sudden – let me explain why it is NOT.
Waterfall design, does not start producing anything before it is ALL thought out. Years of planning, and years of production. The fault tolerance of making physical items, is lower than software. Nonetheless, you could spend little to no planning on software design and also end up with components that do not fit with one another.
My proposal here, is to design the idea of the whole system, so engineers know what they are building ultimately. As in, know what is the movie about with broad brush strokes. And then, as they work on their components of this system, they will find themselves wondering what is in the scene before this and after…
Yet, if we tell them to start with a scene, and we will iterate from there… while it sound fun and agile, and less structured – it is also opening up a can of worms.
To be fair, a movie script does go through edits, and changes. It is NOT written in stone. However, it will also not change from a biopic to a documentary, or from action thriller to a kids animated show.
As long as the total value of the movie is shared with the team making it – you now have everyone rowing in the same direction, asking questions about their part relative to the rest of the parts and so on.
Some planing, to explain the totality of the project, then braking it into small components that clearly say how they are part of the complete story, will provide both agility and speed, and the benefits of knowing what are we building.
References and Quotes:
When NASA Lost a Spacecraft Due to a Metric Math Mistake
“I have already made this paper too long, for which I must crave pardon, not having now time to make it shorter.”
-Benjamin Franklin
