For the past seven years, Medium has been a great home for my writing as Agile Batman. I’ve valued the community here and the conversations we’ve had about improving how teams work.

As my career has evolved, from developer to Scrum Master to Agile coach and now to CIO, my focus has shifted with it.

I now publish across two Substacks:

CIO from Scratch (ciofromscratch.substack.com) documents building a company operating model from scratch as a first-time startup CIO. Real decisions, real mistakes, no corporate safety net. If you want to see what it actually looks like to build something from nothing, this is where I’m writing.

The Invisible Expert (theinvisibleexpert.substack.com) is for leaders who suspect their best technical people are being wasted, and want to do something about it. And for technical people who feel invisible, and want to change that.

Thank you for the support over the years. I’ll see you at the new home.

Stephen Waring
(Agile Batman)

Agile Batman Is Evolving — Join Me at Executive Agility was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

Embarking on the journey to pass the PSM 3 exam is no small feat. It’s a very difficult exam that demands not just knowledge, but a deep understanding of Scrum and everything surrounding it. You will need to draw from your own personal experience to pass.

Having recently conquered this challenge myself, I’m here to share insights and tips to guide you through your own preparation process.

Where do you start?

One of the initial challenges is figuring out where to actually begin.

If you are anything like me, then one of the questions I had at the very start was, what do you actually study for this one? Unlike other Scrum certifications, the scope of PSM 3 is vast and the breadth of topics can be overwhelming.

When I was studying for Scaled Professional Scrum (SPS) it was easy, I’d buy the relevant books, attend some courses, learn the material, experiment in my work place, see what worked and what didn’t, take the exam.

When I was studying for the perspective of a Product Owner, again, there are lots of resources and paths to follow, and plenty of opportunities to talk to the Product Owner’s I worked with, try new things, reflect to see what worked and what didn’t, and take the exam.

But with PSM 3, I struggled to find anything other than what was available at Scrum.org:

Understanding and Applying the Scrum Framework:
Empiricism, Scrum Values, Scrum Team, Events, Artifacts, Done

Developing People and Teams:
Self-Managing Teams, Facilitation, Coaching, Mentoring, Teaching

Managing Products with Agility:
Forecasting & Release Planning, Product Value, Stakeholders & Customers

Scrum.org

That’s quite broad, nothing I hadn’t already covered, so I guess I just had to learn it better? Not quite. Mastering these concepts is not merely about learning; it’s about internalising them at a deeper level.

Read on for:

• A list of key topics to research
• A reading list of books
• Podcasts, blogs and YouTube channels I found useful
• Links to practice questions and exams to help you validate your learning
• A short description of my journey

Key topics to research

PSM 3 tests that you can connect everything together, to demonstrate that you truly understand what you need to do, and why. To pass PSM 3, it’s essential to go beyond surface-level understanding.

For any given any scenario you need to know what to do next and why you would choose that option over another. And you have to do this under immense time constraints (<5 mins per question), with no multiple choice answers to guide you. You have to just know it. It’s why it’s harder than PSM 2.

Here’s a curated list of key topics of what I believe you need to understand deeply before you attempt the PSM 3 exam. It’s not a definitive list, but a good start:

1. The essence of empiricism and its application in Scrum; transparency, inspection and adaptation
2. The significance of the Scrum values in fostering an environment of trust and collaboration
3. Nurturing self-managing teams and facilitating cross-functionality
4. Understanding what motivates people, and how autonomy, via self — management, is a key factor in motivation
5. Understand how mastery affects cross-functionality and motivation
6. Understand how having a purpose, with clear goals, can lead to increased focus and motivation
7. Understand that motivation leads to more effective teams that deliver more value, more often
8. Understand the Definition of Done and how this links to building trust, empiricism, cross-functionality, motivation and transparency, leading to inspection and adaptation to increase quality and value delivered to customers over time
9. How the Definition of Done can be used in all 5 Scrum events
10. Learn how the 3 Scrum accountabilities each enable transparency, inspection and adaptation
11. Learn how the 3 Scrum accountabilities each live the Scrum values, enabling cross-functionality and self-management and help to ensure the team gets to Done each Sprint.
12. The preferred vs mis-understood stances of a Scrum Master
13. The 3 different levels a Scrum Master operates at; within the team, relationships across teams and at an organisational level
14. How and when to deal with conflict
15. The Product Backlog artefact and it’s commitment; the Product Goal and how they link to transparency, inspection and adaptation, the Scrum values, self-management, cross-functionality and getting to Done
16. The Sprint Backlog artefact and it’s commitment; the Sprint Goal and how they link to transparency, inspection and adaptation, the Scrum values, self-management, cross-functionality and getting to Done
17. The Increment artefact and it’s commitment; the Definition of Done and how they link to transparency, inspection and adaptation, the Scrum values, self-management, cross-functionality and getting to Done
18. Technical debt and undone work, and the difference between them
19. The 5 Scrum events, their purpose and how they enable transparency, inspection and adaptation
20. Understand how to live the Scrum values in each of the Scrum events, how to enable self-management and cross-functionality and how the values help the team get to Done each Sprint
21. Why product backlog refinement is an activity, not an event and the benefits of this activity as part of product backlog management
22. How to measure value in your unique context e.g. Evidence Based Management
23. Scaling Scrum effectively in complex environments, understanding that you scale the delivery of value, not people e.g. Nexus
24. Embracing servant-leadership and its distinction from traditional management
25. Using Scrum can be beneficial when working in a complex working environment
26. Mechanical (aka zombie) Scrum vs Professional Scrum
27. Identifying and resolving common Scrum anti-patterns
28. The relationship between Scrum and Agile

Reading List

These books helped me gain a deeper understanding around Scrum and the environment teams operate in. I started by refreshing the basics, then picked books to help me understand specific topics more deeply.

Scrum Insights for practitioners by Hiren Yoshi

You could realistically read this book in a day, it’s short, and is a little bit outdated (it pre-dates the Scrum Guide 2020 update) — but it did help teach me to summarise answers relating to each aspect of Scrum so that I could deal with answering questions more quickly in the actual written exam.

Scrum Insights for Practitioners: The Scrum Guide Companion

Scrum — A Smart Travel Companion (Gunther Verheyen)

Sticking to my basics theme, I also picked up this book. It’s a physically small book and great to carry around for a quick 5 min refresher on any topic.

Scrum - A Pocket Guide - 3rd edition: A Smart Travel Companion (Best practice)

Zombie Scrum Survival Guide (Verwijs, Schartau, Overeem)

In PSM 3, there were questions about zombie scrum (aka mechanical scrum) — this book will help you detect and fix “zombie scrum”, and answer many questions that might come up in the PSM 3 exam.

Zombie Scrum Survival Guide (The Professional Scrum Series)

Scrum Anti-Patterns (Stefan Wolpers)

