Skip to main content

Commerce, coffee, and value

According to Wikipedia, commerce is the exchange of goods and services that existed as part of the human story since prehistoric times. Before currency we used to barter, then we began to use currency backed by resources like gold, and now we use fiat money (currency backed by the issuing government).

As humans we've learnt that this is the way we exchange value. When I go to a particular coffee shop on a Saturday it's because I judge that the value in the coffee given to me is better than the shop next door. I may even be willing to pay a little extra depending on the value provided. In this case, the value is the extent to which my taste buds are excited from the coffee.
An Espresso

Buying a coffee is a transaction. I pay my few dollars then get a coffee in return. Software delivery is a bit different. To deal with custom Software as a transaction is not only hard, it's also counter-intuitive. We've all come across the cliche of spending hundreds of thousands of dollars on a technically brilliant software product that no one uses.

If you deem the value in a product is delivering a technically brilliant bit of Software that satisfies requirements on a spreadsheet. Then you may be able to conduct business using this transaction mentality, but be warned this is neither effective nor is it conducive to real value. Lean thinking and hypothesis driven development is a bit different than traditional commerce. As the cool kids say it's a bit meta .

Lean development is about building the right thing. That is: to explore finding value is value itself. Explaining this to people who are new to Software can be quite difficult and sometimes as Software Delivery professionals we take this for granted. You see for many of us, we've be doing this Software thing for several years. So we understand that we have to learn quick and gather feedback effectively. For many people who have limited exposure to our industry this goes against the grain because it isn't the way we have done business for centuries.

At times we need to ease into this thinking by making transparent the value in learning fast. A (probably unpopular) suggestion I propose is to document your experiments as they are done paying close attention to the result part of the experiment.This will make transparent to others what has been tried and the result of it. This way the learnings, key metric changes, tech discoveries of your experiments are made tangible, while ensuring there's traceability. Eventually, as trusts builds within teams, you may be able to have more flexibility and freedom in running experiments and validating hypotheses. However, you won't be able to effectively experiment without showing value in experimentation to begin with. So, go forth and try to provide metavalue!


Popular posts from this blog

from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that's new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn't have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?