This is the third in a series of posts exploring Scrum Mastery. In our first post, we introduced the 4 dimensions of Scrum Mastery. In the second post, we explored how to grow a strong team identity. Now we will explore the team process dimension.
Recall that the Scrum Team defines their own process within the boundaries of the Scrum framework. This includes their practices, tools, interactions. This includes how they fulfill the accountabilities of their Scrum roles and how they utilize the artifacts and events.
From the product management practices to the engineering and quality practices. From how your team communicates and collaborates to how they effectively use and grow team knowledge, skills, and capabilities. And much more.
There is a lot going on when it comes to delivering complex products in an uncertain and constantly changing world. So let’s try to simplify and create some focus on tangible actions.
Photo by rawpixel on Unsplash
In order to improve team process, there must be transparency to the process. Scrum provides a minimal level of empiricism if you just “follow the rules.”
But much more is possible when teams truly embrace empiricism. Most importantly, teams must understand how their process is affecting their outcomes.
Here are some questions to explore with your team:
There are 7 lean software development principles. While they are all useful to understand, I’m all about simplifying. My colleague Simon Reindl introduced me to what he calls Lean Principles Simplified.
These three principles are interrelated. Maximizing flow means we move items (i.e. value) through the process as quickly as possible, without risk to quality and customer satisfaction. Removing waste helps us do this. Waste is anything not adding value to our customer.
Now assess your process through the lens of the Lean Principles Simplified. Seek out signs of waste and opportunities to maximize the flow of value. Some common examples of sources of waste:
The practices and tools a team uses will be influenced by the type of product, the technology platform of the product, the environment in which the product is used, who uses the product and how they use it, regulatory and legal conditions, market trends, changing needs of the business, etc.
So… a lot of stuff. And much of that stuff changes over time. Therefore, it is essential that teams remain vigilant in inspecting and adapting what they are doing, why they are doing it, how they are doing it, and the benefits they are getting from doing it.
New practices and tools are continuously being created and shared in product development communities around the world, so it is important to stay connected and continuously learn.
In fact, teams often need to modify and invent new practices and tools to meet their unique needs. There is no such thing as a best practice when it comes to complex work. The best practice is the practice that works for your team right now in your current situation, and what that will look like a month from now is likely to be different because your situation will be different.
Take steps 1-3 and apply them in the context of delivering a usable Increment of value that meets a solid Definition of Done.
Done is the entire point of Scrum. Having a releasable Increment of product is what helps reduce risk, optimize predictability, and enable the benefits of business agility. Done is the only true measure of progress.
If you are not delivering a Done Increment at least by the end of every Sprint, this is where you must focus your attention.
Small, quick wins are good. You can get solid benefits from easy process improvements. You can even get some benefits from local optimization. Yet there will come a time when you need to move beyond the low hanging fruit. And you will need to seek system optimization over local optimization (which may mean looking beyond your current team/ product constructs).
I will share an example. I worked with a Scrum Team that had no test automation for a large and very complex product. Implementing test automation is a lot of work and has significant costs. Test automation came up as an idea for improvement multiple times over many months, however, they chose to focus on other opportunities to improve quality and reduce waste in their process. And they did improve quality and effectiveness. However, the gains of each improvement were smaller and smaller.
One day they realized it was time to move beyond the low hanging fruit to seek greater benefits. They needed to take on the test automation challenge. And because of their small, quick wins, they had grown a stronger team identity and were ready to expand their range.
Scrum Teams own their process. I cannot emphasize this enough. And when people feel ownership in something, they want to invest in making it better.
Improving team process is an ongoing effort. It never stops.
Does your team consistently build a Done Increment by the end of every Sprint? In what ways does your team demonstrate they feel ownership in their process?
What aspects of your team process are not so transparent and perhaps being ignored? What steps do you want to put more energy into to support improving team process?
Read all posts in this series:
___________________________
Want to take your learning deeper?
If you enjoyed this post, check out my book Mastering Professional Scrum.
This book illuminates what it means to effectively apply empiricism, an agile mindset, and teamwork to truly unlock the benefits of agility.
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.