The work of a Scrum Development Team is pretty complex. People with a wide range of technical skills need to organise themselves to bring multiple work-streams together and produce production-grade code in as little as 1-2 weeks. While the tasks involved are carefully planned with detailed implementation steps, the novel nature of the work means that plans need to be revised on the fly as new information comes to light. By the end of the sprint, the broad objectives and goals may have been met in ways that were not foreseen at the start. As a result, a daily synchronisation event is absolutely essential to keep focus, share information, and allow time to re-plan.
The trouble is that in the real world, there is an awful lot that can get in the way of this self-organised utopia. We regularly work with teams that see the daily scrum as irrelevant, disruptive, and boring. They are often right. Here are three common anti-patterns and three potential solutions.
1. The team is all working on separate things
Scenario: A team works together in the same functional area of IT, perhaps maintaining the same software product, but the pattern of work is such that each individual works on their own task for a few days or weeks at a time, such as:
- Small client projects
- Business-as-usual minor enhancements
- Configuration changes
Of course, the team members help each other out when needed and there’s the monthly curry-night to keep up morale, but people find very little value in getting daily updates on the meetings their colleagues attended.
Potential Solution: Change the Process
Scrum is optimised for complex work, originally in the software product development space. Teams work closely together towards regular incremental goals, that form part of a long-term product strategy. If this is not what your team are doing, then maybe there are other modern, productive delivery processes that might be a better fit. Kanban is the obvious mainstream example, and adopting this methodology would allow your team to:
- Define the service your team is providing
- Visualise your process and populate it with work
- Design a series of events that is optimised for the work you are actually doing
This might lead you to conclude that a Daily Scrum is not a good fit, and perhaps a weekly catchup might serve you better.
2. ‘Mini-waterfall’ syndrome
There is a multi-disciplinary team of analysts, designers, software engineers, testers, etc. The team forms into distinct sub-teams, where groups of specialists work in batches, handing work over throughout the Sprint. During the Daily Scrum, the following comments may be overheard:
- “I can’t start on that until you’ve deployed it to the QA environment”
- “I haven’t finished the specs for that, but maybe you can pick it up tomorrow”
- “Hmmm, I wonder if we should start having a separate testing sprint after we’re code-complete…”
The value of meeting face to face to figure out how to creatively meet shared goals is beaten into submission by rigid “waterfall” handover procedures.
Potential Solution: Change the work
Some teams really are doing complex work that is a good fit for Scrum, but they are still organising this work in a batch-based or individual-focused way. For a daily scrum to make sense, the somewhat superficial act of batching work together into 2-week chunks is not enough. Fundamental changes to the way the work is done are also required:
Find technical solutions enabling non-sequential work, rather than following a mini-waterfall. For example:
- Implementing automated tests while others write the software
- Effective use of continuous integration and a well thought-through source control strategy
- Building (or re-building) the product using modern architectures that allow many developers to work on the system without the need for complicated merge and integration issues
Establish a common purpose, such as a Sprint Goal. Creating a high-level business objective at the start of the Sprint gives teams something to focus on during the daily scrum, and if all team members are playing a part in meeting this goal then one of the main barriers to creative whole-team collaboration has been cleared.
Reduce the amount of parallel work by helping team mates work together on a single feature. This might be done by pair-programming, especially by people with different specialisms. A database programmer pairing with a UI developer will increase the flexibility and skill levels of the team.
3. Self-organisation is a buzz word that has little practical meaning for the team
The team is not engaged in their plan for theSsprint and has no idea how much will be done by the end. The Sprint Backlog is just a dumping ground for tasks, with work routinely carried over from one sprint to the next. Tools like burn-down charts are a Scrum Master thing and the team don’t pay much attention to them. A typical “update” at the daily scrum follows the same well-trodden path:
“Yesterday I did task 342 and went to a meeting. Today I will go to another meeting and start task 471. I have no impediments.
Very little ever changes. The sole outcome of the daily scrum is that each individual takes 2-3 minutes to make their own plan for the day, with an audience of their peers (probably taking a sneaky look at their mobile phones). Worse still, it becomes a reporting session where developers feel that they have to justify their work over the past day, and be assigned new tasks.
Potential Solution: Change the Culture
People have a natural instinct to organise themselves in groups, but it takes skill and experience to apply this to building software. This is especially true if people are accustomed to being assigned tasks and do not see the benefit of self-organisation. Even skilled people will struggle if operating within unnecessary constraints. This situation may be improved by:
- Training the team at the start so that everyone understands this style of working, either informally by the scrum master or by attending a course
- Establishing clear accountabilities, so the team understand that they are collectively responsible for maximising the value delivered by the end of the Sprint
- Coaching the team to actively manage their work, keeping track of their forecast and escalating to the product owner if they foresee a need to adjust the scope of the Sprint
- Working with the leaders of the organisation to establish a culture of autonomy for technical teams, where constraints are limited, and those present are based on genuine IT strategy
The Daily Scrum is highly revealing of team dynamics
During my time as a Scrum Master I found that this event was highly revealing of the dynamics at play within the teams I worked with. In most cases, problems observed during the daily scrum pointed to deeper problems and were a starting point to help teams improve. In these cases, tackling the symptom directly was ineffective until the root cause had been addressed:
- Routine lateness for a team in London was not solved by moving the time of the event, but by addressing the unhappiness at a change in technical strategy
- Technical problems for a distributed team across Europe and Asia were not solved with new video conferencing facilities, but by ensuring that the whole team were included in product strategy meetings
A genuinely self-organising team is as powerful as it is rare. Daily Scrums become focused but unstructured as the group takes control and explores the possibilities of the day ahead. Getting there takes time, skill, and commitment on the part of the team; and attention to the things that might be holding them back on the part of their Scrum Master.
This article was first published at Agility in Mind