Definition of value is not that easy…

Yes, we finally finished all of our upfront planning and started coding on Project Swarm just yesterday.. what an awesome feeling to see things growing that good!

But, there is a problem..

.. which sounds less problematic in the first place…we fell in love with details!

Yeah, actually we discussed two hours about a feature (it’s a truly awesome one btw.) we didn’t need at all within the whole MVP phase.. But we dug in this deep, we nearly tried to code it — which would’ve cost us a lot of time.. like really A LOT OF TIME.

Gladly we didn’t actually start and moved on to the real problems within our MVP — the LEAN concept saved us! In many ways it’s necessary to love what you do, but sometimes it’s the best to not value problems your own — you’re always the most fascinated person!

Most of the time you start thinking about features you don’t even need at all (or at a much later stage).

So this led us to think about how we could value and rank features regarding it’s importance, by keeping the vision in mind — but still act LEAN.

1) Get a Whiteboard

No, like really — draw the first functional relations down and try 
to eliminate every “non-value-creating-thingy”.

Which meant in our case:

Project Swarm is about digitalize a city by collecting already provided data as well as implementing new sensors for atm. not digitalized devices. Second, collect the data and visualize it within a dashboard, as well as predict future performance based on an algorithm underneath.

2) Cut out the noise

The minimum effort we could model was to get data from many sensors aggregated to our server and display them in a simple list & provide real-time updates with relay!

This took us about three hours — and everybody understood the vision!

3) Avoid complexity

Sure we are using “dummy-data” within all of our “sensors” (actually Node.JS installed with a script on a bunch of Raspberries ;) ), but in the end we started the absolute basic setup and iteration now begins within every part of the final vision.

Horizonzal Iteration:
Every change of the functional design, infrastrucutre within the system or anything which adds a complete new feature is described as a horizontal iteration.

Vertical Iteration:
Optimizing an exisiting part of the system or feature, is declared as vertical iteration. It’s related to an existing object and is focused on details rather than changes to the whole system.

4) Iteration means learning

The MVP phase is about learning, which means always ask why something happened the way it did and why not! It’s much easier to understand a problem within a less complex environment as in a final “black box”.

Eric Ries mentioned this technique which Taiichi Ohno — one of the inventors of the Toyota Production System — invented.

“When something goes wrong, we tend to see it as a crisis and seek to blame. A better way is to see it as a learning opportunity. Not in the existential sense of general self-improvement. Instead, we can use the technique of asking why five times to get to the root cause of the problem.”

In other words, save yourself a lot of time and solve problems in early stages instead of hacking. The solutions doesn’t meant to be perfect, but it needs to be repeatable & clear for everyone working with it.