Early last month I started a new job as Head of Software at Biosite Systems. Biosite create and manufacture a variety of hardware and software for access control and resource management on constructions sites in the UK. This is a significant change in direction for me, until now I’ve always been a software developer first and a manager second. In this role I’m a manager first, and a software developer second - and so far the difference has been even more significant than I was expecting.

I do weekly one-on-one meetings ¹ with everyone on my team. I do this because, with hindsight, a regular opportunity to relieve myself of frustrations and blockers, and to talk about where I wanted my role to go next is something I’ve wanted in every job I’ve had. It’s perhaps arrogant of me to assume what I wanted is what my team wants, but I do it anyway - the meetings are not for my benefit, they are for and about helping my team with whatever might be bothering them that week. I do it every week because the only way to get in front of a problem is to know about it as soon as possible. We still do sprint retrospectives as a team, because day-to-day we function as a team - but people are different and I find the conversations I have one-to-one are markedly different to those we have during the retrospectives.

In our retrospective this week I wanted to look at the “definition of done”, but during the opening one of my team brought up some issues with the sprint demos, so we talked about that instead!

It’s Monday morning, the start of a new week and half way through your sprint. Your burn-down looks like this:

Last time we talked about a sprint whose burndown was going wrong, and the actions we took. One week later and our burndown still looked like this:

In the last couple of parts of this series I’ve been talking about how we’ve been coping with sprints that went wrong. This time I want to look at a sprint that appeared to go right.

Lately I’ve been spending a lot of time thinking about slicing work. This article is about my struggle with it.

I guarantee that the first time you try vertical splitting with a team someone will say “some stories can’t be split”. There is a kernel of truth in this statement (it is obviously the case that there will be some level below which a story cannot be split any further) that makes it easy to say - but the truth is a team splitting stories almost never reaches this limit; you have to push through your instinctive reluctance to split vertically until it starts to become natural.

What’s the most important Scrum meeting? Is it the stand-up? That’s the most frequent meeting, the main synchronisation point for the team. Without the stand-up we might all end up working on the same thing, we might fail to collaborate on a story and end up with two mismatched halves, someone might be stuck and we would never know!

In my last post I rambled on about how important retrospectives are. This blog is meant to be a real story of our adoption of agile, so this time I want to write about one of our actual retrospectives - and what I learned from it.

Continuing the theme of real retrospective examples, this post is another example of a real retrospective. These posts lag somewhat behind my team’s actual work, so please forgive me if I appear to have failed to learn any lessons highlighted in the last post!

More retrospective! This time I wrote up my retrospective plan before the retrospective. Read on to find out how it went…