Notes, reading this article. Has some zingers in here , hah!
The iron cross, maybe without one leg?
You can’t cheat the scope–time–quality triangle. If we try to fix time and scope, quality takes the hit. In a developer-facing product, degraded quality means support escalations, technical debt, and broken trust. Like any debt, technical debt must be paid back, and its interest compounds over time.
I have heard many variations of this. The one I like, maybe most, forget precisely where heard it maybe Shane de la Moore, is to not even consider quality as a degree of freedom, just consider that a non-negotiable.
And yea Robert “Bob” Martin’s Clean Code likes to write this slightly differently: “good, fast, cheap, done.”
The why the what
Every iteration starts with priority. Without it, we’re just shuffling backlog tickets and reacting to the loudest voice in the room.
Proof of concepts!
"…we decided to reduce the risk by investing in more detailed refinement. It means better understanding of both the problem and the solution, including technical proposals and proofs of concept (POCs) to derisk solutions and avoid dead ends."
Conversations: can’t make everyone happy
“No one likes hard conversations. A common mistake is trying to keep everyone happy — engineering, sales, and customers — by accepting overscoped iterations and hoping it will “just work out.” It never does.”
This is well put but it doesn’t address hmm exactly how to make the scoped-prioritization-choices
focus assumed?
“Overestimating capacity: This is perhaps the most common trap I’ve seen. We plan an iteration as if it’s the only thing happening, but in reality, the team is constantly juggling maintenance, support, internal tooling, and dependencies from other teams.”
And in this list, super surprisingly I don’t see the meta-task of, well duhh, proof-of-concepting-and-planning for the next iteration. Unlike in Shape-Up, where that is deferred for a special cool-down sprint, in this article here, hmm I’m actually not seeing this kind of buffer sprint for doing the “shaping up” stuff.
Estimating, a strong maybe?
I should re-read the article but I don’t think I noted discussion of how to do the “e” word, just that you can get more “accurate” at estimating for tasks you have done before. That and I think the author leans into the underpromise-and-overdeliver ethos as well.
References
- https://www.nutrient.io/blog/what-ive-learned-about-product-iteration-planning-while-building-sdks/ , Joanna Ciesielska-Cysek .