Shape first vs. details first

Imagine a block of stone in front of you and that, just as the Italian artist Michelangelo had done a long time ago, you need to release a new masterpiece of Renaissance - sculpture like the famous David.

What would you do, and what approach would you take for this task?

Would you maybe start from the top and try to cut and carve head first, focusing on each detail in the head and then, using the same method bit by bit, try to release each part separately, focusing on different elements of the sculpture? Going bit by bit, you could show a portion of your art to the public before they see the entire piece, and bit by bit, chip by chip, they would experience surprise each time you create a display for them. In that way, your art would be on display in shorter cycles and with multiple iterations.

Now, the question is: How likely is it that, in the process, you would make a mistake with the body proportions or the way parts are connected?

The second approach would be to make a draft figure, a shape and then cut stone roughly along the edges. With each new iterations, you would increase the number of details as a whole. Slowly, cut by cut, and with each sand stroke, the sculpture would start popping up.

Indeed, this would take much longer. You and the audience would see results only at the end - unless you decide that you can have a limited audience of selected critics that will give you feedback along the way and valuable input on what to improve.

An alternative approach would be to start with a rough outline and focus on specific details as time passes.

Probably by now, you are getting an idea of where am I going with this analogy. We often talk about the importance of Minimum Viable Product (MVP) in software development and the SCRUM methodology to achieve what we envisioned. However, we often miss that project we often call MVP are often a fully-fledged project with lots of very detailed functionalities.

This is because nowadays, even in the startup scene, there is rarely a niche product that can start from scratch advancing from “seed to fully grown tree” without any competition. Instead, frequently, there are competitive products we need to look up to. So, starting bar has been raised significantly already. To have a competitive “MVP”, we often need to put substantially more effort.

Imagine that you want to compete in the electric car industry. So, starting with a better tricycle (often represented in MVP coaching sessions) for most customers looking to buy a new Tesla is certainly not a way to go.

That being said, if we think about SCRUM’s functional team size, multiple team orchestration, iterative process of few weeks and overly optimistic expectation of the stakeholders - it is clear the project won’t progress with the speed management would wish to.

So, what path would I choose?

It depends. From case to case, there are several questions I would need to ask, such as: Is it an existing product that needs improvement? Is it a completely new product? How eager are stakeholders to see results? Would they be okay with the mockups first approach? Can BA have a detailed vision of the product without the real thing? How many known unknowns and how many unknown unknowns are there? Do you know how you would like the end product to look?

Those and many more would give you a more clear picture of the way to go.