Scrum Is About Delivering As a Team
Because everyone can do their part right, but the patient might still die on the operating table if the team does not look at the whole picture.
I know, I know. We are talking about a Scrum Team, not a medical team. But go along in my metaphor and think of the patient as the Increment and the Development Team as the medical team.
To make sure we all use the same vocabulary, here are some of the definitions I will be using:
Scrum Team: The Product Owner, Scrum Master and the Development Team.
Development Team: the members of the Scrum Team that develop the Increment.
Increment: The sum of all the work developed by the Development Team during the Sprint. The Increment is a step toward a vision or goal.
Sprint: a time-box during which a “Done”, useable, and potentially releasable Increment is created.
Sprint Goal: an objective that will be met within the Sprint through the implementation of the product backlog, and it guides the Development Team on why it is building the Increment.
One of the most important things that show whether Scrum is implemented effectively in an organisation is the way that the Development Team looks at the Increment and on their role in delivering it. There are no individual roles in the Development Team in Scrum, as is clearly stated in the Scrum guide:
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Why is this so important for the Development Team to understand? Why can they not just focus on achieving their small part of the work that needs to be done? Well, let’s have a look at the Sprint events and artifacts and dissect what the lack of individual roles in the Development Team means.
Sprint Planning is done as a team
It’s the Development Team that commits to building the Increment. Not single individuals. If not everyone believes that the Increment and the Sprint Goal are achievable, it’s time to inspect and possibly adapt at the start of the Sprint. Try to figure out why that is the case. Is it because some team members feel that they have to big a part of the Increment on their plate? Or is the work and vision on the Increment of the others in the team not clear? These questions you preferably want to have answered as a Scrum Team before you start your work. By planning as a team, it helps as well to demonstrate what the role of team members is in relation to the bigger picture of the company, thereby helping with motivation.
Risk if the Sprint Planning is done as individuals: If the Sprint Planning is not done as a team, it leads to situations where some team members finish early with “their” part of the Increment and move on to new tasks before the Sprint Goal is achieved, which in turn leads to unachieved Sprint Goals and less value for the customer. It will also lead to less buy-in to the planning, as individuals will agree with the tasks they have to fulfil, while not necessarily agreeing with the work of other team members.
The Daily Scrum is done as a team
The Daily Scrum is a moment for the Development Team to plan for the upcoming 24 hours and check-in, whether we are still on track to reach the Sprint Goal. If done well and as a team, the Daily Scrum will tell the team whether they are still on track or whether to make adjustments to achieve the Sprint Goal. It is not about summing up what you as an individual did or didn’t do. It is the moment to share with the team how the past 24 hours and the upcoming 24 hours went so that the team knows when new situations arise. So focus on the Sprint Goal as a whole and not on small tasks.
Risk if the Daily Scrum is done as individuals: Demotivating about the Daily Scrum, are the moments that someone says that they had “meetings” or go through a list of tasks, without mentioning the learnings or goals of those meetings. The Daily Scrum is about the Development Team inspecting the plan for achieving the Sprint Goal, and the simple mention of a meeting does not help towards that goal. Those are examples of someone doing the standup as an individual, checking a box without thinking why the Daily Scrum happens or how they can contribute and help others in the team with the 24 hours planning.
The Sprint Review is done as a team
A part of the Sprint Review is the sprint demo. Some Development Teams find it difficult to demonstrate their work, depending on the type of speciality they have. Back-enders typically have less visual work to show than the front-enders. But it does not matter who does backend of the frontend. Team members can demo each other work as well. Show the value delivered as a team towards the Increment and switch up the role of demonstrator. Because the work happened as a team, it should not matter much who demos the work.
Risk if the Sprint Review is done as individuals: Development Team members show their work and do not mention the bigger picture. They talk about features and think half working functionality is done, as they completed their part and a different team member needs to finish the rest. But, it does not matter if one team member has done all his tasks. If there is no value to the customer to deliver, there is nothing done. The patient will have died.
The Sprint Retrospective is done as a team
During the Sprint Retrospective, it is the team that looks at their work as a whole. It is about inspecting how the team can work more effectively. It is a moment to learn as a team.
Signs that Sprint Retrospectives are done as individuals: Team members do not take feedback in if it was not directly related to them personally. Thereby not identifying with the problem as being their own. Even if the input does not affect them personally, it does affect the team that they are a part of and should, therefore, own it. This will prevent the team from learning and adapting, halting their growth.
To summarise
The Development Team has a lot of responsibility, and it can be challenging to keep an eye on the bigger picture when working as a member of that team. But since Scrum aims to deliver value, and it is not about ticking boxes, the bigger picture is the thing that matters. And that can only be achieved by understanding that as a member of the Development Team, your individual contribution is not what counts. It is the Increment delivered as a team that counts. And if we keep that in mind, the patient may live to see another day…
Justus is a freelance product owner and product manager, currently looking to broaden his horizon in Scandanavia.
