One of the best definitions of scrum I’ve seen stated that excellent scrum teams become a better version of themselves every sprint. I’ve fallen in love with this statement and have strived to find ways to help teams evolve since then.
Sadly, I’ve often observed something quite different than continuous improvement.
Many teams are overwhelmed because they receive unsustainable pressure from the business to deliver more than they possibly can. Unsurprisingly, their attention goes to maximizing output rather than improving their processes.
Without continuous improvement, scrum teams can’t go beyond ordinary results.
In this guide, I’ll share what I’ve learned about continuous improvement and some tips to help you implement this philosophy on your teams.
Continuous improvement is an interactive approach to uncover the root cause of problems and fix them so they never happen again.
For example, Toyota allows employees to stop the production line whenever a problem happens. They want to ensure that the root cause is fixed to avoid additional issues. Toyota focuses on continuous improvement, and the result is a high-quality product and a stronger team.
To cite one of the many great quotes on continuous improvement:
“To succeed in this world, you have to change all the time.” – Sam Walton
The classic approach to continuous improvement is known as plan-do-check-act (PDCA). This framework is designed to help you consciously identify problems, plan the solution, make it happen, and check the result.
You don’t need a specific moment for that. Every interaction is a chance to apply continuous improvement.
With scrum, many teams think the sprint retrospective is the right moment to apply continuous improvement. I’d say that’s one chance, but there are dozens of others.
Continuous improvement is more like a mindset than a process. It’s about having an itch to make things better.
Teams become better versions of themselves when they get annoyed by their comfort zone. They strive to evolve continually and deliver more valuable results. Yet, this attitude can be stressful when misapplied.
All teams have dysfunctions; I’ve yet to encounter a perfect team that has nothing to improve. There are always opportunities to evolve.
Focus is the key. Teams get overwhelmed when they try to solve every problem at once. To enable true transformation and sustainable, continuous improvement, you’re better off tackling one opportunity at a time.
I think questions can help teams identify opportunities. I like to create metrics and challenge whether the status quo is the best the team can do. Let me give you some examples:
What’s the average age of your product backlog items? Listen to signs; the older your items are, the more waterfall you become.
How long does it take for an idea to materialize into something valuable? The shorter, the better. Sound product companies relentlessly strive to reduce their cycle time, which empowers them to create value faster.
How often does your team release changes, and how long does it take? The longer it takes, the slower you can learn. State-of-art teams release changes several times a day.
How long do your team members take to conclude their tasks? Long WIP means you either have dependencies, unskilled professionals, or items that are too big.
Either way, you have plenty of opportunities to reduce WIP and deliver value sooner.
How much can your team produce per cycle? This metric can be tricky because it can mislead teams. You don’t want your teams to create more features just for the sake of it, but you do want them to deliver at a sustainable pace to enable you to learn from end users.
The metrics above are just examples to help you uncover opportunities for continuous improvement. You can define more according to your scenario.
“What gets measured gets improved.” – Peter Drucker
Alone, metrics aren’t enough. A common mistake is to create metrics and not talk about them.
It’s a good practice to look at metrics at least once a week and discuss them with your team. Here are some examples of questions I like to ask:
The more questions you ask, the more opportunities you create.
Who’s responsible for continuous improvement within scrum? If you treat it as a process, you may think it would fall to the scrum master. But if you ask me, continuous improvement is best treated as a mindset instead of a process.
All scrum team members have daily chances to apply continuous improvement to their activities. It’s about searching for opportunities to do something better.
The following advice applies to all scrum team members:
When scrum team members embrace these tenets, continuous improvement becomes natural.
Now, let me give you concrete examples for each team role:
Have an open mind to identify ways to strengthen collaboration with business people and customers. Be open to the new and curious about what other teams are doing that could help your team create value sooner.
Look beyond scrum. Strive to understand how the status quo impacts the teams’ results. Identify possibilities to transform the current collaboration into something that enables the team to create value sooner.
Don’t be afraid of conflicts; be fearful of mediocrity.
The goal isn’t to push more features every sprint, but to create something that delights end users and creates business value.
What could be done today to make them more valuable, scalable, and maintainable? What about sharing opportunities with team members and continuously agreeing on small improvements?
Scrum is a process framework that creates room for the right things to happen. From there, it’s up to you to discover how to benefit the most from it.
Many teams ignore continuous improvement because they are too busy feeding the feature factory. Another bad practice is to transform continuous improvement into a mechanical process.
Both scenarios lead to the same pointless results. When continuous improvement becomes your mindset, you have a chance to achieve greatness.
I dislike processes because most of them limit teams’ creativity. That’s why I never tire of challenging the why behind the how.
Without understanding why we do something, we cannot make it better. I’ve seen many teams evolve just by asking questions and acting upon them.
Contrary to what you may think, getting better as a team isn’t complex. It’s all about curiosity and action.
I’ll close with another one of my favorite quotes on continuous improvement:
“Do not be afraid of improving slowly. Be afraid of standing still.” – Leo Babauta
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Chaos engineering is the practice of deliberately introducing failures into a system to test its resilience and identify hidden weaknesses.
Arman Javaherian talks about the importance of setting aside time to help grow and mature product managers on his teams.
Enablement refers to the process of providing others with the means to do something that they otherwise weren’t able to do.
John Karwoski sat down with us to discuss the importance of everyone in the organization owning the voice of the customer.
Learn more →
