In part 1 we saw how to measure agile outcomes. We found a good measure for how successful our team has been, but can we measure how successful the team will be?
Think about MySpace. They were super-successful – the most popular social network in the world – until they crashed.
There are two ways that a team can go from success to failure.
1. Building the wrong thing. Like MySpace focusing on becoming a broadcaster with MySpaceTV, when the real opportunity was users uploading videos.
2. Building the thing wrong. The developers code themselves into a corner and the product stagnates due to excessive technical debt.
Building the wrong thing
In a previous chapter we looked at the core of agile: feedback loops and experiments.
A simple indicator of how agile your product is: how many experiments do you do?
In 2013, Amazon did 1976 experiments.
In 2019, Google did 464,065 experiments! But they have around 300 products so that’s only around 1500 experiments per product per year.
I’ll post soon about measuring feedback loops!
Building the thing wrong
Developers building things wrong and becoming crushed by the weight of maintenance and technical debt is clearly NOT agile.
That’s why the second most important Agile principle (after satisfying the customer) is…
Simplicity–the art of maximizing the amount of work not done–is essential
The importance of simplicity is echoed by Steve Jobs and Jeff Bezos.
Innovation is saying no to 1000 things
Steve Jobs
Always find ways to simplify”
Amazon Management Principle
Why is simplicity so important?
A complex system that works is invariably found to have evolved from a simple system that worked
John Gall
Measuring simplicity
Cognitive complexity measures how readable code is.
If you want a broader measure of maintainability then the SQALE metric includes things like security.
There are free tools like Sonarqube which measure these.
For CSS, CSS Stats measures the number of rules and average specificity.
For XSLT and HTML templates, measure megabytes of code. Less code is better. It’s a “dumb” metric but in practice it correlates highly with code quality.