Innovation game: Buy a feature
Buy a feature is an innovation game to prioritise together with customers or stakeholders. I researched this prioritisation technique and thought it would be an interesting experiment to try to apply this to our OKR planning instead. This is would certainly be a perfect match for my collaborative ownership repertoire.
While we had great interest from our stakeholders we had to cancel the event due to the mandatory home office caused by the spread of the COVID-19 pandemic.
Struggles with Schemaless
This is not to lay blame on MongoDB. What I will describe is not inevitable. It is a shortcoming of humans and not technology. It is about how one can use tools the wrong way.
The cascade of realisations starts with a simple observation:
Our fixtures are too complicated.
…because our interface is too complicated
…because our data structure is too complicated
…because we expose nested entities
…because we nest entities within a single documents
We could have committed the same mistake with JSONB in an otherwise relational data structure. This is not a case that Schemaless is bad in general. We can prevent such issues on multiple levels.
Measuring outcomes
How do you measure outcome and not effort when there is no clear quantitative metric like revenue or churn rate to measure? Another interesting angle to look at this came from Martin Fowler that you can measure output by a measuring a change of behaviour.
Thinking about implementing metrics of behaviour might help finding a more direct path to your customers and stakeholders after all. However, the article is making a fair point that attributing the outcome to a single measure is not always easy. Even more so in component teams I believe. While this is not ideal it is still preferable to not measuring at all or measuring the wrong thing.