Skip to main content

Scrum Mastery: 5 Steps to Improve Team Process

July 16, 2018

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.

How do you work as a team to maximize the benefits of Scrum and agility?

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.

How does your team determine what to build?  How does your team build it?

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.

5 Steps to Improve Team Process

Step 1:  Increase the Depth and Breadth of Transparency

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:

  • How do we make decisions about what to build in the product? How are those decisions transparent and to whom?
  • How do we make decisions about how to build the product? How are those decisions transparent and to whom?
  • How well do we understand team progress towards incremental goals at any given moment? (This could be goals at a daily level, a Sprint level, or longer periods of time.)
  • For every action we perform, what is the valuable outcome of that action? What could make it more valuable?
  • How do we build quality into the product? What is the current level of quality in the product? What’s the trend?
  • What factors have led to successful outcomes? What factors have led to not-so-successful outcomes?
  • What assumptions are we making? How are we validating those assumptions?

Step 2:  Apply Lean Principles Simplified

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.

  • Maximize value
  • Minimize waste
  • Maximize flow

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:

  • Building things customers don’t want/ don’t use
  • Task switching and distractions
  • Partially done work
  • Poor quality
  • Unnecessary or ineffective processes and documentation

Step 3: Expect Change and Seek Better (i.e. Inspect and Adapt)

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.

Be part of advancing your field or industry.

Step 4:  Focus on Delivering a Done Increment

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.

How can you improve your process to get to Done?

Well, there are many ways to improve.  However, there are some universal things to consider when it comes to Done. So Simon Reindl and I have narrowed it down to 7 specific areas of your process to explore, applying steps 1-3.  These are the 7 areas we use to help team’s start their journey of discovery and improvement:

  • A solid Definition of Done
  • Effective use of Sprint Goals
  • Getting PBIs to Done earlier in the Sprint
  • Building quality in
  • Tackling technical debt
  • Identifying and removing impediments
  • Growing team skills, knowledge, capabilities

Step 5:  Move Beyond the Low Hanging Fruit

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.

What did you think about this post?