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!