In the last couple of years I’ve met a few people who have been challenged by balancing building a product suitable for everyone versus building a customised product suitable for … Continue reading Product through customers
I’ve talked previously about technical debt. Should we stop other work to address it? What is the cost of delay? And that we should watch out for technical bankruptcy. But … Continue reading How much time should we put aside for tech debt?
In all organisations it’s really important to be delivering the most valuable thing, and in many organisations it’s obvious what that is—and people just get on with it. But in … Continue reading Estimating value bottom up and top down
It’s well-established within the agile world that delivery teams—and particularly individuals—are terrible at estimation. We do estimate, still, and hopefully we get better with time, comparing forthcoming work with past … Continue reading Flat pack estimation
I’ve been having fun this week watching some conference talks about my current favourite language, Elm, at Elm Europe 2017. And I enjoyed seeing an important idea discussed—important not just … Continue reading Always build for real people’s real problems
Sometimes a piece of analysis work can be very open-ended, or at least there is a danger that it might go on too long. Examples I’ve come across are reviewing … Continue reading Hubbard’s powerful question: What decision do we want to support?
Last week I wrote about the value of stopping work to tackle tech debt, and more specifically when we might expect to recover from the temporary stoppage. In the ensuing … Continue reading The cost of delay of technical debt
One of the questions that arises with many teams I work with is: Is it worth spending an iteration (or more) not delivering any features but just working on our … Continue reading Should we stop to address technical debt…?
A colleague pointed me to a nice article by Sue Davis about writing for the public, and among the suggestions was the idea of timeboxing feedback: “If you don’t, the … Continue reading The benefits of timeboxing a solution
Most project teams I work with prioritise their work in a simple order: most important, second most important, etc. But sometimes people still use the MoSCoW method, and I find … Continue reading There’s trouble in MoSCoW