How NOT to Run Scrum Meetings
How NOT to Run Scrum Meetings
Seven things you shouldn't do when running scrum meetings for development teams.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
Since the Agile manifesto was published in February 2001, software development has evolved into a collaborative process of rapid and constant change. Nearly fifteen years on, Agile has been pretty agile itself — with around 50 Agile practices now widely recognized, it’s one of the most popular techniques for development. Despite the diversity of tools now available, they all still share the same goal: to quickly create working results and to constantly improve upon them.
To Run or to Sprint?
Much like Agile management, Agile software development confines work to a regular, repeatable work cycle, also known as a ‘Sprint’. The aim is for developers to reach their goal in a very short timeframe – usually within one to two weeks. During each sprint, a team creates a series of products with only the most essential functionalities required so as to match the minimal time they have to work with. It is an incremental process: there will often be multiple sprints before the physical release of the product, with each new iteration of work building on from the previous one.
During a sprint, team members will check-in on a daily basis during ‘Scrum meetings’ (or ‘Daily meetings’). The main purpose of these meeting is for team members to make - and follow up - commitments to one another, and to raise any outstanding impediments to the project.
With the Rugby World Cup just last year — and the fact that it only does so every four years - it would seem unjust not to bring up a single comparison with the other type of scrum. While on the surface it may seem like the two have little in common, there are some similarities to be found. We do, however, think it’s highly important you don’t get the two confused, as that could cause tempers to flair in the meeting room.
So, without further ado, here is our list of how not to run a scrum (meeting or physical).
1. Don’t Address Too Much
To non-rugby fans, a scrum may seem like a confusing thing. However, it only really serves one purpose: to get the ball in the hands of your scrum-half. Similarly, you don’t want to over-complicate a scrum meeting. Generally, you should only address the following 3 topics:
- What has been done since the last scrum meeting?
- What will be done before the next meeting?
- What impediments are being faced which may block/slow down the work?
(Remember, scrum meetings are there to capture the issues recognized, not resolve them).
2. Don’t Sit Down
While this may seem obvious in rugby - unless your intention is to be squashed by 10 or so 18st men – the same might not be said for a meeting. However, the whole purpose of scrum meetings is for them to take no longer than they need to be. So, standing is a sure and simple way to cause a short, high-energy meeting, and will help make sure it doesn’t last any longer than fifteen minutes.
3. Don’t Lose Focus
This, of course, should apply for the whole game of rugby and your entire working day. If your daily scrum meetings seem to be unfocused even though everyone has lots to talk about, consider finding a directive. Have team members point at tasks on a task board as they talk about their work. This helps differentiate between topics that are directly related to the sprint work and those that aren’t.
4. Don’t Neglect the Coach
It’s a common theme in all sports where a talented team of players underperform due to bad coaching, and vice-versa. For a lot of work teams, the transition to the high-effectiveness, high-efficiency nature of sprints can be difficult to settle in to. Therefore, it may be useful to utilize the expertise of an onsite Agile coach to observe and give feedback on the success of their meetings.
5. Don’t Do It All Alone
Rugby is a team sport; and sprints, scrum meetings and all Agile practices should be team efforts as well. Pair Programming sees two developers — a ‘driver’ and a ‘navigator’ — work collaboratively on a single screen. This encourages better communication and clarification of the problem, and a better understanding of the solution. The intended result is a higher-quality product with fewer defects.
6. Don’t Forget Your Boots!
Perhaps the most important ‘don’t’ of all. Professional rugby players aren’t expected to play without their boots, so why should programmers struggle on without the proper equipment?
Published at DZone with permission of Josh Anderson , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.