This book was still being written as I took PSM 3, but I have been following Stefan’s work for a while and expect this book will be excellent. It’s available to buy now, so pick up a copy and read it.

The Scrum Anti-Patterns Guide: Challenges Every Scrum Team Faces and How to Overcome Them (The Professional Scrum Series)

Cynefin (Dave Snowden)

This book will help you understand why Scrum can help navigate working in a complex environment.

Cynefin - Weaving Sense-Making into the Fabric of Our World

Agile Leadership Toolkit (Peter Koning)

Reading this will help you understand how to create a culture of continuous improvement and support self-managing teams.

Agile Leadership Toolkit: Learning to Thrive with Self-Managing Teams (The Professional Scrum Series)

The Nexus Framework (Bittner, Kong, West)

There are many different ways to scale Scrum, you need to know at least one of them when studying for PSM 3. I chose Nexus because it’s also part of Scrum.org and that made a lot of sense. This book will help explain Nexus for you, it’s a tough read with lots of useful information.

Nexus Framework for Scaling Scrum, The: Continuously Delivering an Integrated Product with Multiple Scrum Teams (The Professional Scrum Series)

The Professional Scrum Team (Götz, Schirmer, Bittner)

This book contains everything you would want to know about becoming a professional Scrum team, a team that delivers value and enjoys doing it (not mechanical or zombie Scrum 🧟‍♀️).

Professional Scrum Team, The (The Professional Scrum Series)

The People’s Scrum (Tobias Mayer)

As a change agent, I like to build up a resistance of people to help make things happen. This book can help you with “stealth scrum” — when the organisational resistance is high. A great book to read and help you on your journey.

The People's Scrum: Agile Ideas for Revolutionary Transformation

Agile Conversations (Squirrel, Fredrick)

This book will help you understand how to have conversations in an effective way, that knowledge will help you answer questions about how you might approach a problem in PSM 3.

Agile Conversations: Transform Your Conversations, Transform Your Culture

Fixing Your Scrum (Ripley, Miller)

A great book for understanding some of Scrum’s anti-patterns and how to deal with them.

Fixing Your Scrum: Practical Solutions to Common Scrum Problems

Mastering Professional Scrum (Ockerman, Reindl)

A must read.

Mastering Professional Scrum: A Practitioners Guide to Overcoming Challenges and Maximizing the Benefits of Agility (The Professional Scrum Series)

The Professional Agile Leader (Eringa, Bittner, Bonnema)

A book to help you work as a Scrum Master at an organisational level.

Professional Agile Leader, The: Growing Mature Agile Teams and Organizations: The Leader's Journey Toward Growing Mature Agile Teams and Organizations (The Professional Scrum Series)

The Professional Product Owner (McGreal, Jocham)

This will help you understand the perspective of a Product Owner; one of the three Scrum accountabilities you need a deep understanding of for PSM 3.

Professional Product Owner, The: Leveraging Scrum as a Competitive Advantage (The Professional Scrum Series)

Scrum Mastery (Geoff Watts)

A great Scrum Master reads this book… (You’ll get it when you’ve read it). I actually read this twice, once a long time ago and more recently after Geoff updated it in 2021.

Scrum Mastery (Geoff Watts' Agile Mastery Series)

The Surprising Power of Liberating Structures (Lipmanowicz, McCandless)

This book will help enhance your facilitation skills and answer any questions about how you might facilitate a scenario in the PSM 3 exam.

The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation (Black and White Version)

Applying Scrum with Kanban: A Pointless Book! (Andy Hiles)

If you are new to Kanban, this book is excellent. It makes it easy to understand how Scrum and Kanban can be used together to deliver value and optimise team effectiveness.

Applying Scrum with Kanban: A Pointless Book!

Agile Retrospectives — Making Good Teams Great (Derby, Larsen, Schwaber)

A great book on how to design and facilitate retrospectives.

Agile Retrospectives - Making Good Teams Great

Note — This book has recently been updated.

Agile Retrospectives, Second Edition: A Practical Guide for Catalyzing Team Learning and Improvement

Agile Product Management with Scrum (Roman Pichler)

Go a little deeper into the Product Owner’s interactions with the Scrum team with this book.

Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn))

Coaching Agile Teams (Lyssa Adkins)

This will help you understand the mindset of coaching teams; sometimes you need to step back, sometimes take control. The book contains great examples of activities you can facilitate to help your team work better together. One of my favourites is Journey Lines; great for helping people get to know each other.

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

Sprint Journal (Stephen Waring)

That’s right, I wrote my own book and published it on Amazon. It’s actually a journal that you can use everyday with the Scrum teams you work with.

It helps you put theory into practice.

As part of my PSM 3 study, I realised that I had a whole checklist of things that I’d unconsciously been doing for a very long time. So I put some structure around it and created a series of Sprint Journals (depending on Sprint length) to help other Scrum Masters on their journey.

These books will help you look out for the right things and the anti-patterns in each of the Scrum events in your daily work. There is a different journal for each common Sprint length.

• Sprint Journal - 2 Week
• Sprint Journal - 3 Week
• Sprint Journal - 1 Week
• Sprint Journal - 1 Month

Blogs, Podcasts and YouTube

I didn’t just read books…

Blogs

There is an excellent series of blog posts from Steven Denier here that links all the Scrum concepts together, a must-read for anyone studying for PSM 3.

Scrum.org Blog

Podcasts

I’d listen to the Agile Mentors Podcast to keep my thinking in the world of Scrum whilst I was commuting or out for a walk. It covers a wide range of topics.

Agile Mentors Podcast from Mountain Goat Software

The Troubleshooting Agile Podcast was also great for diving into specific topics.

Troubleshooting Agile Podcast - Conversational Transformation

YouTube Videos

This is by far one of the best Scrum learning resources out there. If you only do one thing from this entire article, watch these videos.

Agile for Humans

There are a number of playlists you need to work through and take notes from, but Deeper Into Scrum was of the very best for me. It’s a members-only playlist and requires a subscription, but it’s cheap and worth every penny.

Whenever you have a spare 10 minutes, watch one of the nearly 500 Your Daily Scrum videos to gain expert insight into a variety of topics surrounding Scrum, including situations that might arise in a PSM 3 exam.

Practice Exams / Questions

I bought these practice questions from thescrummaster.co.uk and started to work through them each week.

Free Scrum Master PSM 3 Questions

Get started for free with this selection of PSM 3 “like” questions.

Free Scrum Master III (PSM III) Practice Questions - TheScrumMaster.co.uk

Ultimate Scrum Master PSM 3 Questions

You can pay a very small fee for a new set of questions and answers. These helped me start to understand what the actual exam would be like, and forced me to start answering within a time box. The answers provided helped guide me to the answering the right way.

Ultimate Scrum Master III (PSM III) Practice Questions -

Ultimate Scrum Master PSM 3 Assessment

And finally, you can take a small PSM 3 “like” exam, marked by a real person, with real feedback, for a small fee. I did this to boost my confidence before taking the final PSM 3 exam. The feedback I received helped me to pass on my first attempt.

Ultimate Scrum Master III (PSM III) Practice Assessment -

Next steps for you

Everyone’s journey is different.

As you embark on your journey, remember that it’s not just about passing the PSM 3 exam; it’s embracing continuous learning and growth as a Scrum Master. Whether you pass or fail the exam, you will improve as your learn more and more.

Try and find a study buddy, or join a learning cohort to boost collaborative learning and have amazing discussions about Scrum that really open your mind to what’s possible.

If you want to chat to me about PSM 3, please connect with me on LinkedIn and drop me a message — I’d be happy to help.

My Journey

From immersing myself in books, engaging with podcasts, blogs, and YouTube channels and having rich discussions with other Scrum Masters and Scrum trainers, every resource played a vital role in expanding my understanding of Scrum. Additionally, practice exams and questions validated my learning and provided invaluable insights into what to expect and fine-tune my approach.

I’ve worked as a Scrum master since 2007, so I’ve made lots of mistakes and gained lots of experience along the way. Here are the other exams I’ve taken and passed. Each of them required lots of studying, attending courses, reading books, trying things in real life etc...

A quick summary of the certifications I had completed before attempting PSM 3:

• PSM 1 and PSM 2 😉
• PSPO 1 and PSPO 2 to gain a deeper understanding of the Product Owner’s perspective
• PSD to gain a deeper understanding of the Developers perspective
• SPS to gain a deeper understanding of how and when to scale Scrum
• PAL 1 to gain a deeper understanding of agile leadership and how to work at an organisational level
• PAL-EBM to gain a deeper understanding of value and how to measure it
• PSK 1 to gain a deeper understanding of how Scrum and Kanban can work together to deliver exceptional performance from your team(s)

A quick summary of my experience

• I have over 20 years experience creating software as a developer, working directly with customers and stakeholders, senior management and leadership, with about 15 years of that experience directly as a Scrum Master with multiple teams across multiple organisations.
• I’ve read a lot of books surrounding the topics of Agile, Scrum, project management, software development, leadership and anything relating to teams and how they get stuff done.
• I joined a PSM 3 cohort with other PSM 2 certified Scrum Masters for a 6 month programme where we went deep into Scrum, every week. It was important that these people had significant experience with Scrum so that we could have rich conversations that helped you question everything you thought you knew.
• I’ve taught, coached and mentored multiple Scrum Masters in my day job.
• I’ve watched a lot of videos on YouTube, subscribed to multiple podcasts…. I’ve basically lived and breathed Scrum for the entire period.
• I was prepared to fail the exam, when I failed, I was going to inspect at where I was weak, and adapt (but I passed).

It’s not the end of my journey, I’m still reading, still learning, still growing.

I hope you found this useful, if you have any questions, I’d be more than happy to help. Please reach out.

How to prepare for PSM 3 was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

The same two people are constantly sniping at each other, arguing over every point, taking any opportunity to get one up on the other. It’s getting worse. It’s starting to affect the rest of the team, meetings are becoming battle grounds, it’s becoming uncomfortable for everyone — so what can you do to make things better?

✋ This cannot continue

It’s quite clear that this cannot continue, so here are a few things you can do as a Scrum Master to help get this team back on track:

• Teach the team about healthy and unhealthy levels of conflict. Conflict about how the work is done can be healthy, but when it becomes personal, it’s unhealthy, it can sap energy from the team and reduce its effectiveness in delivering value.
• Ensuring the team has a psychologically safe environment to discuss any issues in Sprint Retrospective can help nip conflict in the bud. This means a private area for just the team, where everyone feels able to voice their concerns in an open and constructive way. If it starts to get out of hand, use your facilitation skills to get things back on track. Allow everyone’s voice to be heard and guide the team to a collective, effective resolution.
• Review and enhance existing team working agreements that address the source of the conflict. Having the team do this collaboratively will enable self-management and continuous improvement. I find something like 6 Thinking Hats can really help the team to think together here — focussing on the problem, not the person, whilst allowing emotions to be felt without repercussions.
• Use another Sprint Retrospective event to teach/reinforce the 5 Scrum values of Courage, Commitment, Focus, Openness and Respect to the team. Show them how they can live the values in their context and why it’s important to do so.
• Live the Scrum values yourself — show them how it’s done, and continuously reinforce them as and when the team demonstrates using them in their daily work e.g. When someone has the courage to say they are struggling with something in the Daily Scrum, let everyone know that it was good they had the courage to say that. In Sprint Planning, there will often be moments where the team need to practice active listening, remind them that it was good that they respected the speakers viewpoint whilst they kept quiet and took everything in.
• Offer facilitation services to those in conflict. It’s not your role to resolve the conflict yourself, but you can help each person to see the other as a human being. Help them talk to each other to come to a resolution. Methods such as Empathy Mapping or Journey Lines can help build connections between people.

Recording when Scrum Values are used

I’ve written a Sprint Journal that helps you track when the Scrum Values are being used throughout each Sprint:

Sprint Journal - 2 Week

Take this empirical data you collected to Sprint Retrospective and inspect it as a team and decide what to do next.

The crucial role of Scrum Masters in navigating conflict

Scrum Masters possess the skills to transform conflict into collaboration, they help reduce the chances of unproductive conflict by constantly promoting a healthy work environment where the 5 Scrum values are lived daily.

It’s not the role of the Scrum Master to resolve the conflict themselves, but they are accountable for the effectiveness of the team. When an unhealthy conflict starts within the team, one that the team cannot resolve themselves, then they may need to act to de-escalate this to a healthy level of productive conflict as soon as possible.

Proactive monitoring of team dynamics allows Scrum Masters to detect early signs of conflict, they are someone who understands each person and their daily work can help the team avoid falling into the conflict trap, making it a nicer place to work.

Summary

In the fast-paced world of Agile development, conflict within teams is inevitable, it can derail progress and halt productivity. Productive conflict is good, but it can quickly become personal and unproductive if you are not careful.

A skilled Scrum Master can help make sure this does not happen by helping the team live the 5 Scrum values of Courage, Commitment, Focus, Openness and Respect every single day. This helps create an environment where trust is built, and information can be made transparent so that better inspections and adaptations can be made.

Well facilitated Sprint events, such as Sprint Retrospectives, can help the team work together and decide what to do next. A good set of collaboratively built and maintained team working agreements will help codify how people work together and help reduce the number of misunderstandings leading to conflict in the first place.

Doing the above doesn’t guarantee that unproductive conflict will arise, people have incredibly complex and changing lives, but it should help to go a long way to making sure conflict is infrequent and dealt with quickly.

Ultimately, the individuals affected need to resolve the conflict between themselves. The Scrum Master can provide services to help with that as requested.

A Scrum Master who helps the team learn how to deal with conflict boosts self-management and motivation of that team.

If all else fails, the team should decide on whether the team composition should change to ensure their continued success. This really is a last resort though.

Conflict to Collaboration was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Death Loop of Delivery is a reinforcing cycle that can take hold when delivery expectations, uncertainty and trust are handled badly. It’s very common.

Does this sound familiar?

Missed expectations lead to demands for greater certainty and control.

Teams respond with larger estimates, more reporting and defensive behaviours.

Pressure increases, quality and motivation suffer, autonomy decreases — and delivery becomes harder rather than more predictable.

The real danger is that many of the actions that make the loop worse look perfectly reasonable at the time.

You work with teams. Things have generally been very good, you’ve delivered real value, people are happy, you are getting things done.

Your customers are happy, their product is getting better and better.

Your stakeholders are happy.

As a result, more and more work is coming in, more features and improvements are being requested. You’ve now got a larger budget to hire more people, and more teams to deliver even more value.

As long as you keep delivering, everyone is happy…

But if you’re not careful, you can enter the death loop of delivery.

Where does it all go wrong?

It often starts with the dreaded committed delivery date — decided by management without consulting the team. Cue the panic as unrealistic deadlines loom, and the team scrambles to keep up.

When you constantly deliver, trust can be very high, but trust between teams and stakeholders often starts to crumble when teams start to not deliver everything promised by a committed delivery date.

Trust

To rely upon or place confidence in someone or something

- dictionary.com

Working in a world of VUCA (volatility, uncertainty, complexity and ambiguity) means that there are plenty of opportunities for missed delivery dates to happen.

The problem with the committed delivery date

Layers of middle management, product owners, project managers, tech leads or team managers get together and decide when a piece of work will be finished.

The team is never consulted.

These people have the best intentions of course. They might base their plans on high level estimates provided by the team itself, usually under pressure to do so quickly, and usually when they know the absolute least amount of information about the work they are about to undertake.

Even if the team did have the time to conjure up what looks like a decent plan, it’s often ends up being estimated as way more work than management are willing to accept. It still needs to be done quicker.

In reality though, even if the team is consulted, it’s too late. The committed date can’t be changed at this point. Any attempt to delay the date will have people asking why it’s going to take much longer than the original “estimate” (that the team didn’t have any say in).

What we have here is a committed delivery date, decided and enforced by the authority of stakeholders, imposed on middle management and thus the teams themselves.

What happens next is not pretty

The team probably know the project isn’t possible before they even start. They are already under pressure.

They try to reduce scope with the stakeholders, only for that exact same scope to be added back later in the project (with stakeholders conveniently forgetting they said it was ok to remove in the first place).

Inevitably, projects started like this are doomed to failure, and when they are officially “late”, the stakeholders and the teams arrange a post-mortem meeting to discuss how to not let it happen ever again.

Accelerating the descent

In order to not let stakeholders down in the future and protect themselves from future blame and retribution, the teams start to pad their estimates. What was 5 points is now 8, just in case.

With higher estimates, forecasted delivery dates get extended and stakeholders start wondering why everything is now taking much longer these days.

They start questioning the estimates given by the team, you might hear things like “that’s not an 8”. Estimates are revised downwards after working with “tech leads” to make them more “realistic”.

The teams resist this, but it’s futile. Even if the estimates stay the same, your product owner or project manager is forced to update the roadmap to reflect “reality”.

The result, the team is late to deliver before they even start.

When product backlog items (PBIs) take longer than initial estimates, usually due to the nature of working in a complex and inherently unknown working environment, management start asking why the team is going slowly.

“Why is velocity dropping? We used to do 40 points a Sprint, now we’re only doing 30?”

The team starts to cut corners, reducing quality to hit a date and artificially boost velocity. This increases the likelihood of bugs and rework, further reducing the time they have to build a quality product in the future.

It’s a vicious spiral.

This team starts to become hugely demotivated. They no longer have the time to do a proper job, and everything is starting to suffer.

They’ve become a feature factory.

Protect yourself

Now everyone starts to protect themselves. The environment is becoming more and more toxic.

People start to document everything, every decision made, every change to every estimate as proof of what happened. They do not want to be blamed for the inevitable failure of the project.

As things get worse, management assign a “project manager” or “delivery support” to bring everything back on track. Applying more process, control and restrictions. Further reducing the team’s autonomy, motivation and effectiveness in this death loop of delivery.

This will continue getting worse and worse until something changes.

People will leave and be replaced. The team becomes less and less motivated, less and less effective, the value delivered by this organisation will diminish until a competitor starts to outperform it or something else changes.

Deliver something, anything.

There’s no quick win here, you have a lot of work ahead of you.

You re-build trust by delivering something, anything. But it has to be good quality, it has to work, it has to be valuable, it has to be a step in the right direction.

• You need to get better at forecasting.
• You need to work at a sustainable pace.

Do both things and more accurate forecasting will lead to work being delivered more frequently on time.

More predictable delivery = happier stakeholders = more trust.

More trust leads to more transparency, inspection and better adaptations can be made for better outcomes in the future.

Step 1: Nail the basics

Get the basics of working with Scrum right:

• Create a good Definition of Done and use it.
• Define initial team working agreements.
• Define a clear product vision and product goal. Make sure everyone knows what they are and what they mean.
• Learn how to write suitable product backlog items for your context.
• Spend some time building and refining a good product backlog and make sure everyone understands it.
• Start tracking cycle time (when you first start something to when it’s “done”).
• Start tracking work item age (how long an item has been in progress up to today).
• Learn how to perform probabilistic forecasting e.g. Monte Carlo.
• Run effective Sprint Planning sessions.
• Run effective Daily Scrums.
• Run effective Sprint Reviews.
• Run effective Sprint Retrospectives.
• Run effective Sprints.

I’ve written a Sprint Journal that can help you nail the basics of Scrum:

Sprint Journal - 2 Week

Step 2: Learn how to split work up into small, manageable chunks, visualise your metrics

• Now that you can write good PBIs, it’s easier to split them. Learn how to split up PBIs into “right sized” chunks.
• Now that you are tracking cycle time, learn how to calculate your Service Level Expectation (SLE).
• Visualise your cycle time metrics by creating cycle time scatterplots. Use them in your Sprint Retrospectives 😉.

Step 3: Use your measurements and adjust how you split

• By now you should have a good understanding of work item age. The teams should be setting their own team working agreements for work item age i.e. what do we do as a team when a PBI reaches 80% of it’s SLE?
• The team should be discussing work item age in every Daily Scrum.
• You’ve split lots of good PBIs by now, the team should have a good idea about what “right sized” means for them. The team should set their own working agreements for splitting items under the SLE value (aka right sized).

Now we’re focussing on getting things “done”.

Step 4: Stop wasting time estimating — use empirical data instead

• Ditch story points — you don’t need them now. You’re wasting time guessing how long things might take with the least amount of knowledge, then using those guesses to predict when something might be done. Instead — use your cycle time data and observed metrics to create a probabilistic forecast instead. Get away from opinions and move to facts. No-one can “change your estimates” ever again.

Step 5: Continuously improve everything

• Regularly review and update team working agreements to improve the quality and effectiveness of this team.
• Limit work in progress (WIP) to improve flow.
• Review and update your workflow steps — are they the most effective way of getting to done? Use empirical data and run experiments.
• Review and upgrade tooling to support your work.
• Automate everything.
• … try anything else your team feel can improve the way it works together. Prove it with data. Inspect and adapt.

Summary

Unrealistic deadlines from the start, leads to teams that scramble to keep up. As the pressure mounts, estimates get padded, deadlines get pushed, and quality takes a backseat. It’s a vicious cycle of missed targets and disappointed stakeholders, leading to demotivated teams and a toxic work environment.

Trust starts to break down when you stop delivering. This leads to more control from management, less autonomy and reduced motivation.

Demotivated teams are less effective, and less and less value is delivered over time.

It’s a death loop of delivery.

Following the above steps will help you to start rebuilding trust, improve performance and focus on delivering quality work with better forecasts.

Splitting tasks into manageable chunks, using empirical data instead of story point estimates and continuously improving everything will lead to a more effective and motivated team that delivers.

Delivering can help teams can break free from the cycle, regain trust, and achieve better outcomes.

Of course, there are many, many ways of entering and escaping this loop, this is my recent experience and the steps I used to help repair the damage.

Do you see anything like this happening where you work? It’s not too late to fix things. Just start delivering again and rebuild that trust.

Are you caught in the Death Loop of Delivery?

It isn’t always obvious when the loop is taking hold. Behaviours like asking for better estimates, increased reporting or adding more oversight can seem perfectly reasonable in isolation.

I’ve created a free Death Loop of Delivery Diagnostic tool to help you spot where these behaviours may be showing up in your organisation.

It takes just a few minutes and gives you a personalised score across six areas, helping you identify where the strongest signals are and where to look more closely.

Take the free Death Loop of Delivery Diagnostic
https://steve-k4xgwyk7.scoreapp.com/

Escaping the dreaded death loop of delivery was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here are 8 highlights to help you on your own agile journey in 2024.

Unlocking Business Agility with Evidence-Based Management

If you haven’t come across Evidence Based Management (EBM) yet, it can help you move from an output oriented culture, to an outcome based one by helping you measure value across 4 Key Value Areas. This book will help you understand and apply EBM in your own unique context.

Unlocking Business Agility with Evidence-Based Management: Satisfy Customers and Improve Organizational Effectiveness (The Professional Scrum Series)

Driving Value with Sprint Goals

Do you work in a team where your Sprint Goals either don’t exist, don’t relate to the longer term product goal, are based on outputs rather than outcomes, or just a list of tickets to complete?

This book will help you create better goals and use them appropriately to help deliver real value, every sprint.

Driving Value with Sprint Goals: Humble Plans, Exceptional Results (Addison-Wesley Signature Series (Cohn))

Sprint Journal — 2 Week

Lots of things happen throughout every Sprint, this handy journal gives you a structured way to store important data about what happened.

This isn’t something you read, it’s something you fill in.

It covers all the core Scrum events:

• 📆 Sprint Planning
• 🔄 Daily Scrum
• 📈 Sprint Review
• 🧐 Sprint Retrospective

Each has a reminder of its purpose, a set of checklist items of what to look out for, attendance, how the scrum values are being used, goals, impediments, anti-patterns and anything else useful.

There is space for your own notes as well, unique to your own context.

Take these notes to Sprint Retrospectives, be transparent, and collaboratively inspect and adapt to enhance the quality and effectiveness of your team.

Sprint Journal - 2 Week

Evidence Guided

Itamar Gilad presents an actionable model called GIST (Goals, Ideas, Steps, and Tasks) — to help you create high-impact products in your organisation.

Evidence-Guided: Creating High Impact Products in the Face of Uncertainty

Management 3.0

I was first introduced to Management 3.0 when I learned about Delegation Poker — then I went deeper into the topic by reading this excellent book, you should too:

Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))

Practical Product Management for Product Owners

This book was recommended to me as part of a PSPO-A course. If you are a Product Owner looking to hone their skills, or a curious Scrum Master trying to help support a Product Owner, this book can help:

Practical Product Management for Product Owners: Creating Winning Products with the Professional Product Owner Stances (The Professional Scrum Series)

Applying Scrum with Kanban

If you are working in a Scrum team and want to understand how work is flowing through your process, start with Kanban. This is a great book written in a friendly way to introduce you to the flow metrics that can help your team become more effective, efficient and predictable.

Applying Scrum with Kanban: A Pointless Book!

Delivery Management

The organisation I worked with decided they wanted to rename all Scrum Masters to “Delivery Managers” — so I read this book to better understand what that actually meant.

I’d recommend it to any Scrum Master to help them get out of the “Scrum bubble”. It’s also an excellent book for anyone who actually hires Delivery Managers — so they understand what they are hiring.

Johnny puts it brilliantly himself:

If the teams you work with aren’t quite hitting their stride, and delivering value still feels like a distant aspiration, then Delivery Management can help.

Well worth a read if you’re a Scrum Master who currently thinks Delivery Management is the same as Project Management.

Delivery Management: Enabling Teams to Deliver Value

Summary

So there you have it, 8 more books to add to you collection for 2024.

They are the sort of books that make you think different, experiment with new approaches and help the teams you work with to deliver real value.

Enjoy!

8 Agile books to read in 2024 was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever worked in an organisation where there is a disturbing lack of Scrum Masters?

I have.

Many organisations either don’t understand or don’t see the value in the Scrum Master. They often combine it with other accountabilities or just try to live without it.

This article will help you understand the value a Scrum Master brings to your organisation and why if you are using Scrum, it’s essential someone fulfils the Scrum Master accountability in each of your scrum teams.

They amplify the effectiveness of your teams, boosting your return on investment.

The Scrum Master is your team’s leader

Scrum Masters are true leaders who serve the Scrum Team and the larger organisation.

Scrum Masters are true leaders who serve the Scrum Team and the larger organisation.

Scrum Guide 2020

With a leader in place, the team can make decisions more easily. With a servant leader in place, you know those decisions are for the team’s advantage and aligned to the organisation’s goals.

That’s right, a Scrum Master leads by serving the team’s best interests rather than managing them with authority.

Not only that, they lead others throughout the organisation in their use of Scrum and other agile practices.

Your Scrum Master is accountable for the effectiveness of the team, it’s use of Scrum and it’s continuous improvement. In order to do this effectively, they lead the team by understanding and serving their needs to help them grow.

They help improve the team’s quality (via the Definition of Done) and effectiveness (it’s processes to get to done). This is usually via the Sprint Retrospective, but your Scrum Master will be observing your team’s interactions continuously; teaching, guiding and mentoring whenever it makes sense to do so.

They help the product owner with product backlog management and their interactions with stakeholders.

They help the organisation understand what Scrum is, and how it can be used as a competitive advantage to deliver value early and often.

When a Scrum Master leads your team, it becomes more effective at making decisions that are in it’s best interests — boosting your return on investment.

Scrum Masters truly understand and effectively applying Scrum practices

They don’t just read the Scrum guide and follow the steps.

They understand it deeply.

Topics such as self-management, cross-functionality, empiricism, living the scrum values, psychological safety, trust, facilitation, coaching, teaching, mentoring, impediment removal, acting as a change agent and many, many more — whatever the team needs, your Scrum Master is learning about it.

Scrum Masters understand the links between all these things.

They are continuously inspecting and adapting their own effectiveness, improving their own understanding of what Scrum is and how it should be used to maximise it’s effectiveness in your own unique context — researching new practices that can help the teams they serve.

They have a growth mindset, watching hours and hours of YouTube content, listening to podcasts, reading books and blog articles, going to meetups and conferences, preparing and studying for certifications to help broaden their knowledge, validating their learning and applying it to the teams and organisation they serve.

A Scrum Master continuously improves themselves and the environment they work in. As effectiveness improves, you start to deliver better quality solutions, more effectively — boosting your return on investment.

Scrum Masters resolve impediments quickly and efficiently

A good Scrum Master is working with their team to identify and resolve impediments to progress; raising the transparency of any problems so that the teams can make the right adaptations for the future as soon as possible — minimising the risk of delay.

Impediment identification and removal is a skill.

Scrum Masters have this skill, but not only are they helping remove impediments as required, they are also teaching the team how to do this themselves. Their goal is to build self-managing teams that don’t need them as much anymore.

A self-managing team is going to get problems out of their way quicker, delivering value and achieving business goals sooner — boosting your return on investment.

Scrum Masters effectively facilitate

For sure, anyone can hold a daily scrum, or a sprint retrospective — but are they effective, or are people just going through the motions, turning up and nothing really happens?

Each Scrum event is a key inspect and adapt moment.

Not only does your Scrum Master know what to inspect, and what to adapt, they also know the most effective ways to facilitate these events in your organisation’s own unique context; it’s unique combination of tools, people, personalities, locations etc…

Each event you have costs time and money. A Scrum Master maximises the effectiveness of every Scrum event with effective facilitation and fulfilling the purpose of each event — boosting your return on investment.

Scrum Masters enable continuous improvement

Continuous improvement is the heart of everything a Scrum Master does.

This kind of enthusiasm is infectious.

They will infect your teams, the people your teams speak to, the whole organisation. Everyone will get better, continuously.

As your team’s continuously improves everything they do, they inevitably deliver value quicker, your customers are happier and you achieve your business outcomes sooner — boosting your return on your investment.

Scrum Masters reduce damaging conflict and increasing productive conflict

Scrum Masters see the iceberg before it’s too late, they can help prevent conflict and can help resolve conflict in a way where everyone wins.

They help build a work environment where people can disagree and commit and resolve their issues with each other in a productive way before they escalate to all out war.

A Scrum Master is skilled in conflict management, and can help coach the team to define working agreements that help prevent conflict in the first place. To help foster an environment where damaging conflict rarely occurs, and productive conflict thrives.

Complex problems require diverse thinking and sometimes conflicting opinions to solve. A good Scrum Master will help your team navigate conflict, teach them the different types and provide facilitation services as required.

Preventing damaging conflict and resolving conflict quickly, enables teams to get back to doing what they know best, delivering valuable solutions to our customers and driving business outcomes — boosting your return on investment.

Scrum Masters hold developers and product owners to account

Your product owners are focussed on maximising the value delivered by a scrum team, your developers (incl. designers/testers etc…) are creating solutions to problems. But which separate person is holding them to account?

Having a Scrum Master in your team helps your product owners and developers fulfil their own accountabilities by being held to account by someone else.

There is a healthy conflict and tension between all accountabilities.

When people feel accountable to someone else, they are more likely to deliver sooner — boosting your return on investment.

Scrum Masters prove it all with metrics

A good Scrum Master does all the above, but they also prove their effectiveness with objective data.

They know what metrics are useful and what metrics can be damaging.

They’ve learnt how to do this with tools such as Evidence Based Management.

They use objective data to see what works and what doesn’t, they prove that their methods are working, and inspect and adapt their approach with the team over time.

Working in an empirical way leads to changes that are proved to be working, leading to a quicker delivery of value to customers, improved business outcomes — boosting your return on investment.

Summary

I hope you can now see the value in a Scrum Master . Investing in a great Scrum Master will pay for their salary many times over.

We live in a complex world and Scrum Masters can help your teams and your organisation navigate that complexity using empiricism.

Can you afford to not have a Scrum Master in your team?

Without a Scrum Master, many of the things above will not happen, or will not happen with the same diligence and competence. This is mostly due to a lack of time, but also due to a lack of experience and education.

Without a Scrum Master, you could watch your use of Scrum slowly fail, losing your competitive advantage and reverting back to old ways of working; ways of working not suitable for a complex working environment.

Making sure you have someone with the accountability of a Scrum Master in your team could be one of the best decisions you make. They will help your amplify the effectiveness of your teams in delivering real value to your customers and achieving your business outcomes sooner.

Scrum Masters are team effectiveness amplifiers was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

The 5 scrum events defined in the scrum guide 2020 are:

1. Sprint Planning
2. Daily Scrum
3. Sprint Retrospective
4. Sprint Review
5. and the container for all of these, the Sprint itself

…but what if you renamed all of these events, do you think your team would be more effective?

Let’s explore…

Product slice planning

Product slice planning replaces sprint planning.

The product slice is our next step towards our longer-term product goal.

The objective of product slice planning:

• collaboratively define a product slice goal
• decide what work will be undertaken to achieve that goal
• decide how that work might be completed for the next product slice that we can potentially release to our users.

We need to consider how each item selected contributes to the product slice goal, whether we have the capacity to do it and how we plan to undertake that work.

At the end of product slice planning, we’ll come away with a collaboratively built product slice goal, a product slice backlog and a plan for what to do next.

By replacing sprint planning with product slice planning we change the focus of the event to be “what can we potentially release next” — and this might lead your team to be more effective.

Collaborative daily planning

Collaborative daily planning replaces the daily scrum.

The focus of collaborative daily planning is to inspect progress towards the product slice goal. We’ll then make the required adaptations to the product slice backlog to correct any variances detected towards achieving our product slice goal.

We’re not reporting progress here, no status updates, we’re getting together and planning, collaboratively.

A simple change in the name might alter the focus of this event to be planning focused, rather than status update oriented, and thus improve the effectiveness of your team

Continuous team improvement

The continuous team improvement event is where we all get together and look at how we can improve the effectiveness of the team and the quality of the work it completes.

We do this by inspecting how completing the previous product slice goal went, and deciding what adaptations we need to make for the future.

These adaptations might include:

• Reviewing our definition of done, to ensure the quality of our future product slices is always improving
• Reviewing our ways of working, to ensure we are collaborating effectively
• Reviewing the tools we use and how we use them
• Reviewing what skills we need to achieve our future product slice goals, and identifying new skills to learn or acquire to ensure we’re not impeded in the future.

By changing the event name to continuous team improvement, we change the focus of the event to have a clear outcome, we’re here to improve. How are we going to do that?

Product Review

Product review replaces sprint review.

It’s where the team and its stakeholders get together to look at the current state of the product and how the product is doing in its market.

We’ll look at the latest product slice and try to get feedback on whether we are headed in the right direction to hit our current product goal.

There will be discussions on how building the previous product slice went, including anything we didn’t complete and why that was the case.

And we’ll review the current value our product is delivering with stats, analytics, user insights and other useful data to see if the work we do is really making an impact towards our longer-term goals.

By the end of the product review, with the feedback we’ve collected, we’ll add items to the product backlog to ensure we stay on the right track, these adaptations will help to ensure we are maximising the value our product delivers in the future for our customers and stakeholders.

By changing the name to product review, we change the focus of the event to be all about the product, and not just demos of work to prove we’ve been busy.

The product slice

The product slice is the new name for a sprint.

A product slice implies that we’re working on a smaller part of a bigger thing, that we are working iteratively, slice by slice, to achieve a bigger goal.

Have you tried sprinting everywhere? It’s hard work. The word sprint can imply an unsustainable pace; contrary to one of the principles of the agile manifesto:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

https://agilemanifesto.org/principles.html

By renaming the sprint to product slice, we change the focus to be less about burning ourselves out, and more about building slices of a larger goal, at a constant pace, indefinitely.

Summary

I’m not suggesting you go out and rename all the scrum events in the organisation you work with. Far from it!

But by taking the names out of the equation and refreshing your understanding of their purpose with your team can be a useful exercise to help the teams you work with gain a deeper understanding of why the events exist in the first place, and thus, your team may become more effective in the future.

Who knows, maybe you prefer the new names and you’ll continue to use them forever.

If you are working in an organisation where scrum is frowned upon, then maybe use some of the names above to ease into the framework later in your journey.

I hope this article was food for thought and good luck with Scrum in the future!

What if you renamed all the scrum events? was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you first start out planning sprints, it can be difficult to know what to do, where to start. So here’s one simple method to set you on the right path.

All you need is a definition of done, a product backlog, a sprint goal and a team…

Let’s get started

The definition of done defines the expected quality level of your product so that someone can use it, your actual users, in their day to day life or work.

An increment of your product is born when a work item meets the definition of done.

So if you don’t have one yet, start by defining done first.

Sprint Planning

When you head to your next sprint planning event, you’ll be addressing the following topics:

• Topic One: Why is this Sprint valuable? Your Sprint Goal.
• Topic Two: What can be done this Sprint? The product backlog items you select to achieve the goal.
• Topic Three: How will the chosen work get done? The plan.

The definition of done is obviously super important then.

How do you know what can be done in a sprint if you haven’t defined what done actually means?

After you’ve decided why the sprint is valuable (the sprint goal), and what can be done in this sprint (selected the product backlog items subject to your definition of done), then the final topic to cover is how the work will be done.

To increase the transparency of the work of the sprint, we need to build a shared understanding of what work remains before we consider each product backlog item to be done. When all product backlog items are done, the sprint goal is achieved (or we adapt and create more work items to cover the gap as we learn more).

It’s important we increase the transparency of our sprint backlog so that we can inspect and adapt our progress towards the sprint goal in each of our daily scrum events.

During the sprint itself

During sprint planning we might only plan some of the sprint to help reduce waste in not planning the whole sprint upfront (in case we don’t make it that far).

The scrum team can therefore add details (the plan) for each product backlog item at any point during the sprint as required.

Use sub-tasks

Lots of teams I’ve worked with use sub-tasks of the individual product backlog items, augmented with other tasks to build their plan of the work of the sprint.

But what exactly should these sub-tasks and tasks contain?

One way of doing this is to use your definition of done as inspriation. Your definition of done should explicitly state what’s required to get to done, so creating sub-tasks from these things should be easy.

Worked example

A very basic definition of done

An increment is born when:

• Code is merged into the main branch
• Code is peer reviewed by 2 people
• All AT suite tests pass
• All API tests pass
• Our security scanning software shows no critical threats
• The product documentation has been updated with a video walkthrough explaining the new feature to users

How the work will get done

By creating a sub-task for every aspect of the definition of done, we’ve helped build a shared understanding, raised the transparency, of the work remaining to get to done and achieve our goals.

Summary

Scrum is based on empirical process control; we raise the transparency of certain artefacts; the product backlog, the sprint backlog and the increment, by building a shared understanding with the people that need to know.

The people that need to know are those that inspect the current state, and help make informed adaptations so that we can improve our chances of achieving our goals together.

Raising transparency is critical in ensuring the success of your product.

By adding sub-tasks to your sprint backlog that represent the work remaining to complete each work item, we are raising the transparency for the developers and the stakeholders.

By using the definition of done as inspiration, you are creating a shared understanding of the work remaining to get to done and create great products for our users.

A simple way to increase the transparency of your Sprint Backlog was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you work in a team that has everything it needs, you can be unstoppable! Creating a skills matrix is a great way to see what skills you already have and what you need to acquire in order to succeed together.

What is cross-functionality and why is it important?

When using the scrum framework to build products, your team is focussed on the long term product goal, and the shorter term step towards it, the sprint goal.

You are building an increment of your product that meets your definition of done so that you can provide something of value to your customers.

However, if you don’t have all the skills you require to meet that definition of done, then you are going to have a problem, an impediment.

A skills matrix can help you remove that impediment.

You can temporarily solve the problem by asking for help outside the team, but for long term success, you need to acquire the skills yourself. Being cross-functional means having all the skills you need to build an increment of your product.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

https://scrumguides.org/scrum-guide.html#scrum-team

What is a skills matrix?

A skills matrix helps to build a shared understanding of what skills the team current has, and what they seek to attain. This boosts transparency for the members of the scrum team and the organisation you work in.

Example

The following image shows an example of a small 4 person team and just 5 skills. Each colour represents a different level of confidence each person has with that skill, rated from beginner right through to catalyst.

• We can see that Person 1 has great confidence in the scrum framework (catalyst), but not so much confidence in anything else (Beginner/advanced beginner).
• Person 2 however specialises in react, and has a general understanding of everything else.
• Person 3 has more confidence in their python and automation testing skills
• …and Person 4 has the greatest confidence in Java, but also a bit of automation testing.

How do you get started

It’s super quick and easy to gather the data. You just need one person to create the matrix, ask each member of your team to fill it in asynchronously, then gather together to discuss the results.

A virtual whiteboard like miro is excellent for something like this, but you can just as easily use coloured cells in a spreadsheet to achieve the same result.

1. List all the people in your team on the left hand side (rows)
2. Create a column for every skill required to deliver an increment of your product (columns)
3. Ask each person to fill in the colour that represents their confidence in each skill
4. Discuss the results

What do I do next?

When you have this information, gather as a group and examine the data.

You could ask yourself the following questions:

1. Are there any skills listed that no-one has any confidence in? If so, you have an impediment; you have a skills gap. You need to resolve that by acquiring the skill(s) in whatever way you can. This skills matrix might help you to make a case to your organisation to hire an external trainer or to pay for a training course.
2. Are there any skills only one person has? This person is a single point of failure — if they are off sick, or go on holiday, you have an impediment. You should seek to collaborate and have others learn that skill as well
3. Does anyone want to learn a skill from someone else on the team? Now you know who has knowledge about each skill, you can help each other to succeed in their career. You can even pair up and learn together.

Summary

The simple practice of creating and maintaining a skills matrix is great for raising the transparency of the cross-functionality present in your team; having everything you need to build an increment of your product that meets your definition of done.

Armed with this information, you can inspect the results together and adapt your plans for the future; maximising the effectiveness of your team and your chances of successfully achieving your goals.

Make sure you review the skills matrix regularly; updating it with any progress you’ve made acquiring new skills, and also adding any new skills you realise you have to learn.

Sprint retrospectives are a great place to discuss your team’s skills matrix regularly.

A skills matrix is excellent for helping to create a culture of continuous learning and improvement, wherever you work.

You can also use this technique for things like a communities of practice; identifying how you can help each other to grow and learn new skills/tools/practices together and facilitating career development.

I hope you found this useful for you and your team, and good luck learning new things together!

Build a skills matrix for your team was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.

Work smarter, not harder

I’ve been doing a deep dive into Kanban recently and wanted to share some of the things I’ve learned and how to apply them in the Scrum teams you work with on a daily basis.

I’ve specifically been focussing on the 4 metrics of flow, and this time we’re looking at work in progress. Inspecting work in progress can help your team get more things done by creating an environment where there is a consistent flow of value through your process.

What is work in progress?

Any work items between a started point and a finished point are considered work in progress (WIP).

https://kanbanguides.org/

You choose the start and finish points suitable for your process and work items.

For the purposes of this article, we’ll assume work items have started when they get set to our “in progress” state, stay in progress whilst they are in the “review” state, and are finished when they get set to our “done” state:

What is a work in progress limit?

If work in progress is the count of work items started but not finished, then a work in progress limit is a practice for ensuring that only a certain number of items are in progress at any one time.

Teams set policies to ensure that no more work can be started until something else is completed. This creates a pull system. The team pulls more work when it has capacity to do so.

In the following example we can see 2 WIP limits in action:

• There is a WIP limit of 2 items on the “in progress” column
• There is an overall WIP limit of 4 items across both the “in progress” and “review” columns

We should not start item 6 until there is space in the “in progress” column; there are already 2 items in progress so we are already at the WIP limit.

However, even if item 4 or 5 moves on to the “review” stage (which has no WIP limit), we still should still not start item 6, as there is an overall WIP limit of 4 items across both the “in progress” and “review” columns.

We’ll need an item from the review column to be finished and get set to “done” stage before we have capacity to pick up item 6 at all.

Why would you want to track work in progress?

Tracking work in progress as a metric for your team will allow you to tune your process to be more effective, to deliver value to your customers more quickly:

• What happens to our throughput and cycle time when work in progress increases?
• What happens to our throughput and cycle time when work in progress decreases?
• What work in progress limits should we set for our own unique circumstances? What experiments should we run to prove this?

How do I get started?

WIP can be measured by simply adding up the number of items between your start and finish points at regular time intervals, typically every day.

Worked example

In the following example we have the same 4 step workflow; Backlog, In Progress, Review and Done, and we have 5 work items ready to start.

• The start (entry) point for calculating work in progress is the In Progress state
• The finish (exit) point for calculating work in progress is the Done state

Day 1: Work in Progress is calculated as 0. There are no work items in the “in progress” or “review” states…

Day 2: Two items are now in progress, so WIP = 2…

Day 3 — Item 1 is done and has left our process, item 2 is now being reviewed and item 3 is in progress. WIP = 2…

Day 4 — Item 1 and 2 are both done, item 3 is in review and item 4 is in progress. WIP = 2…

Day 5 — Items 1, 2, 3 and 4 are all done, leaving only item 5, which is in progress. WIP = 1…

WIP run chart

A WIP run chart is a line chart that shows us the daily work in progress over time. The following chart shows us the first 5 days of the example above, followed by a further 5 days of data:

It’s super easy to create this, you just need a spreadsheet with some charting capabilities and a simple table like this:

You can extract this data from your scrum board manually each day, or directly from a tool like JIRA by looking at the dates a specific item was in certain steps of your workflow.

Armed with this chart, you can take this as an input to your next sprint retrospective and find ways to help improve the effectiveness of your team.

Don’t feel constrained by a single sprint’s worth of data, you can plot this over a much larger timescale, multiple sprints.

Summary

If you’re a scrum master looking for ways to help improve the team’s effectiveness, then keeping an eye on work in progress and helping the team set policies to manage it via work in progress limits, should help you create a sustainable pace, indefinitely.

Inspecting work in progress allows you to work smarter, not harder.

It’s important the whole scrum team buys into this and actively manages it themselves. It’s not just for a scrum master to manage.

I like to keep this sort of thing simple. Show the observed data in your next retro, discuss what WIP limit experiments might be suitable for you and your team, run those experiments and see what happens next.

I think you’ll be surprised what such a simple practice can have on the effectiveness of your team.

Work in progress is just one of the 4 metrics of flow, I’ve written 3 other articles that’ll help you understand the rest:

• Read more about cycle time here
• Read more about throughput here
• …and read more about work item age here

If you’re interested in getting certified and learning more about kanban, I’ve written all about my journey here.

And if you want to learn about applying kanban practices with scrum, checkout Profession Scrum with Kanban material here at thescrummaster.co.uk

All the best on your journey with Scrum and Kanban!

Using Kanban practices within Scrum — Work In Progress was originally published in Agile Batman on Medium, where people are continuing the conversation by highlighting and responding to this story.