How is the Scrum development team different than a “normal” team?
This question is about more than just terminology, and it gets to the core of how Scrum changes the way we work. This article will cover three essential topics to help you.
At first glance, a Scrum development team may look like any other team. However, once you start spending time with them, you’ll observe a few key differences. Three distinctions of a Scrum development team include
Self-organizing is a term you’ll find a lot in Scrum literature. It means they share leadership and accountability as a team, and they don’t report to the Scrum Master or Product Owner.
They have significant freedom to identify how to solve the problems and deliver value. Said another way, the Product Owner owns what value to create, but the team owns how to deliver that value.
The rhythms of the Scrum allow the development team more autonomy. Once a sprint begins, it is a safe period of time where no new work can be assigned to the team. This period allows the team the freedom to focus and adjust as they need. Because the requirements have been clearly defined, the team can decide how they do the work.
The whole team owns the work in the sprint backlog. If something isn’t done, it’s not the fault of one person; it’s the responsibility of the whole team. It’s not, “Bill didn’t get that done,” it’s “we didn’t get that done.” This is a critical mindset shit.
The team checks in each day through the daily scrum to stay in sync. As they evaluate and adapt each day, they engage and listen to what each other is doing because they share ownership at the end of the sprint.
They also leverage the sprint retrospective to evaluate their team functioning and adapt to improve. Not only are they sharing ownership for the value delivered, but they are also sharing ownership for how to function as a team.
Traditionally the development team is fully allocated, focused on a single product, and cross-functional. This is the ideal setup for a Scrum team to truly thrive.
However, many organizations struggle to go all-in with exclusively focused teams. This is a big issue because the split focus decreases the team's agility and mutual trust.
If this is your situation, you can work with your leadership to still clarify the boundaries for non-team work somebody can be asked to do. It’s not ideal and could really derail the team learning Scrum, so proceed with caution.
Leaning Scrum for the first time can be a bit overwhelming. There are many new terms and concepts in Scrum.
Well we’re here to help.