EN 
JA 
IT 
ES 
The Technique Trial
Over the past five years I’ve had an awesome career being a Scrum Master. I don’t make that distinction because prior to that I didn’t like being a Scrum Master, but because I wasn’t a Scrum Master at all…I was a Chemistry teacher. It is only recently that I’ve looked at these two roles and spotted some key similarities (including one that teenagers and software developers aren’t as different as you might think!). I was and still am a facilitator, a manager, an impediment remover and a change agent. So, it got me thinking that because these two roles were similar, could some of the techniques be re-applied in a different context? As it turns out, absolutely!
I wanted to write up a few techniques that I used to use in a classroom of students that I now use in a meeting room of adults. When I was involved in training people to teach, ‘Creativity in the Classroom’ was where you’d find my name on the training agenda. For me, training isn’t about conceptual ideas, but hard and fast techniques you can take away and leverage tomorrow. That is what I have focused on here. They may have longer-term outcomes, but the practices are easy and have given me great results. Note, I know they include complementary practices to Scrum and that there is no consistent theme.
Students work in pairs and feedback to help the rest of the group -> Refinement in Advance
Good for: Getting the team closer to the users and dis-aggregating ‘central command’.
Prior to a Product Backlog Refinement session (or similar) ask the Developers to share out one or two PBIs from the Product Backlog to refine in pairs. Ask them to engage with the end-users, the Product Owner, and relevant stakeholders in order to gain transparency on the ‘ask’. The pair writes the description in collaboration with the Product Owner, and may add testing criteria or anything else relevant. In short, they take time to understand the technical requirements of the PBI. Doing this in advance achieves a few things:
✔️ Knowledge of upcoming work is shared across the Developers. All members are focused on helping the rest of the team and so it generates more of a ‘one team’ feeling.
✔️ Sizing is smoother. Often Developers ask numerous technical questions to the PO which de-rail the purpose of refinement – transparency on value. If some of the Developers have been involved in detailing the PBI already, they can ‘head off’ technical questions if they aren’t relevant.
✔️ Estimating is more informed. There is more confidence in the room that forecasts are reliable.
Sharing the learning objective at the start of a unit -> Visualising a Sprint Goal
Good for: Showing everyone how they contribute to the big picture of the Sprint.
Stick your Sprint Goal at the top. That’s the aim and a single focus (ever heard of a Pyramid with two peaks?…nope, one pyramid, one focus, one Sprint Goal).
PBIs that are dependencies are in the lowest level because they need to be done first. They are the bedrock on which validation of your Sprint Goal will be successful or not. Without the bedrock, you are very unlikely to meet your goal. PBIs that are able to be done once you have resolved dependencies are the next level.
✔️The Pyramid shows how each PBI contributes to the wider picture.
✔️ Encourages buy-in from all Developers, even when they are working on something ‘tiny’, because they can see why each PBI matters.
✔️Stakeholders love it because it’s visual.
✔️You can colour triangles in during the Daily Scrum to show progress, or add/remove them as needed.
Importantly, don’t get hung up on it remaining a pyramid shape. It’s a structure for supporting transparent planning, not just making a pretty image!
Behaviour resolution -> Fictional Team Member
Good for: Empathy and re-focusing conflict amongst teams.
Scrum Teams consist of people and therefore things can get emotional. We’ve likely all been in a Sprint Retrospective when things have bubbled over and perhaps crossed the line into the ‘personal’. Try using a fictional team member with a back-story (ours is a developer called Jerry- he is logical and always fair). If a conflict is getting out of hand, get the team to sit and think about how Jerry would feel.
✔️ Participants stop thinking about how they feel and start considering how someone else does (empathy).
✔️ It removes the personal aspect of the conflict (de-escalation) and often allows a way forward.
These are just a few things that I’ve directly pulled from my teaching repertoire and there are plenty more. They focus on empowerment without ownership, equality through engagement, and leadership from within.
I haven’t gone into too much detail because I don’t believe it’s necessary. You’re all practitioners with unique circumstances, so take what you like, try the Technique Trial, and if it doesn’t work, bin it. Let’s be empirical about it.