EN 
JA 
IT 
ES 
Ain’t Nobody Got Time For That
You’ve dialled into your third MS Teams call of the day. An hour later you hang-up, wondering what the purpose of it was. Don’t worry, you think, maybe it will be more useful next week? We’ve all been there, and yet we resolve to continue to attend. Before we delve into the Scrum events, I feel it is useful to share some tips that Elon Musk told his Tesla employees:
Stop big meetings. Ditch frequent meetings. Leave a meeting if you’re not contributing. Drop jargon. Communicate directly, irrespective of hierarchy. Follow logic, not rules.
For those who aren’t aware of Musk’s charismatic leadership style, his approach is founded on empowering individuals and teams to get stuff done. His employees can expect their management to give them what they need and not stand in their way, but importantly, the team must find out what they need and make it transparent. Everyone is accountable – and this is where Scrum comes in.
Scrum Teams are effective when they self-manage. Sadly, it is a concept that is commonly misunderstood; mistaking it to mean that the team manages their entire existence without support from their organisation – this is not the case. Self-management is when a team decides who does what, when and how and importantly, the Scrum events underpin this concept. In complex environments (where more is unknown than known), having the people closest to the problem is vital. The ability to pivot rapidly, supported by a rapid time to market and tight quality controls is the core of what Business Agility actually means.
But – and there’s a big but, when Scrum Teams aren’t empowered to self-manage and control their own destiny, value will always suffer. The reason is because of Scrum’s underlying empirical feedback loop that requires frequent transparency, inspection and adaptation, but it is common for our users to be too busy to help us to inspect our work. Consequently, the Scrum events become less impactful, more formulaic and eventually get to a point where a team will say ‘can we just squish these two meetings together?’. For a Scrum Master, that is a spark about to ignite a wildfire – your team are now at a point where they don’t see the value in each Scrum event so they want to shorten them.
For those interested in why it is called a Scrum ‘event’ rather than a ‘meeting’, it’s partly down to psychology (events sound more important and impactful) but also because each has a clear outcome and actions. When there becomes a feeling of ‘ain’t nobody got time for that’ then we are missing an opportunity for our team to be able to deal with volatility and uncertainty. Things change, and the events help us to formally decide on the adaptations we need to make to improve our value offering and increase our return on investment. Scrum provides five of these events that are part of the framework, can you name them?
Daily Scrum – A 15-minute timeboxed event for the Developers (the Scrum Master and Product may attend but typically don’t participate) for them to inspect the progress made towards their Sprint Backlog in the previous 24h. Their discussions focus on the Sprint Goal and may result in items being added or removed from the Sprint Backlog.
Sprint Planning – An 8-hour timeboxed event for the entire Scrum Team to discuss the Why (Sprint Goal), What (Sprint Backlog) and How (the plan) for the Sprint. It takes a long time and when done well, mitigates the need for additional meetings.
Sprint Review – A 4-hour timeboxed event for the stakeholders (organisation and users) invited by the Product Owner to inspect the increment produced by the Scrum Team. Only work which meets the Definition of Done can be inspected and presented – but this is not simply a demonstration, it is a working discussion. The outputs and outcomes are a re-ordered Product Backlog and hopefully a better understanding of what to focus on in the next Sprint.
Sprint Retrospective – A 3-hour timeboxed event for the Scrum Team to reflect with honesty and transparency on their process. They consider what they need to improve in next Sprint and may add work to their Sprint Backlog to address these improvements.
The Sprint – The encapsulating event that holds all others. Each Sprint is a mini-project and should be treated independently from other Sprints. It provides a short focused effort on a single Sprint Goal.
Going back to Elon’s point about stopping big meetings, the timeboxes seem pretty large, right? I’d agree, but these timeboxes are maximums and not minimums; it is the outcome that matters. Self-management is fundamentally about the Scrum Team facilitating these events themselves and controlling the ecosystem of their Product. Perhaps it is helpful to liken a Scrum Team to a team of doctors? A midwife brings you into the world, doctors continually look after you and when things go wrong, they’ll put you back together. A self-managing team is cross-functional to be able to do all of these things (requirements elaboration, writing code, testing, infrastructure and release) and moves to reduce any dependencies they have on other people.
If you are in a position where the value in your Scrum events is lessening, try the BEAF approach; boundary, execution, action, finish. Begin by stating what you’re (as a collective) trying to achieve, you can limit tangents and affirm the value in everyone’s presence. Follow this up with crisp execution, focused on exactly what you are trying to achieve and nothing more. Close with assigned actions and their purpose. The fourth point is obvious but so often forgotten – if you finish early, end the event! Don’t be calendar filler. Show attendees respect by achieving the outcome and finishing early, or at least on time.
One final point to note about Scrum events, meetings and agility in general is ‘metrics’. You absolutely and unequivocally need to understand the impact of the work you do (a good resource to check-out is the Evidence-Based Management Guide) and this is often forgotten. Could you quantifiably demonstrate every Sprint that you’ve moved forward? When discussing with leadership, could you show them the money you’ve saved through an initiative? Whilst you may be in a unique situation in that you are both the client and supplier, it is not unreasonable to expect these metrics and being gathered as a tool to help us inspect ourselves. Any self-managing team should understand this.
In summary, ensure your meetings and Scrum events are purposeful for everyone. If they aren’t, you’ve got a problem, because when volatility arises, and it always does, you will be in a worse position than a team who regularly exercise an empirical feedback loop. If you aren’t sure whether your events are hitting the mark, simply consider ‘Did I offer or gain any benefit from being here?’ – if your answer is no, raise it in the next Sprint Retrospective and work with the team to fix it.
In the words of the eponymous GIF:
