In this part we focus on value. What is value, how to measure it and how to add value in software development context?
If we look at the software as an end product, it's valuable when it saves money, makes money or protects revenue [1].
When looking at software from a development point of view, it's valuable when it's easily modifiable. Therefore, the most valuable thing to do is to maintain and improve software modifiability. That is, to keep software soft, easily changeable.
Also, in our daily work, we should focus on things that produce the most value and leave less valuable things later. Sooner we produce the value, the better.
There is also the value of process. If, for example, feature requirements are fuzzy or the feature itself might have a questionable value, we should stop and remove any uncertainties. This also applies to team work where we should eliminate waste and maximize value, for example, try to eliminate unnecessary meetings with too many participants.
Adding value
To add value, we typically have to modify software somehow.
If the software is easily modifiable, it therefore implies quality, since if the modifications were easy, there should be no defects or bugs. It also implies a short feedback loop where we can easily observe the modifications.
When software is easy to change, we can quickly get feedback. Does it build? Did the tests pass? Was the deployment successful? Does it work in production as intended? If it takes long to get feedback, software is not easily modifiable.
Easy to change also implies quality, since if a change would cause a bug or other unexpected extra work the change was not easy, after all.
Ability make quick changes without bugs is valuable.
We could try to distill this into following:
Easier to Change ⇒ Short Feedback Loop ⇒ Quality ⇒ Value
It's worth noting that the software should be easily modifiable to all developers in a team, including newish junior developers (with some gentle guidance, perhaps). If making a change requires extensive experience about the project and senior developer skills, then the software is not easily modifiable.
Codebase that can be modified with ease to add, remove or modify features is just golden.
And this is the gist of it. To add value, keep software easily modifiable, or better, make it even easier to change.
Feedback loop
Fast feedback improves productivity and feedback loops occur almost everywhere.
It is not only a development time thing where we wait for feedback from the test suite.
In daily work, we need feedback on our peers in code review, for example. Is the Product Owner available when the team has questions?
And most importantly, customers need feedback on how changes impact the system. Driving business innovation requires experimentation and the faster we can experiment the better.
There is also one thing to keep in mind: feedback loops should be short even after years of intensive development. This requires some thinking ahead of how to arrange things.
Collecting metrics of various different feedback loops can be valuable. Are tests becoming slower? Number of bugs trending up? Lead time from feature request to production? etc.
Summary
Value in software development can be measured in various ways. One is the value of the delivered software product. Another is modifiability of the software: easily modifiable software is valuable. In daily work we should focus on things which produce the most value. And finally, the business value which we should keep clear in mind during development and value of the process by eliminating waste, like unnecessary meetings.
Adding value to software is essentially keeping the software easily modifiable. That is, it's not the value of the feature but the lead time from feature request to production.
Customers need quick feedback on how features form and affect the final software product. But this is not the only feedback loop in software development. Feedback loops occur almost everywhere, like test suites. Measuring different feedback loops is valuable and enables teams to react early if things start to go wrong.
In the next and final part of this blog series we talk about being a crafter at Bytecraft.
Earlier installments:
--------------
