Are we succeeding as a software team?Well, if our job were feature delivery, we could look at the parade of JIRA tickets in our “complete” column. That is only part of our job, though.The purpose of a software team is to provide valued capabilities to customers, internal or external. To do that, our software has … Read moreFive Measurements You Should Make and Then Ignore (Plus One to Watch Intently)
As a software engineer, what is your job? and what is your value? On many teams, the work is “add features to this codebase.” We congratulate teams for moving JIRA tickets from “defined” to “delivered.” Meanwhile, the value to the business depends on value to the customers, or to people or software who in turn … Read moreProduct teams own capabilities, not (only) code.
We talk about “software products” and “product teams.” What does this even mean, “product?” It is not the definition I learned in school. Economics 101: the output of the economy is “goods and services.” Goods, also called “products,” are physical items that you can buy, take home, and have. Like, if you buy a rug, … Read moreWhat is this “product” you speak of?
TL;DR: Projects ask teams do what is asked of them; Products ask teams to invent their work. This requires a different way of seeing the world, and not everyone can do it yet. Software is not an up-front investment that pays off over its use. Software is an ongoing concern, an intricate piece of a … Read moreProject to Product asks more of our software, and more of us
Just now, Avdi had a miserable experience buying curtains. He went to pick up an order that he placed last night, but Lowe’s didn’t have it. The order was sent to the wrong store and it was a huge pain to figure out. Software is hard to get right. And every time we don’t, customers … Read morethe Enterprise eats Software
In software and in business, we don’t build up from specific subtasks. We build up from broader capabilities.
Here’s a lovely graphic from the folks at Intercom. It describes the difference between what companies sell and what people buy. We don’t want the tool, we want what we can do with the tool. Take it further – maybe what that skateboarder really wants is: the high fives at the end. Our accomplishments feel … Read moreTools -> capabilities -> acclaim
In Projects to Products, Mik Kersten divides flow items in software products in four: features, defects, risks, and debt. If you only count features added and bugs fixed – changes visible externally – then you neglect the other outcome of our work: the next version of the team+software. I prefer to think of “technical debt” … Read moreIncreasing potential as a specific output of flow