Measurements and the new Agile
Measurements and the new Agile
A few examples from around the internet that represent a renewed energy for measuring our work.
As I’ve written here and here, it is pretty clear there will be a new “agile” coming soon, and I believe we’ll create it with all the good parts from old ideas, and include new rigor for business value. It’s not surprising, tech is an industry fraught with ebbs and flows of trends and styles. This time however, feels different to this engineer, and I for one welcome our new measurement overlords. I believe with this new path, we’ll avoid all of the apple pie positions we’ve faced over the last decade or more. We’ll transform what was an old way to predict the delivery of a product, and turn it into a new way to measure the outcomes after delivery.
One thing we should all recognize: The current state of tech is not burdened by slow or difficult delivery patterns for software. What I mean to say is, we are not stuck in problems that don’t have some prior art or references to previous success. We can build software and deliver it to users really quickly nowadays. Even cutting-edge technology is being delivered extremely fast, and some could argue way ahead of its "fit and finish".
The important questions in software development are whether your product is being used, that it works the way you believe it should, and obviously whether it’s a value some one will pay for.
Let’s poke at the phrase: “works the way you believe it should”.
A very quick and easy way to get into trouble with software products is to believe it provides value and then never follow up to check or get lulled into the sleep of bad metrics (an ode to “dashboard watching”). It’s the trap we can fall into with measurements, and defeats the purpose of them, if we don’t constantly adapt. We need reactions to measurements and change the product as needed - and change the measurements as well. Measurements are not always static. In fact the best measurements provide learning opportunities that result in more clear understanding of how and what you want to measure next.
wrote a really great comparison of incremental progress vs. feature factories.
A few takeaways I like from this are these comparisons:
the organization is a feature factory and incentivizes big-batch prescriptive projects—thus creating a vicious loop (“commit to what you will build”, “ok”, “failure!”).
I personally cringe and my palms begin to sweat when I read “commit to what you will build”. And I love the way he reframes it here as significant progress:
However, there is huge difference between estimating “work” (when will it be done), and estimating “time to make significant progress and reduce uncertainty”.
These express clearly the difference I believe we will be teasing apart in the future.
An article by Rain Leander on thenewstack.io, brings an excellent point to this measurement topic, and it regards how we have treated developers. They write:
The first thing to change is how we measure success.
And I believe this cannot be over-emphasized. We need to focus on the things we’re currently measuring and have honest questions about them. Alongside this we need to share some of the burden of failed efforts (as opposed to simply laying the fault at engineering’s feet). And to nail this point down they also write:
They must trust developers to deliver measurable results without in-person supervision, but those results must be realistic in the first place.
The “apple pie position” is another topic to bring up regarding measurements. Too often we in engineering create faux debates because we get wrapped around the axle about measuring our work. Sometimes it’s used as a cudgel to avoid efforts, and in other cases, it’s used in ways that stifle creativity.
tweeted an excellent set of examples of these positions:
And to wrap up this article, I find Dare’s perspective to be the most honest and on-the-nose:
Software engineers are involved in this, and we shouldn’t simply be passengers. We should ask our team/company about the way we’re measuring our work. Our tools need to change as well … more to come from Attainable on this. Stay tuned.