Confessions of a PST Part 2: The best way to leverage Scrum is to cherry-pick your favourite bits.

Last week I made a confession in response to all the questions I get as a Professional Scrum Trainer™️ about whether Scrum “really” works: It doesn’t. 

So here’s my other confession - Scrum can have magical outcomes for you and your teams, NO MATTER the context you live and work in, but you have to be open to two things: 

1. Forget the framework altogether and instead, understand and embrace empiricism
2. Choose what works for you from the framework, then iterate on your implementation of it

Let’s talk about Number 1:

The whole reason for any person, team or organisation to adopt an agile way of working and look for a tool or framework to help them along is to LEARN QUICKER. 

Scrum is excellent for this, irrespective of your context, because it is based on the fundamental theory of empiricism - our innate human desire and ability to make experience and evidence based decisions.

To act, based on learning. To change, based on learning from that action. To do this again and again, thereby evolving as people, species and a community.

If we understand and embrace our innate desire and ability to be empirical, it becomes quite a straightforward leap to want to work this way too. And then we take a look at the framework, and see what we can take from it.

So then, for Number 2:

I believe in embracing just a few elements Scrum when you’re starting with it, whether you’re in a clear, complicated, complex or even chaotic environment. 

If you look at my personal Scrum board at home which has helped me and my husband move and settle in a new country, launch a new organisation with a solid pipeline to boot, plan and have a destination wedding, and even launch 3 new products, all within just 1 year, while we continue to have immense love and support for each other (with no ripped hairs or frown lines) - you will perhaps believe me when I say Scrum is magical in its benefits, when you know how to make it work for you. 

Here’s some things that have worked for me, and for teams I’ve worked with:

• Start with a retrospective. If you do nothing else with Scrum, run a retrospective with your team at regular intervals, with the aim of identifying improvements in your ways of working. Whether it’s starting to eat lunch together once a week or spending time automating your code, reflecting on your people and processes is singlehandedly the most important thing you can do as a team. And when done with the intention to learn and grow with ideas that come from within the team, you will end up with many more opportunities to supercharge your team’s effectiveness, more so than with having a mandated twice-monthly vent session (or just a beer fuelled party). You may even find you are picking up ideas that “sound” like Scrum (let’s plan more frequently, let’s have a daily check in, etc) or even, that you never think or hear of Scrum again!
• Decouple the review and the retro. Their purpose is separate, as is their audience. You need a very particular focus and people in the room when getting feedback on work done and work coming up, and a completely different group and space for reflecting on the people, culture and process side of things. Don’t combine them and don’t rush through either of them.
• If you’re working on a pre-planned scope to deliver within certain timelines, that’s okay! Just don’t freak out trying to order, refine and estimate backlog items, let alone trying to set Product Goals or Sprint Goals (which usually end up being a list of tasks/features) then get caught up in unrealistic burn-down charts and forecasting conversations. Understand that you do have a deadline and/or scope to work towards, set realistic expectations around completion dates (including communication the cone of uncertainty around said dates), provide regular updates to stakeholders around expected deadlines and/or scope, and be transparent with team members and stakeholders around any strategic compromises to quality that may be required. If you’re lucky, you may be able to flex the scope/deadline and prioritise quality, but this only works if we are really honest and upfront about our capacity to complete work with quality in mind.
• Make data driven decision-making a habit. Collecting data on value delivered is not as difficult as you may think - read about Evidence Based Management here - and consider visualising metrics right next to your Product and Sprint Goals and/or backlogs. Measuring value delivered not only provides the focus you and your team may need (focus being the whole purpose of Product Goals and Sprint Goals anyway), but as you go you may find opportunities with the data gathered to challenge some of the pre-planned/committed scope we were just talking about (e.g. feature usage index is showing 30% of what we’ve delivered in the last 6 months is not actually used by our customers…what might we want to move around for better ROI?).
• If you’re working in a more operational environment, or you’re just not building a product e.g. you are in a marketing or sales team, you don’t have to be working on a Product Backlog or be setting a Product Goal. Consider instead setting some OKRs, some flow metrics or other measures of value and quality to track your progress against. Take advantage of what DOES work from Scrum for you: Planning your work as a team at regular intervals, reviewing that at regular intervals, checking in on each other daily and replanning the day ahead before going about it, reflecting and improving your processes and team environment regularly, promoting cross-skilling and experimentation, etc.
• Kill the jargon. If you’re at the early stages of a team's Scrum adoption and finding the entirety challenging to implement, offer your team some of the elements in layman’s terms and let them pick what they want to try. I find it very freeing for teams to adopt Scrum without the jargon - e.g. “let’s plan our month ahead together” as opposed to ‘let’s do sprint planning’. Advise on what they may need now e.g. a retro and a planning session may be most helpful, not what perfect looks like. Take it as a baby-steps approach rather than a revolutionary one.
• Retrospect on your adoption of Scrum itself. In line with the previous point, it is important for Scrum teams at all levels of maturity to reflect on their experience with Scrum. What’s working, what’s not? What could we get rid of, what could we add on? How are we all doing in our roles, what more do we need from each other? What can we improve? Whether it’s the timing of daily, splitting the review and retro, setting goals or giving up on goals, monitoring metrics or automating deployment, Scrum teams are meant to be continuously improving their ways of working, and that includes their application of Scrum itself.

Moral of the story:

Your adoption of Scrum is best looked at as a journey. Make it an empirical one.

Will cherry-picking from Scrum limit the benefits of the framework? Quite likely. Will trying to do Scrum “by the book” give you a hard time? VERY likely.

You are much better off trying to experience some true benefits of Scrum through the cherry-picking - like collaboration, focus, engagement, quality work and a sustainable pace of delivering value - rather than the ‘perfect Scrum’. 

My assumption of course is that, as and where it applies, you aspire to adopt the framework in its entirety to be able to experience all its benefits, ensuring along the way that your environment is set up to support all the elements as intended. 

If you’re interested in doing this for your team and/or organisation, the 2 day Professional Scrum Master™️ training from scrum.org may be one for you - here are a few public courses I’ve got coming up that you could join. I promise to share more of what’s worked and what’s not, and how you may (or may not!) want to leverage Scrum in your own context.