In the sixth installment of this series on Agile’s Great Debates, I take on five more topics that Agile practitioners like to argue about:
- Timeboxes are Just Guidelines
- Scrum Masters Can Support More Than One Team
- Managers Should Attend their Direct Reports’ Sprint Retrospectives
- Scrum Teams Should Stay Together
- Scrum Is a Fit for Any Type of Work
Timeboxes are Just Guidelines
What’s so important about time-boxing? The whole point is to keep within a constraint – e.g. the Daily Scrum should be no longer than 15 minutes. I don’t care if you’re standing or sitting – when the clock strikes a quarter past the hour – you should be DONE with the meeting.
Part of me wants to argue a contrary opinion, which is that each event should take however long it needs to take. This is far less prescriptive, but then you have less predictability and a more laisse faire approach to accomplishing the goals of each meeting.
So no, at the end of the day (and in my humble opinion), The Scrum Guide is clear about the maximum timebox for each Scrum activity. Also, keep in mind that you don’t have to use the maximum amount of time – if you can get through your Daily Scrum in five minutes, rather than 15 – good for you!
Scrum Masters Can Support More Than One Team
This is one of the agile topics that get people riled up and with good reason. I’ve heard many different opinions about this – such as “A good Scrum Master can support more than one team, but a great Scrum Master only supports one.”
But what if your team has grown into a high-performing team, and is truly self-managing and self-directed? Do they really need a Scrum Master that is full-time and dedicated only to them? While I can always see value in having a Scrum Master, in this case, their time might be better by training, joining, or supporting a different Scrum Team.
I’m generally not a fan of splitting my focus, preferring to work on only one team and one product. Unfortunately, the reality is often that there are more projects and business needs than there are people to do the work. In situations like this, there may be no choice but to split a Scrum Master between multiple teams.
Managers Should Attend their Directs’ Sprint Retrospectives
While I don’t recall there being a specific rule about prohibiting people managers from attending their direct reports’ Sprint Retrospectives, I think it’s a bad idea (and not a best practice). As everyone knows, when your direct manager is in the room with you, you’re a lot less likely to feel safe and speak with candor.
However, in reality, you can’t always avoid having a manager at the Sprint Retrospective, especially if they are also a contributing member of the Scrum Team. To make this work, my advice is usually to make it clear at the beginning that this is a “safe space” and everyone should feel okay to share their true feelings.
The manager should also be reminded that this meeting is not meant for evaluating their employees. This is easier said than done (like disregarding a piece of evidence that has already been shared with a jury), but do whatever you can to make sure everyone is comfortable and that nothing said in a retro is used to punish someone.
Scrum Teams Should Stay Together
As a Scrum Master, my goal is almost always to help grow my team into a high-performing team. If you’ve ever been on a team like this, you know that it’s magical, and you never want to break up the team.
Again, in reality, it isn’t always possible to keep a Scrum Team intact, due to the needs of the business. Often, this happens in organizations that haven’t yet made the switch to doing projects versus building products. With projects that have specific beginning and ending results, the team is often disbanded after the final handover, and everyone is reallocated to other things.
Another consideration is people might start to get bored after supporting one product for an extended period, and they want to grow into other areas or learn new skills. This often causes the person to leave on their own, and any time you lose (or add) a team member, it’s like hitting the “reset” button of team formation, and the dynamics will never be the same again.
Scrum Is a Fit for Any Type of Work
While I love Scrum and agile ways of working, is it truly a framework that can be used for any type of work? Well… almost. I love the Stacey diagram that depicts the sweet spot for work that would best be handled in an agile way.
However, some types of projects are not a good fit for Agile. When more is known than is unknown, when there is low complexity, and when you’ve done previous similar projects successfully, you probably don’t need to use an agile approach. Another example would be almost anything that has physical components that have to be done in a particular order (think construction).
Scrum was originally created to improve software development, but since it has expanded to be used in many other contexts – everything from Marketing to home improvement projects, to your kid’s homework. The key is to pick the right tool for the job – if it’s agile, use it; if not, do something more traditional, and you’ll have more success.
That’s a Wrap
So, there you have it – another five agile debate topics down. But don’t worry, there’s still more to come! In the meantime, please let me know if you have any thoughts or comments.
And, if you want to check out the other blogs in this series, here they are:
- 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
- Part 4 – Scrum Master needed?, silver bullet, adoption is easy, PO at scrum, 10+ teams size
- Part 5 – Conflict, leadership, technical POs, who should write User Stories?, extending Sprints
And, bonus, the one that started it all: 20 Great Agile Debates.