Attainable Newsletter

Share this post

Measurements and the new Agile

newsletter.attainable.engineer

Measurements and the new Agile

A few examples from around the internet that represent a renewed energy for measuring our work.

Attainable
Feb 24
Share this post

Measurements and the new Agile

newsletter.attainable.engineer

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.

silhouette of hills at golden hour
Photo by Robert Murray on Unsplash

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.

John Cutler
wrote a really great comparison of incremental progress vs. feature factories.

The Beautiful Mess
TBM 7/52: Two Bets
I made this single page cheat sheet covering bets, models, measures, goals, etc. It may be a helpful companion to Bets, Success Metrics, and Roadmapping…
Read more
2 months ago · 43 likes · 8 comments · John Cutler

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.

Shreyas Doshi's Product Almanac
tweeted an excellent set of examples of these positions:

Twitter avatar for @shreyas
Shreyas Doshi @shreyas
Apple Pie Position: A statement that instantly elevates the person who is saying it and is simultaneously hard for anyone else to push back on, and so everyone avoids the personal risk and just nods “yes”, even though its actual value in this specific situation might be… https://t.co/01UJ8cwo8D
1:26 AM ∙ Feb 23, 2023
1,757Likes201Retweets

And to wrap up this article, I find Dare’s perspective to be the most honest and on-the-nose:

Twitter avatar for @Carnage4Life
Dare Obasanjo @Carnage4Life
Product managers across tech will need to become versed in spelling out the MEASURABLE way that their team 1. Improves the customer experience. 2. Grows revenue or cuts costs for the business If you can’t then the question is why your product or team would be missed?
10:23 PM ∙ Jan 22, 2023
198Likes26Retweets

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.

Share Attainable Newsletter

Share this post

Measurements and the new Agile

newsletter.attainable.engineer
Previous
Comments
TopNew

No posts

Ready for more?

© 2023 Attainable
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing