🗞 Stream Recap: Product Planning
Engineering Culture #15—Here's what you missed
Hey it’s Denis—before we start, the next book club cohort is starting next week. Book of choice is Accelerate. Agenda is speed reading + holding each other accountable to apply. Want to join?
Talking Points
“Is technical debt a project by itself or part of the actual project?“
“On the day you touch the ticket and find out that it is too big and cut it into more tickets. What happens with your deadline? Will it move?”
“Use event models as a means of planning a project. The slices define a non-negotiable one-sized logical unit that can be planned to a high degree of certainty.“
“Estimates are used by the C-suite to make decisions—kill project, add people, renegotiate terms. And all of them suck if made late in the project.”
“Stakeholders don’t care about when will it be done.”
“Will it be done before I want to kill it [the project]?”
“The important question is done by then—why?“
“Done to stakeholders means you can now work on something else. They expect lead time—time on the calendar.“
“Engineers favour cycle time when asked for estimates.”
“At a high level we manage projects to manage risk—all high-level decisions are harmful if done too late.“
Bad outcomes: “We’ll do our best and at the end of the project we’ll course-correct.” This is terrible, you’ve just spent your entire budget!
“If you have X amount of budget, you need to make improvements (and several launches) within that amount. Otherwise you play a very risk game.”
“Early in our career we get told: Your most important responsibility in tech is giving accurate estimates.“ 🤮
“#NoEstimates does not mean it’s done when it’s done. It will give you a projection based on data that is available, when it’s available.“
“Estimates are not grounded in reality. It’s not data-driven. It is always a guess and never accurate.”
We explored a practical example of gathering data from JIRA.
“Agile doesn’t maximise speed or velocity. You’re not running with your computer. Agile is about shortening feedback cycle to an optimum. This retains decision-making ability.”
“Does everybody agree with what the priorities are? If yes, does everybody stop work every day or every few hours to ask for feedback? This is the goal of trunk-based development that Agile enables.“
“Are you building the right thing? Are you building it the right way?”
“The flow of confidence throughout the duration of a project follows the quality of your guarantees.”
“Estimates are a bad guarantee—they lower confidence. Confidence into the project, confidence into the team, confidence into the process.”
Stakeholders: “When the team is late, stop asking them when they are going to be done. They already got an estimate wrong—don’t make them estimate another layer of progress on top of that. It’s nonsense. Use the data that you have, instead. A late teams has tons of that.”
“Make sure that for the first projection you use solid data points. You can guesstimate on top of that, but avoid starting with a blind guess.”
“The person with an incentive to add to the backlog should be different from the person incentivised to cut scope from it. Product prioritises, engineering pulls.”
Recordings
Highlights (AI)
Data-driven decision making in product planning
📊 Using data from management software can augment, replace, or add another data point to estimation in product planning.
🤔 The risk is that making these decisions at the end of the project can be harmful, so it's important to involve non-technical stakeholders throughout the process.
💡 Agile product development involves conducting experiments and gathering data to make informed decisions about whether to turn a concept into a permanent product, allowing for continuous growth and adaptation.
🕰️ Traditional estimation methods have proven to be ineffective, with 40-60% of projects being late, highlighting the need for a shift towards data-driven approaches in product planning.
💭 Without confidence in data analysis, teams often resort to guessing and subjective discussions, leading to inefficient decision-making processes.
💡 When planning a product, always use data as the first decision point, rather than relying on guessing and estimation.
Importance of refactoring and technical depth management
💡 "You either trust the process or you got to change the process."
🤔 Managing technical depth is crucial for parts of a project that are on the critical path of the value stream and generate revenue.
🤔 It is important to be skeptical of the urge to throw away valuable code and rewrite it, as refactoring can make the code even more valuable by opening up opportunities for future changes.
🔄 Preemptively refactoring code on the critical path during the Sprint planning phase can be valuable for future development and maintenance, especially for frequently changed components.
🏗️ Embrace refactoring on the architectural level, even if it takes a long time, by breaking it down into small steps and using continuous development techniques like branching by abstraction.
Good choice for the book club with accelerate!