The Perfect Agile/Scrum Standup Redux
09 Feb 2013
One of the good things about successful software development approaches, is that what worked 7 or 8 years ago is still applicable today, despite significant changes in technologies, platforms and work environments. The How may be different now, but the What and Why remain the same.
Case in point, over nine years ago I joined a little startup building life sciences software in a small west coast Canadian city. The team was small, young and definitely inexperienced in the ways of professional software development. But we figured it out, through trial and error our team processes and daily stand ups got progressively better.
The team wasn’t afraid to suggest improvements and point out flaws when things didn’t go well. The key to successful agile/scrum/anything is absolutely having a passionate team. If you can get the right people on the bus and keep them there, you’ll do alright regardless of process.
Fast forward to today, and the development processes we’re using now are simply a refined version of what worked in years past.
The Daily Stand-up
It’s interesting to note that although our intuition can probably tell us what makes for an effective stand-up go well, we often don’t act it. For example, it takes only one question / side-discussion mid stand-up to de-rail the entire process. Daniel called for decision making to occur after the stand-up and I’ve certainly been a culprit of this. For any team member with a vested interest, it’s all too natural to immediately chime in and attempt to problem solve or dig deeper. Avoid doing this.
It’s important to recognize and call-out the end of a stand-up. Even a simple, “and that’s the stand-up“, suffices. It provides an opportunity for those with nothing further to add to get back to their work, and anyone with a deeper topic to stick around. Truth be told, discussing every question, issue or story as a team can be disrupting and exhausting.
There is a certain amount of learning that a team needs to go through in order to get better. Regular reflections are important. I’ve been in situations where certified scrum masters, project managers, etc. have been brought in to fulfill a perceived gap. With almost certainty this idea of parachuting in a hired gun never worked and led to added frustration amongst the team. It’s not until the team has convinced themselves that there is a gap or unresolvable deficiency that change became reasonable.
I agree with Daniel that the stand-up should avoid divulging into a status report. It’s important to gather around something physical, like a whiteboard, that outlines the current state of the sprint or iteration. There are digital tools (Atlasssian Jira, etc.) that replicate certain aspects of this, but nothing replaces physically moving story and task cards in front of the team. When using both digital and physical tools, please make sure that they are kept in-sync.
If there’s one piece of information to share during your standup, it’s when your current task is expected to complete. That style of update can give a better indication of progress, as opposed to simply iterating what has been completed so far, or all the minutia that remains. It also provides fodder for your team lead / product owner and anyone else that is counting on your deliverables, including your QA engineers.
Quick Tip: Aim to keep your tasks and stories small (< 3 days), it’s far easier to mentally track and report progress.
Go back and read Daniel’s post again, and follow me on Twitter.