In the fourth installment of my blog series on “More Agile Great Debates,” I dive into another five topics that people like to argue about. Let’s do this (again, in no particular order):
- Scrum Teams don’t always need a Scrum Master
- Scrum is a Silver Bullet
- Agile Adoption and Transformation are Easy
- The Product Owner Should Attend the Daily Scrum
- Scrum Teams can have more than 10 People
Scrum Teams don’t always need a Scrum Master
As a Scrum Master myself, I find this debate topic to be particularly sensitive, and it is hotly contested amongst agile practitioners. According to The Scrum Guide, the Scrum Master is one of three roles on a Scrum Team. So, to me, this means that the Scrum Master is an essential component of Scrum, and without one, you’re no longer using Scrum.
That said, there are some circumstances where it might not make sense to have a Scrum Master that is a full-time member of a Scrum Team. On newer teams, the Scrum Master is usually highly utilized, whereas more mature teams may have become high-performing and truly self-managing. In this case, their need for a Scrum Master could be minimal.
As teams mature, the Scrum Master may be able to support more than one Scrum Team. While this is not an optimal situation, it makes the best use of the value that a Scrum Master provides.
For high-performing teams, they may absorb the aspects of the Scrum Master among the team members. I’m not advocating this, but in some cases, this is what happens. They literally outgrow the need for a Scrum Master (just like parents and their children). An occasional need for a Scrum Master may pop up, but these types of teams are usually excellent at solving their own problems.
Scrum is a Silver Bullet
Nope. Not true – Scrum is NOT a silver bullet or a panacea. Sadly, this misconception is widespread and many uneducated leaders think that adopting agile, Scrum specifically, will solve all of their problems.
What most people don’t realize is that when agile and Scrum are first introduced, like acne treatments, it tends to make things worse before they get better. The reason for this is that the transparency of Scrum causes problems to be exposed, problems that were previously hidden (whether intentionally or not). Poor performers usually can’t hide under these conditions, and sometimes team changes must be made.
Scrum is also most useful in certain situations and contexts. Where this agile framework truly has its sweet spot is for efforts in which there is a lot of complexity and ambiguity. Work that is fairly predictable or repeatable, or projects with physical components, may still be a far better fit for a traditional project management approach.
The key is to evaluate each project individually and choose the best option for the situation. You wouldn’t use a hammer to install a screw, so don’t assume Scrum will work for every type of work, either.
Agile Adoption and Transformation are Easy
…said no one, ever. Agile is a refreshing approach to modern work, but it’s most definitely not an easy thing to switch to. Change is hard. Really hard. And people generally resist things that are new or uncomfortable. Anything that challenges the status quo is viewed as a threat, and resistance will happen.
The best chance of success in transforming to an agile way of working requires several things, with the biggest factor being top-down support from the organization. Without this support, efforts to move to agile will likely fail.
Detractors may also try to sabotage your efforts, so proactive change management needs to be part of the process of transforming. Bring your people along for the journey – don’t just “do it” to them. You must have buy-in for changing how your company works.
Finding champions is another key aspect of successfully adopting agile. It helps to have people who have gone through this change before, experts who can serve as cheerleaders and guides during the transition. Without positive advocates on your side, the attempt to “go agile” may initially fail.
The Product Owner Should Attend the Daily Scrum
This is kind of a trick question. Technically, the Product Owner is not required to attend the Daily Scrum, but it is a good practice. The Daily Scrum is really just for the Developers of a Scrum Team, so they can plan their day’s work toward achieving the Sprint Goal.
The benefit of having the Product Owner attend the Daily Scrum (as a silent participant) is that it helps them keep their pulse on the work happening during a Sprint. I have noticed that when the Product Owner doesn’t or won’t attend the Daily Scrum, they start to feel disconnected and are less engaged with the rest of the Scrum Team.
Another good reason to have the Product Owner attend the Daily Scrum is that they can stick around after the Scrum portion of the meeting is over and they’re available as a captive audience for the team. This enables the Developers to ask any questions or get clarifications on things. The added value of this practice is then additional ad-hoc meetings are not needed to resolve these issues.
So, my advice is that the Product Owner should attend the Daily Scrum whenever possible. It will increase engagement with the team as a whole, with the added bonus of speeding up development.
Scrum Teams can have more than 10 People
Over the years and various iterations of The Scrum Guide, the advice on Scrum Team size has changed several times. Once, it was 5 plus or minus 2 (so 3-7 people). Then it was 6 plus or minus 3, (3-9 people). In the latest version, published in 2020, the current limit is 10 team members or less.
I like to stick to Jeff Bezos’ “Two Pizza Rule,” which states that if you can’t feed your team with two large pizzas, then your team is too big. The largest team I led as a Scrum Master was nine people, and that was pushing the limits. Once a team grows to this size, the number of communication channels exponentially explodes and misunderstandings and issues are much more likely.
Teams that are too small can also have problems. If your team only has three people, it probably means that everyone is doing double duty, or more; meaning one person is Scrum Master and a Developer, etc. This is not a good combination for success, but as long as you’re intentional it can work (though it’s still not ideal).
My perfect team size is from 5-7 people, not including the Product Owner or Scrum Master. With that size of a team, it’s manageable, and with a skilled cross-functional team, you can accomplish a lot of valuable work each iteration.
Final Thoughts
In this installment of my blog series, I covered five more contentious agile great debates. Suffice it to say that you need a Scrum Master to “do” Scrum, agile transformation is not easy, and Scrum won’t solve all your problems. It is beneficial to have your Product Owner attend the Daily Scrum, but not required, and your team should be no larger than 10 in size.
That’s about it. If you have any thoughts or opinions on any of these topics of agile debate, I would love to hear from you, so please leave a comment in the box below.
And, if you want to check out the previous episodes of this blog series, you can find them here:
- Part 1 – Devs as Sub-team, the 3 questions, product goal, refinement, hybrids
- Part 2 – SAFe, showing undone work, Status Updates, Agile = Scrum?, Review vs. Retro
- Part 3 – Product Development, Backlogs, Scrum: Methodology?, PO owns budget
Check back soon for another blog to explore even more Agile Great Debates!