Self-management in Scrum Teams
An infographic to help your teams learn self-management
Self-managing teams are one of the foundational principles of Scrum. As Scrum Masters, we are trained to strive towards that idea. It embodies the first value in the Agile Manifesto: We put the individuals and the interactions first by giving the team autonomy on how to organise themselves to achieve the Sprint Goal. Only then do we give them tools and processes to support that specific way of organising themselves.
Self-management is critical to succeeding as a Scrum Team because it leads to ownership and empowers the team. And it creates intrinsic motivation, which is such a powerful driver of team effectiveness.
However, in reality we find that self-management remains a challenge. Developers in Scrum Teams often do not feel comfortable with self-management, and struggle to take ownership of their work.
This lack of ownership is especially visible in an inability to commit to the Sprint Goal, which is perhaps the most important accountability of the Developers. Too often we see that they are dependent on the Product Owner to tell them what to do. Too often we see the Product Owner literally spoon feed the Developers, to keep them busy.
The situation is made worse by the fact that Product Owners often think that it is their responsibility to make sure that the Developers are kept busy. The focus is on resource utilisation, which is terrible for flow and makes it very hard to focus on delivering value.
The result is that in Sprint Planning, rather than thinking about the Sprint Goal, work is selected to ensure that everybody has enough work to do for the Sprint. And often a Product Owner will feel guilty if someone is left wanting. They are expected to provide a solution on the spot, with no help from the Developers.
This relationship between Product Owner and Developers creates a reinforcing loop. Developers gradually lose the need to contribute and are simply conditioned to expect to be told what to do. They see the Product Owner as their manager, responsible for keeping them busy.
This in turn reinforces the role of the Product Owner as the manager of the work to be done, often even leading to additional accountabilities like Business Analysts and Architects. Which in turn leaves even less space for Developers to break out of the loop.
Self-management is a hard skill to develop. Especially because in general Developers are still usually regarded as coders — writers of code — rather than full partners.
Breaking the Habit
This lack of Developer empowerment is a hard habit to break. Even for those of us used to self-management, we have probably all had that experience where you simply have no idea what to do next. You are stuck and start procrastinating.
This happens even in a pair programming team. There will be moments when a Developer is finishing a Product Backlog Item (PBI) on their own. Perhaps doing some final minor fixes. Their pair has finished their work and has moved on.
The challenge is that breaking the habit requires a variety of skills and prerequisites, making it quite complex. But we are here to help!
To help break the habit and help Scrum Teams learn self-management more effectively, we have created a step-by-step approach to help Professional Scrum Developers decide how to pick up new work during the Sprint.
This approach provides a set of guidelines to help a Developer consider important aspects of the decision and practice the new skills of self-management. The goal is to create a new habit, one in which the Developer becomes habituated to assessing work value and priority.
Three things to keep in mind
Before diving in, there are three things that are very important to keep in mind when using our approach.
The Sprint Goal
The first thing to keep in mind is the Sprint Goal. While going through the steps in our approach, a Developer should always remember that the highest priority is to find out how they can help to achieve the Sprint Goal.
This sounds easier than it is. We all know that after Sprint Planning for the first few days, everything is clear, work is relaxed. But there always comes a point where things start to go sideways. And that is the moment you need to remind yourself to take a deep breath. And think of why you are here. The answer is simple:
What I’m going to do in order to help achieve the Sprint Goal together with my team.
As long as you keep this one rule in your mind while you are going through the steps of our approach, things should work out fine.
Flow
The second thing to keep in mind is a bit more abstract but no less important. It has to do with moving away from resource utilisation. The thing to keep in mind here is to realise the goal of working together as a Scrum Team is to create and maintain Flow, not to keep people busy.
This is Little’s Law: the more things you do, the longer each task will take. With the far-reaching implication that sometimes, having some Developers doing nothing is not only acceptable but also necessary for maintaining Flow.
Teamwork
Last but not least, a Scrum Team works as a team, without exception. This is not simply a question of formalities. Essentially, a Scrum Team combines their cognitive power to create a hive memory of the plan. This allows them to collectively have a more complete view of the Sprint, and therefore improves their ability to manage the Sprint more effectively as it unfolds. It is the ultimate remedy for the limitations of our individual skills and experience, and for the effects of cognitive load.
The Infographic
Let’s go through the step-by-step approach.
Pair Programming
The first step is to look at the PBIs that are in progress and see where you can help get them Done. Helping other Developers to get things Done is the perfect way to move closer to achieving the Sprint Goal.
The reason for this is two-fold. Working as a team creates synergy, making working together more effective than working alone. And it is perfect for keeping Work in Progress (WIP) low, which is a very effective way to improve Flow and really juice Little’s Law.
Helping others can be anything. Working on code together is hugely effective, but other tasks can also have great value. Perhaps you notice your teammate is lagging on documentation, so you pick that up. Maybe you can help by playing around with the functionality and giving them feedback. Do some refactoring here and there for them.
Anything goes just as long as you help get things Done.
Mini Sprint Planning
If you can’t find where to help, the next best thing you can do is to just simply call your teammates together in a mini Sprint Planning to decide which PBI in the Sprint Backlog to pick up. What is the next best thing to do to achieve the Sprint Goal? Just in case you are wondering — don’t wait for the Daily Scrum to get together to figure out what to do next. That is a waste of time. Do it right away!
Incidentally, this is where our third thing to keep in mind really shines: always working together with your team. Deciding what to pick up next together with your team makes that decision much easier to make and it builds self-confidence. But it is also hugely important because you commit to the Sprint Goal together, not as individuals. So it makes sense to involve the other Developers in preparing this new work.
Beyond the Sprint Goal
Although the main focus of a Sprint is to achieve the Sprint Goal, it does not mean that every PBI on the Sprint Backlog should contribute to the Sprint Goal.
Because Scrum is so much about continuously focusing on the most important work — the work that defines the Sprint Goal — the implication is that there is always other work which cannot be picked up. And often this can be quite frustrating. So here you have an opportunity to have a look at that work.
Perhaps there is a refactoring that although not essential, you have been dying to take care of for a while. Or perhaps there is some new technology you would love to try out. Maybe there’s an architectural diagram you think will help team communication.
These are all valid activities you can dive into, while you wait for an opportunity to get back to the Sprint Goal.
And yes, indeed, we would rather have you pick up something outside the Sprint Goal if you are on your own. That is how important we think it is to respect the hive mind of the team and the focus on maintaining flow.
Refinement
Closely related to the previous step is working on improving the Product Backlog. Like any Product Owner will tell you, there is always work to do to manage the Product Backlog. Perhaps do a quick tool comparison for one PBI. Or configure some extra monitoring in preparation for a second PBI. Maybe a PBI needs some clarification, or perhaps some requirements are missing. Even translating information in a PBI into a design or a diagram can be valuable. And maybe, you can even go and talk to the users or customers of your product.
In the infographic, this step sits together with the previous one. The reason we discuss the refinement separately here is because it is the riskiest way of looking beyond the Sprint Goal.
You see, there is no guarantee that any work in the Product Backlog will actually be picked up, so there is always the risk that any work you do there will be wasted.
This is also the reason why you should preferably collaborate with the Product Owner when you are considering this kind of work.
The final Choice
If you have gone through all the steps and have still not found anything you can do, your final choice is to pick up the next PBI on the Product Backlog. Together with your Scrum Team of course. Here the hive mind is even more important than when looking at the Sprint Backlog, simply because the PBIs on the Product Backlog have not gone through Sprint Planning.
Conclusion
So there you have it. Take the infographic and stick it somewhere where everyone can see it. And any time you feel uncertain, take a deep breath and have a look. Or even use it as a tool for inspection during the Sprint Retrospective.
Notice that we did not include the last step in the infographic here — just taking a break. We did this on purpose. For us, the decision to take a break is something that stands above the work, at the discretion of the person. In Agile, working in a sustainable way is so important to guaranteeing the effectiveness of the team, that deciding to take a break should be a no-brainer.
And of course, relaxing can mean anything. Maybe taking the time to learn something new. Or reading a book in the park. Maybe go home early for a change. Or even play some football or table tennis with a colleague. Go for a camping weekend. Let’s chill!
The bottom line is that while in a Sprint it is important to focus on achieving the Sprint Goal, it is not the most important thing. Your well-being comes first. And not just because we think it is ethically right, but also because it makes you more effective, more able to self-manage. Remember, it is about sustainable development and not about resource utilization.
Every now and then taking a moment to do something else creates space in your mind, space for thinking about the work, even subconsciously. Lateral thinking. The space to really come up with surprising ideas.
As they say, curiosity is the mother of invention. And idleness is the mother of all vices… or more positively, the mother of possibilities.
I wrote this article together with Ziryan Salayi, and he collaborated with Karelia Martinez to create the infographic. We are all a part of Scrum Facilitators!
You can download the infographic for free on our website: scrumfacilitators.com.
✅ All our content is 100% free to download.
✅ You can alter all our products and even use them commercially (YES, even commercially).
✅ We make €2,50 profit if you order our products. this profit goes to our Scrum Facilitators Foundation.
❌ We don’t require your email address to download our products.