We started this Scrum foundation series explaining we see four underlying concepts of the Scrum framework. In the past series of mails we covered the three pillars of Empiricism, and we covered the Scrum Values.
Now that we understand that we need trust, which is built up by living the Scrum Values, to bring transparency and as such have a good basis to inspect and adapt, we can have a look at the self-managing aspect of the Scrum Team.
👉 Self-managing, meaning the team internally decides who does what, when, and how.
Allowing to take more decisions = more mandate = more autonomy = higher motivation = higher effectivity.
Together the team is self-managing. Each of the Scrum Team members plays an important role.
Let’s take a look at the Developers.
Being accountable for creating any aspect of a usable Increment that adheres to the expected quality levels each Sprint, Developers do need to take active part in making decisions together with the Product Owner and Scrum Master.
During Sprint Planning, the Developers in collaboration with the Product Owner define a Sprint Goal. They also select Product Backlog Items to include in the Sprint in order to reach this Sprint Goal.
And so the Developer supports deciding on what.
Further during Sprint Planning, the Developers agree how they plan to reach the goal – for example: which items do we take on first? During the Daily Scrum they revise their plan, which might make them shift the order of dealing with the selected items.
And so the Developers supports deciding on when.
The Developers also have to agree how they plan to create a new Increment that meets the Definition of Done.
And so the Developers supports deciding on how.
These are just a few examples how the Developers plays a significant role in the self-management capabilities of the Scrum Team.
Self-managing is about having a mandate to take decisions.
The Developers certainly need to take an active part when it comes to deciding which Product Backlog Items are selected for the Sprint, in which order to work on them, and how to create the next Increment that adheres their Definition of Done. And as such they support the Scrum Team when it comes to making decisions about what, when, and how.
Note: without a clear (Product, Sprint and Quality) goal, without clear accountabilities, and without a clear boundaries, self-management will not occur.
Together with your Scrum Team, evaluate how self-management can be improved through the accountability of the Developers.
Also think about what additional insights or input the team would benefit from others outside the team about purpose and goals, the team’s accountabilities and the boundaries they have to work within.
We hope you will find value in these short messages and if you are looking for more clarifications, feel free to take contact.
PS. Next week we’ll have a look at self-management and the Scrum Master.
If you want to take a deeper dive into the core concepts we are covering in this blog series, then surely check out our Professional Scrum MasterY workshop. We have some scheduled in the coming period.
Don’t want to miss any of these blog posts? Have the professional Scrum foundations series weekly in your mailbox.