The basic things are the big things in Scrum
The teams that get the best results aren’t necessarily the ones using every complimentary practice out there. They’re the ones who do the basic things well.
That's because the basic things really are the big things. Here are five so-called "basic" things that you can concentrate on to help push you to the next level.
1) Having a clear Product Goal
When I come in to coach a team, the very first thing I ask the Product Owner is, do you have a Product Goal and does the team know what it is? Because a clear (and hopefully inspiring) Product Goal gives the team the context that they need to understand what is in the Product Backlog and why. And psychologically, everyone wants to know why they are being asked to do what they are doing.
But more than that, it helps the Developers collaborate with the Product Owner and with each other. Developers can give the Product Owner great ideas on what might help to achieve the Product Goal. And they can make better decisions about how something should be developed if they know the goal for why they are delivering it.
And finally, a goal gives the Scrum team something to measure progress against rather than just counting tickets or tasks.
2) Making the Retrospective count
The Retrospective is part of the Scrum framework for a reason. Because when we ask ourselves how we can improve, we are empowering the team to own their own process. Which is a good thing because we're the ones doing the work!
The Sprint Retrospective should be positive, productive, and kept within the timebox. And every Sprint, the team should walk away with at least one small improvement.
A series of baby steps is better than a giant leap. Small changes tend to stick. Big process overhauls often don’t. Make one meaningful improvement every Sprint, and in six months you won’t recognize yourselves.
3) Really using Empiricism
Empiricism is built on three pillars: transparency, inspection, and adaptation. When we treat the Scrum events as opportunities to actually use those pillars, we stop going through the motions.
At Sprint Planning, Developers should adjust their plan based on what they learned in the previous Sprint.
At the Daily Scrum, the team should honestly ask: Are we on track? What should we do next?
The Sprint Review should not be a one-way communication. It should be an opportunity to inspect what was delivered and adapt the Product Backlog based on real feedback. No one wants to come to a meeting where they aren't contributing. So, if your Sprint Review has gone flat, it might be because your stakeholders want to be engaged rather than lectured at. At every Sprint Review, give them a chance to share their reactions to what was delivered. Let them vote on the best thing delivered, or on what to do next, or just ask what they think. Make it a conversation instead of just a demo.
At the Retrospective, we should identify one small improvement we can make, because a series of small improvements sticks better than a giant leap.
The Scrum framework is based on Empiricism and lean thinking. So really use the events to inspect and adapt. Without that, you're just going through the motions of Scrum without any power behind it.
4) Good meeting facilitation
Our days are made of time. Don’t waste it.
Keep events short, focused, and purposeful. Don’t let them wander. In larger meetings, use techniques like Liberating Structures so more voices are heard and the conversation stays productive.
Good facilitation helps a group of individuals start acting like a real team. People feel heard and ideas surface that otherwise wouldn't, and the group leaves with shared purpose instead of lingering confusion and probably frustration as well.
If you want practice using Liberating Structures, join us at our next Professional Scrum Facilitation Skills class. It's a great, one-day class for Scrum Masters, Product Owners, Project Managers and Business Analysts who want to lead more effective meetings.
5) Limiting Work in Progress
OK so I know I led the article with saying that you don't have to use every complimentary practice to do Scrum well. But that doesn't mean that complimentary practices are a waste of time. What it means is that the Scrum team should only use them if they find them helpful. So how do you know if limiting Work in Progress might help you?
If your testers don't have anything to do at the end of the Sprint, but they're overwhelmed at the end.
If your team has a high amount of work not done by the end of the Sprint.
If your velocity (or throughput) is highly variable
If individual Developers on the Scrum team are working on four or five things at once and then handing them off to Testers in one giant lump
Then you might want to propose to the Developers that they should consider establishing Work in Progress limits during the Sprint.
Here's how to get stated.
Visualize your work on a Scrum Board for the Sprint Backlog at least. Even if work just goes through three columns like To Do, Doing and Done. Or your work might go through a traditional workflow like New, Ready, To Do (picked for the Sprint), Development, Testing, and Done. However your work currently gets done today, start with that as the columns on your Scrum board.
Set limits for the active states of work only. In the first example above, the "Doing" column is the only one that would have a limit. In the second example, the Development and Testing columns would each have limits. Whatever workflow your team has established, the team should set an agreement that there is a maximum amount of items that can be in each of the active states at one time. Base the limit on the number of Developers in the Scrum team who typically work in each column. For example, if you have 5 people who typically do Development, then your Work in Progress limit might be 4 (if you want to encourage pair programming) or 10 if you want to start with looser limits to make the transition easier.
Get started there and discuss how to improve at the next Sprint Retrospective.
Here's why Limiting Work in Progress is helpful. It creates focus. It surfaces bottlenecks faster. And it helps the team finish what they start so they can get real feedback sooner.
Not convinced? Join us at our next Professional Scrum with Kanban class for more nuances on why Limiting Work in Progress is awesome, and how to get started.
Conclusion
These five things aren't flashy or new ideas, but they are important to the foundation of a great Scrum team. And when you do the small things well, a Scrum team can accomplish great things and have a good time while they are doing it.
