If your Retrospectives are boring then maybe your team is just incompetent
ok, so apologies for the click-baity title but so long as you're here...
Why doesn't my team have anything to say in the Sprint Retrospective?
One the questions people ask at almost every Scrum Master training session I run is "How do I get the team to engage in the Sprint Retrospectives?"
Quite often this is followed by nodding from other members of the class and people will shrug and say "We've got nothing to discuss so it's really difficult to find something to talk about every couple of weeks."
And I've been thinking about this and how the conscious competence matrix might be a useful model when thinking about...
What challenges a Scrum Team might typically face as they mature in their understanding of Scrum
What the team should be discussing at their Retrospectives
What questions the Scrum Master will typically be answering and what questions the Scrum Master should be asking
... bear with me and I'll try not to get too "Donald Rumsfeld" about the whole thing...
The Conscious Competence Matrix
If you're not familiar with the conscious competence matrix (it's also referred to as the four stages of competence and the conscious competence ladder) then it's a simple theory of learning that states people go through four phases when they are learning any new skill and I've observed this with most of my Scrum Teams.
With any new skill you start off not only not knowing something (in this case Scrum) but also not knowing what you don't know. At this stage people typically think that the thing they don't know is easier than it is... because they aren't aware of everything that they don't know. In the case of Scrum people might think that the Scrum Guide is only 19 pages so even though they haven't read it yet or delivered anything using Scrum, how difficult can it be!?
Only once you've begun your learning journey and (crucially) tried to apply your new knowledge do you begin to realise how difficult something is, how little you actually know and how much you still have to learn. At this stage competence (never mind mastery!) can appear out of reach and this is why a drop in confidence often occurs with people doubting that they can ever master this thing. This is when people need most support.
But practice makes perfect... or at least competent in this case. Hooray, you're no longer incompetent! You have now learnt the skill and are able to apply it, but it still requires hard work and constant thought.
Through hard work and repetition you complete your journey to mastery and you no longer have to even think about it to make it happen. You are competent without giving it any conscious thought!
Most of us have experienced this
If you've learnt to drive then you have very probably gone through these four stages without being aware of it. Most teenagers look forward to the day they'll be able to drive without giving a second thought to the skills involved. They assume they'll be a great driver... and then they take some driving lessons and are overwhelmed with clutch control, changing gears, staying in land and avoiding moving cars (and sometimes parked cars!) at the same time. Sometimes there are tears. You might want to give up at this stage and most people at some point start to doubt whether they'll ever be able to drive. But with persistence and support and more lessons, everything slowly starts to come together. You pass your test. Time passes and then one day you find that you've arrived at your destination and you didn't think about changing gears or balancing the clutch even once.
Congratulations, you're an unconsciously competent driver!
So what has this got to do with Scrum?
Scrum and the Four Stages of Competence
In my experience most teams who are starting off with Scrum think it will be easy.
The Scrum Guide is only 19 pages. It's easy to understand. Scrum is all about having a 15 minute meeting every day. No big deal. It's all a jolly adventure!
As a Scrum Master, most of the questions you'll be asked at this stage will be about Scrum and the mechanics. When can we ask for feedback from stakeholders? What should we talk about at the Daily Scrum. What's a Burn-Down Chart? Should we be using sticky notes or JIRA?
And then they fail. They get to the end of the Sprint and nothing is done. They didn't have the skills to produce done work. Or they didn't allow enough time for testing or deployment or documentation or peer-reviewing or whatever. Or they'll try to present things at the Sprint Review that aren't done or documented or fully tested or meeting some criteria of your Definition of Done or User Acceptance Criteria and they'll be presenting things as "done" which the stakeholders haven't seen and aren't happy to accept.
They'll fail and they won't be happy about it and it will be Scrum's fault.
They're ready to move onto the next stage.
Questions you might hear in the Sprint Retrospective: Why can't we test this next Sprint?
Once the team realise that Scrum can be difficult to master their confidence can drop and as a Scrum Master you'll want to guide them towards the realisation that they can get stuff done with Scrum.
Some teams will struggle with the idea of getting anything done within a couple of week if done means tested. They might have long testing cycles, they might rely on external teams or they might have a long manual process for regression testing. At this stage, the path to Scrum Mastery can seen unattainable for some teams. There's so much they need to learn. It can often be easier just to give up and go back to the old way of doing things.
As a Scrum Master you'll want to encourage them to incrementally improve, ensure they understand the value that Professional Scrum can bring to the team and the organisation and help them improve their technical practices to enable more agility.
Questions you might hear in the Sprint Retrospective: How on earth can we design, develop, test and deploy something all in one Sprint?
As a team begins to apply Scrum they'll typically struggle to put together reliable forecasts of what they can achieve and so their output can be unstable. They might under-commit and then over-commit and then under-commit again as they struggle with the discipline that Scrum requires.
Their Scrum is possibly a little robotic but they are definitely doing Scrum. And this is where the true click-baitiness of blog title is exposed because boring Retrospectives probably aren't a product of your team being incompetent, they're more probably an indication that your team is merely consciously competent. They've doing Scrum but they aren't trying to get better.
Because in my experience a lot of teams lose sight of why they are doing Scrum. Scrum is an empirical process control framework, designed to facilitate continuous improvement of your product and your processes. But teams often stop trying to improve when they stop failing. They accept being okay, rather than striving to be outstanding.
And that's why they sit in their Sprint Retrospectives and don't have anything to say. Because they aren't thinking about how they can be "15% better" or even 1% better. They aren't suggesting small experiments with new technology. They aren't thinking about the Product Vision and what they could contribute to it. They aren't thinking about team dynamics and how they could learn a new skill to make someone else's life easier and the team more productive. They aren't thinking about how they can engage the stakeholders and get faster feedback. They aren't discussing whether they can implement automated testing and CI/CD and push button releases to minimise cycle time and increase agility. They aren't thinking about paying down technical debt or whether trying Pair Programming might reduce bugs or whether their peer-reviews are helping to maintain code quality. They aren't asking their users how satisfied they are with the product and what they could be doing better. They aren't striving to be the best version of themselves they can possibly be because they're happy with being okay.
As a Scrum Master this can be your greatest challenge. Realising that just because things aren't constantly broken your work isn't done, in fact your work may be just beginning. As an experiment if you're in one of these Retrospectives try something new, try asking the team what they'd need to do to increase their productivity by 1,000%. The art of the possible. Brain-storm. Note down every suggestion. Then ask why they aren't doing these things. Then put together a backlog of all these reasons and excuses and impediments and start working through them.
This is where the hard work really starts.
Questions you might hear in the Sprint Retrospective: Do we really need a Sprint Retrospective every Sprint?
Once your team have truly mastered Scrum and are continuously seeking improvement you're probably thinking that you can take it easy. Sprint Retrospectives take care of themselves so it's time for you to put your feet up?
Think again. This is where you get to do the whole thing all over again at organisational level.
Questions you might hear in the Sprint Retrospective: Maybe you don't even need to be at the Sprint Retrospective!