Welcome to the Home of Scrum!

One the questions I get asked during almost every Scrum Master training course is "How do I get the team to engage in the Sprint Retrospectives?". Quite often the feeling within Scrum Teams is that once nothing is broken and the team is meeting their forecasts, there's "nothing to talk about". So 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... https://www.youtube.com/watch?v=REWeBzGuzCc 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. Unconscious Incompetence 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!? Conscious Incompetence 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. Conscious Competence With practice and patience comes competence. You have now learnt the skill and are able to apply it, but it still requires hard work and constant thought. Unconscious Competence Through hard work and persistence you eventually master the skill and it no longer requires conscious effort when doing it. You are competent without giving it any conscious thought! Most of us have experienced this in every day life 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. 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? Unconscious Incompetence 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. 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. Conscious Incompetence 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. Conscious Competence 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. Unconscious Competence But what about when your team have reached unconscious competence? They have mastered Scrum and are continuously seeking improvement. So you're probably thinking that now 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 start the whole thing all over again at organisational level. Enjoy! Summary As with all models, the conscious competence matrix is a simplification. Don't confuse the map with the terrain. But just because it's a simplification doesn't mean that it's not useful in some situations. If you are a Scrum Master and your teams are not engaging with the Sprint Retrospectives and you recognise these patterns then it might be helpful to think of your team as having got comfortable in the "consciously competence" stage and your job is to gently push them out of their comfort zone!

More "Cha-Ching!" if your Scrum Values are alive!

Are you a Business Analyst and do you currently fulfill the role of the Product Owner? Or otherwise the Product Owner may have delegated some tasks to you, for lack of time to deal with those themselves.

An introduction of the Brazilian - Portuguese edition of the paper "The 8 Stances of a Scrum Master". The translation and new visualizations are created by Fabio Fioratti Azevedo and Danilo Almeida.