David's blog

Err and err and err but less and less and less

David's blog

Err and err and err but less and less and less

Agile

Being blocked doesn’t mean you cannot work

If you’ve been on a Scrum team for some time, you will inevitably hear someone at the stand-up say: Today I cannot work on <some feature> because of <some reason>, but that’s all right. I’m not otherwise blocked because I can also work on <some unrelated thing>. There are two (very human) factors at play […]

The one question not to ask at the standup meeting

What is the very first question one is supposed to answer during a standup meeting? If your answer is: What did you do since the last standup? then congratulations. You have given the canonical answer recommended by Mike Cohn himself. But I am now convinced that this is the wrong question to ask. When you […]

Going for one-week sprints: a good wrong idea

A few weeks ago, our team held a sprint retrospective (which I unfortunately couldn’t attend) during which it was decided to shorten our sprint length from two weeks to one. The team was right in their decision, but probably for the wrong reasons and here’s why I think so. The main driver behind this decision […]

Scrum stories that are juuuust right

On thing has been bugging me for quite some time now as I observe our team at Neurobat. Most stories on our sprint board are being worked on by one developer each, leading to daily scrums where everyone reports on work that is completely independent from that of the others. Even though we encourage people […]

The only problem with daily scrums

Over the past five years, our team has attended more than 120 daily standup meetings, carefully following the “canonical” format and having each team member answer the usual questions: What did you do yesterday? What will you do today? Any impediments?   There seems to be one flaw with this format, however. The flaw is […]

Reviewer queue

During a recent sprint retrospective we raised a problem with the way we assign code reviews. Not the formal, whole-team ones, but the regular ones we solicit for each pull request. The problem was that we tend to select our reviewers based on various subjective criteria, including how well we like the person. I admit […]

Not prioritising architectural needs

From Mike Cohn’s User Stories Applied, there was this little paragraph that I think many teams (including my own) tend to forget about: Developer Responsibilities You are responsible for providing information (sometimes including your underlying assumptions and possible alternatives) to the customer in order to help her prioritize the stories. You are responsible for resisting […]

Scroll to top