Writing tests isn’t particularly cheap so they fall down on my priority list when creating for example prototypes or MVPs. To some degree rightly so. I don’t know What I am doing yet, therefore, the How (my implementation) is changing regularly. Having to constantly add and adjust tests, a specification of something that is still in flow, feels like a drag at this point.

So far I discussed what in my experience is (1) a good approach to software engineering projects (Ready, Learn, Do) and (2) how to adapt roadmap planning to leverage the experience of all members of your team. What I think is still missing is a discussion about responsibilities. Who is driving the Ready, Learn, Do process for a pitch we committed to? The answer to this question is part of this post.

Now that I have written a bit more on the abstract side with Potential Space (1) and Leadership and Management (2) I want to have a look at how to actually navigate through that space and towards a solution.

Working in the tech industry means transforming uncertainty into its opposite. While a drastic simplification it generally holds true, because what we do is solve problems and if the process of doing so wouldn’t be littered with unknowns there wouldn’t be anything to solve in the first place.