Agile Scrum–Part 2 The Team
Sharing Expertise

Our office is filled with experts, and they love sharing that technology expertise to help others learn and do more. Explore our insights, tips and tricks through our blogs. Learn more about our thought leaders >

Back to Blogs >>

Published by Kathy Eager, on Monday, September 10, 2018

I recently wrote about Agile Scrum – Part 1 The Daily Scrum, in an attempt to dispel some myths and hopefully give tips on how to better use the Agile Scrum framework. Here in part 2, I’m going to talk about the team. Who is included, and who isn’t. And why that’s important.

By definition, the Agile scrum team consists of the Product Owner, the Dev Team, and the Scrum Master.

Product Owner – Firstly, notice that is singular. Not product owners, just product owner. One of the main reasons for this is that the product owner is responsible for the backlog. They are responsible for the content of the backlog and the priority of the backlog. They are responsible for bringing together (and winnowing out) stakeholder feedback.

Note, the stakeholders are NOT part of the team. They attend reviews and provide feedback THROUGH the product owner.

A single product owner eliminates the issue of “death by committee”. A single product owner eliminates issues where one stakeholder tells the developer to do it one way, and five minutes later another stakeholder tells the developer to do it another way.

Nightmare scenario: where all of the stakeholders are deemed to be product owners. This guarantees too many meetings, lasting way too long. Decisions will be made and unmade (and made again), wasting everyone’s time and prolonging the project.

The Dev Team – A bit of a misnomer here, in that the “dev” team is anyone who is doing the work of making the stories into reality. Sure, that can certainly include developers, but it can also include QA folks, designers, architects, etc.

Ideally, team members will be generalists. This helps when tasks aren’t getting completed within the sprint and can be shuffled to other members, as well as knowledge-sharing. It also helps to avoid bottlenecks.

The Scrum Master – As mentioned in Part 1, the scrum master’s job is to remove blocks. Dev team is stuck because of access? Scrum Master gets the team access. The Scrum Master also makes sure meetings are time-boxed and on topic, and just generally makes sure the Agile Scrum framework is being followed.

Team size – 3-9 members. Teams that are too large eliminate all the benefits of communication that Agile Scrum provides. Coordination of time, code, meetings, etc becomes too difficult with larger teams. Information is no longer as easy to disseminate and share. Teams that are too small can lack the necessary general skills to be flexible.

Nightmare scenario:15 people attending a daily scrum that lasts over an hour.

Scrum teams work because they can self-organize. (Remember what I said in the last post, Agile Scrum should NOT be micro-management). Self-organized teams are efficient and motivated. Having too many members and members not executing their roles correctly can kill self-organization, and therefore kill efficiency and motivation. Don’t be an efficiency-killer!

Categories: Agile,Agile Scrum,Scrum

Original Post:

Recommended For You
If you just cringed when you saw this was about Agile, you're doing it wrong.
View More ...
PSC's Kathy Eager is now a Professional Agile Scrum Master.
View More ...
Collaboration and flexibility are key tenets of Agile. Now modern tools exist that allow teams to communicate as openly and easily as shouting ov...
View More ...
I started using Visual Studio Team Services last year to manage internal projects at my company, PCS Group. A large portion of our consultants ar...
View More ...