This article is one of a series on Scrum, The Good Bits.
One of the central principles of “Scrum that doesn’t suck” is to maximize useful communication. If you load too much process on top of that, you actively inhibit communication. In theory, daily standups are a communication tool. The general process of daily standups is pretty simple:
- Everyone gathers around the Todo list (Project Backlog) at the beginning of the day
- Everyone takes turns to say: which task they worked on yesterday; which they’ll work on today; how close to completion each task is (Burndown)
- People also raise risks and impediments that are slowing them down
- No-one talks for more than a couple of minutes
Developers and Project Managers find almost infinite ways to screw up this simple process, from treating Burndown as a measure of how hard people are working, to allowing deeply technical debate to break out in the middle of them while everyone else is standing around getting bored, to squabbling about if people are attending the meeting as Chickens or Pigs (seriously, people actually do this).
I’m going to talk about what I think are the two most useful types of communication you get from the daily standups, and the minimum viable process needed to accomplish these. Specifically, we’re going to talk through:
- Avoiding nasty surprises
- Increasing collaboration
Avoiding Nasty Surprises
Software development is full of surprises – often unpleasant ones. What turns an unpleasant surprise in to a truly nasty surprise is when it’s too late to fix it or do anything about it.
When a given task is a lot more complicated than anyone thought, that’s an unpleasant surprise. When the developer working on it has kept quiet about that, and they’re three weeks and half way in to solving a task that was meant to take a day, and you’re releasing at the end of this week, that’s a nasty surprise.
When a junior developer has decided they need to build a whole new framework to solve a relatively simple problem, and they’ve started building it instead of fixing the problem, that’s an unpleasant surprise. When they’ve a week in to it, and have been making difficult-to-undo changes to support it, that’s a nasty surprise.
When your remote developer can’t access the issue tracker, and so has been ignoring bugs, that’s an unpleasant surprise. When you’ve been assuming they’re close to a fix a week later to find out they haven’t even started on it, that’s a nasty surprise.
When one of your senior developers is making great progress, but has chosen an interesting looking item from the very bottom of the Todo list rather than working on a far more urgent feature you were sure someone was doing, that’s a nasty surprise.
Daily standups are a great way to find out about unpleasant surprises before they become nasty surprises. Senior developers should be able to spot unpleasant surprises by listening to what the other developers are working on, and why it’s taking them so long. Project Managers should be able to elicit and start fixing process-based impediments (“I can’t test this until I can get a power cable for the handheld device ordered”) in good time. And Product Owners (or Customers) should be able to flag that everyone’s building the wrong thing, a long long time before it’s built.
There are teams where the Senior Developer, Project Manager, and Product Owner is the same person, and while not ideal, sometimes that’s the reality, and that’s ok.
Organize daily standups to catch unpleasant surprises early. Don’t assume as a Senior Developer or Project Manager or Product Owner that you’ll be able to easily spot all forms of unpleasant surprises turning in to nasty surprises – it’s a team effort. Perhaps your Junior Developer has already been told by Technical Services that there’s no way in hell they’ll support a solution based on WordPress, and the Senior Developer is midway through planning his WordPress solution.
Don’t assume that unpleasant surprises are anyone’s fault. They’re a constant in development – the goal is to stop them going nasty
The most difficult developer to add to a project is generally the second one. Whatever a given developer’s failings, as long as they have a reasonably coherent picture in their head of how a project should progress, then the project has a reasonable chance of success; the different components are designed work together (sometimes a little too closely) because the same person is writing them.
Technical debt at this point is inconvenient, and will come back to bite, but not for a while – you’re less likely to accidentally break or be confused by a system that is entirely your own work.
The second developer changes all this, largely by virtue of not being psychic. If they’re not sure how something works, and it’s not well documented (or, more likely, the documentation misses out ‘obvious’ bits), there’s large scope for confusion and misunderstanding. The original developer may not remember off the top of their head why they did things a certain way, may not have the time to answer, probably won’t remember all the nuances of the problem, or occasionally may even get defensive when asked about their design decisions by the new developer.
If you have a period of the day where everyone briefly summarizes what they’re working on, what they’re struggling with, and what the approach they’re taking is, then you have a period of the day for people to remember why something works the way it does, and save each other some time.
Can this happen in an ad-hoc manner? Of course. But it’s not always obvious who the right person to ask about a given component is, and it’s not always the obvious person who has the best insight in to it. Perhaps the original developer doesn’t remember why they didn’t use ActiveMQ, but the Project Manager remembers the meeting with Technical Services where they explained why they wouldn’t support it, or perhaps the best insight in to how to work with a given component doesn’t come from the original developer, but from another developer who’s interfaced with it recently.
Organize daily standups to capture insights on development tasks from the whole team, rather than finding the developers on the team accidentally duplicating each others work, or developing multiple and exclusive systems for doing the same thing.
As with all things Scrum and Agile, focus on why you’re following certain processes, and if you don’t understand why, stop doing them. If your daily standups are no longer functioning as an communication tool, you’ve lost the plot somewhere along the line.
If you don’t currently use daily standups, and you want to improve communication, addressing the issues above, give them a go. Design your process around the two principles above – whether that’s requiring developers to send a daily email at the beginning of the day about what they’re working on, and why, and how it’s going, or whether you do physically meetup, stand up, and follow the traditional Scrum standup structure.