In my previous post, I discussed deliverying value over tech obsession.
Changing to a value-driven mindset is a journey. In this post I go a bit more hands-on and outline a couple of key topics that have helped me on mine so far.

The agile movement and Scrum

Agile development is all about delivering value as early and often as possible.
In Scrum we do this through sprints where at the beginning of each sprint we consider what we can do in this sprint that will bring the most value to our end users.
A sprint is 1-4 weeks – with 2 week sprints seemingly the most popular.
Done right, real business value is delivered even after the first sprint.

Real agile development is a collaborative effort in which the end users are driving the needs of the application. Be vary of long-term product visions worked towards in sprints, this tends to violate this principle!

However, it is fully possible to work agile and use Scrum and still build overly complicated solutions. As developers we are still susceptible to tech obsession and it is easy to argue for over-engineered solutions even within the context of an agile Scrum team, it only requires convincing the other team members.

An agile process does not equal an agile mindset!

KISS & YAGNI

“It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupéry

Keeping solutions simple and cutting away features you are not going to need anyway, is easier said than done. While the principles are easy enough to understand, it takes practice to realize the full extend of these principles applied to software development.

Look for the simplest possible solution that will solve any given problem and try not to disregard the idea just because it might seem “ugly” and go against everything you have learned thus far. There is a good chance the simplest solution is the right approach, bringing the most value here and now to end users and that your disregard for it is based on years of indoctrination in a technology-focused mindset.

While we, as developers, tend to think of these principles more from an implementation point of view – even more important is to apply these on the conceptual level. It is easy to create product visions that will take months to implement. When approaching new product ideas, try to find the very essence of your product and think hard about what would bring the most value with the least amount of effort. Ideally you have a small prototype after the very first sprint that can already be used to illustrate the core concept.

Act like a surgeon

When building new products, we want to start as simple as possible. Every time you are introducing tooling and frameworks to your solution, you are increasing complexity. This complexity will cause hard-to-debug problems, you will have to research more in-depth how the framework or tool actually works and you will end up spending a lot of valuable time on this – time taken away from actual product development.

When the need arises and you have to introduce a framework to solve a given problem, think like a surgeon. We want to go in, fix the problem and do as little harm as possible to the surroundings.

The best frameworks solves one problem. When we introduce a framework, we want the one that fixes our problem with as little effect on the rest of our code as possible and with the least amount of additional complexity introduced. Stay away from frameworks that tries to solve every problem within a domain, these tend to be super complex and have a huge impact on the way you write your application as well as making your application much harder to debug.

Good enough is good enough

Accept solutions that are not perfect. If the solution is fit for purpose, it is good enough.
Striving for perfection tends to increase complexity and is very time consuming with diminishing returns on the value delivered.

Accept that good enough is good enough and you will be able to deliver value more frequently.