A guest post from a collegue of mine, Mike Jebber.
I have been doing some research on the Scrum.org site to get more information about the certifications. On their home page I spotted a forum thread about the differences between the Scrum Guide and the Scrum Primer, two different documents provided by Scrum Alliance and Scrum.org. You can find and read the article here.
I responded to the thread with my own thoughts on the discussion and part of what I talked about focused on things to look at to determine proper team size (since that was part of the discrepancy noted between the two documents referenced in the thread).
I wanted to share my response with you directly as I think it is relevant in a lot of our discussions…
We should be careful about how prescriptive we are as a training community in some areas.
Take for example the recommended team sizes. Let’s re-ask ourselves: “What really determines a products proper team size (and the product should be considered when deciding this)?” Several factors come to mind immediately:
- 1. Consensus in a Timely Manner: We have basic general need to gain consensus, in a timely manner, on a regular basis within Scrum teams. It’s been my experience over the last 5 years using Scrum (both properly and improperly) than any group with varying skillsets and subject matter expertise larger than nine makes gain consensus in a timely manner nearly impossible. This is true for Scrum teams, stakeholder groups, groups of PO’s working on complex integration projects, and any other gathered group. We have service groups, Enterprise Help Desk, Tier II Support, Release Management, and others who use Scrum to manage their work and perform their duties. In these cases, the teams have been able to move forward quickly with a larger group since the members on the team are all of like background, skillset, and SME. Again the focus is not just consensus, but consensus in a timely manner…remember we are time-boxed and need to deliver what we promise on-time. Our most “productive” groups have been 5-7 people and no more…why? They consistently provide more value to their customers on a regular basis with consistently high quality than teams which are larger.
- The Team’s Skillsets: Different products are going to require different skillsets. Yes, utopian Scrum has every team member owning all the skillsets needed to do every task on the backlog themselves. Ok, how many of you really live in this world today in your companies? It’s something we all work for of course, but it’s like reaching infinity, or the speed of light, or the perfect golf game, you can always get a little closer to the goal, so “what is good enough”? Team skillsets should be considered when determining proper team size for a product.
- 3. The Product: Depending on where a product is in its own lifecycle, and what the company/customer requests of the PO, different skill sets may or may not be necessary at different points in time. Maintaining a consistent, focused team on the product is always the best way for function, but some products may require a specialist’s assistance for several or many sprints until either the products team is well-enough versed on what to do moving forward, or the specific requests needs are met, and further maintenance of the new functionality can be handled by the now more experienced original team. Moreover, some of our Scrum Teams “products” are the services that they provide to the organization. These teams have a narrower focus on what is needed to deliver a high quality service and have shown to not be affected as much by team size as development teams are.
So I believe just talking about the numbers without getting in deeper about what they represent is prescription without diagnosis and doesn’t carry much value on its own.
Thanks for coming in today.
Chris
