After all of the random analogies from my Scrum Rants' intro post, let's kick in with some basics of Scrum: the Whos, the Whats, and the Whys. We'll start light with the whos, the "how many" ratios, and a why teaser.
The Whos:
Classically in software development the Who of Scrum is the "Scrum Team," which is a big old obvious-sounding "duh."
The roles within the Scrum team are as follows:
- The Product Owner [PO]
- The Scrum Master [SM] - "Scrum Coach" or "Agile Coach" are terms gaining popularity and I'll use "Agile Coach" a lot since I think it is more accurate AND, it just sits better.
- "Developers" - Not always actual developers, this could include supportive roles like QA ("Quality Assurance" or testing-focused-folks), designers, tech support reps, business analysts, even technical writers, so this can be a misleading term on some teams but we'll break it down. Suffice it to say, in classic software development Scrum, there HAVE to be some number of developers involved - but you DON'T want a case of too many cooks on any one scrum team.
The Golden Ratio:
Speaking of too many cooks, Scrum subscribes to the strange business concept that there definitely CAN be too many people on a team. To hit the ideal ratio, every Scrum team "should" include one Product Owner [PO], One Scrum Master [SM], and 3-9 "developers". This means a team should have anywhere from 5-11 people on it. No more than eleven. No fewer than five. Always one Scrum Master and ANOTHER, separate, Product Owner for each and every Scrum team.
Even more radical -- HUGE, really -- is the idea that one person should not try to work on or across more than one Scrum team. !! Impossible, right?? I know.
The Whys - A Teaser
Here the business-oriented CEOs reading this will cringe. But that's only because work environments are all about overwork these days: doing more with less of a salary budget is #bizgoals. Since the beginning of Software development, orgs have ascribed to the idea that the more developers you have on a team, the more bandwidth you'll have for doing more work! Simple, right? Another classic old-school thought is that developers are hands down the most valuable players for software development that exist. Any non-developers are extra and somewhat unnecessary for software development. Right??
Both mindsets are squarely rejected by Scrum. And the Scrum reasons are worth teasing out. We'll get there soon.
But! That's a cliff-hanger question in this Scrum needle-threading journey, first we'll need to dive into what the responsibilities actually are for each role listed above.
To Be Continued, until then consider:
- What are the different roles in your work team / how would you define each role?
- Are there distinctions/silos between the types of work each role accomplishes?
- Are there direct players vs supportive players within your team?
- How many teammates do you have? Does it feel like "enough"? Will it ever?
- Do you think adding more people would automatically enhance your team's productivity? What if your team doubled or tripled in size?
- How frequently do you collaborate with others on your team to complete tasks together? How connected do you feel to work that your teammates have completed?
Further Reads - "Best Agile Team Size for High Performance?"
