

An introvert software consultant. Currently assigned to a web project, using React and TypeScript. In the spare time I make electronic music.
If you have 20 teams that are struggling with a web of dependencies, handoffs, and constraints…. then no amount of assigning the teams a Product Owner and Scrum Master, pretending they “own a product”, running standups and retrospectives, and giving them their own whiteboard, will really move the needle. The reality is that you have a 150 person “team”. You’ve got to deal with that.
So basically … projects aren’t the problem. They are a reasonably human concept (a container of work, something to shoot for, time-bound, an undertaking). The danger is slipping into viewing projects as a first-class citizen of software product development. In product companies, projects are vehicles, not the end-goal. You don’t get credit for adding a feature. You get credit for earning more revenue, retaining revenue, reducing costs, or preventing costs from increasing. So when you ask what someone is working on and they say “finishing project [xxxxxxx]”… make sure to…
You’ve gotta ask … how is the team actually benefiting from using the product? Is the tool helping them deliver more value to their customers? When I ask this, I’ll often hear about benefits like tracking, accountability, visibility, estimati…