The classic daily standup has everyone answer three questions: What did you do yesterday? What will you do today? What is blocking you? This format often falls flat. A developer talks about what they worked on yesterday while half the team glaze over. A developer talks about what they did yesterday even though it has…… Continue reading Better standups
This week i had agile training. It stressed the importance of dedicated product owners. The trainer told us that the bare minimum is 50% of the product owners time. Where i work it’s common to have a nominal product owner who can only spare 5-10% of their time. This effectively means that 80-90% of requirements are…… Continue reading Product owners: the cold hard stats
Typically, dev targets are based on functionality delivered. This depends heavily on having very specific requirements – how do you define “done”? Its much harder than it sounds. What if the functionality is delivered but with major bugs? What if (when) the requirememt change halfway through the sprint – is that shifting the goalposts? There…… Continue reading Dev targets: measuring business value
From “Getting Real” (37signals). Underdo Your Competition Fix Time and Budget, Flex Scope Less Mass Lower Your Cost of Change Embrace Constraints Half, Not Half-Assed Start With No Hidden Costs Rinse and Repeat The book contains loads of other useful advice too. Genius.
If you’ve ever been to Paris (or anywhere else) with 50 people you will know that the bigger the group the harder it is to get anything done or to get anywhere. The length of time it takes for the group to make a decision increases drastically with the number of people in the group.…… Continue reading Why products are like a works jolly to Paris
Feedback and feedback loops are a key part of Scrum: Iterative releases/demos. Regularly get feedback from the business and from end users. Sprint velocity. Velocity takes into account the accuracy of previous estimates. Retrospectives. Get feedback from the team as to how they could become more effective. Standups. Promotes feedback between members of the team.…… Continue reading Feedback loops in Scrum
A common criticism of using “relative size” is that developers tend to estimate in ideal days and then translate it to relative size. I disagree. I find myself doing the opposite. This week, when asked for an estimate i said “twice what it took us to deliver X”. Where X was a feature that we…… Continue reading Estimation: “ideal days” vs “relative size”