Based on some recent experiences and conversations, I wanted to explore a couple limitations of Scrum that have come up recently.
1) Limitations of the Standup
Long-time readers will know that I’m a strong advocate of the 5-minute daily standup.
Where 5-minute daily standups are weak is in any discussion of the larger picture. If you try to have a reasonable discussion about the larger picture during a 5-minute standup, this will take far more time, and most of your group will have tuned out by the time you’re done. Conversely, under normal operation, your 5-minute daily standup is great at firefighting issues with currently open tickets, and seeing what is not being worked on, but unless you’re paying active attention, it’s easy to miss someone being semi-blocked or not speaking up to say that they’re blocked. This can happen often due to pride or embarrassment, often with inexperienced or new team members.
Proper use of one-on-ones is probably the best way to deal with this. But if your team member is shy and embarrassed about issues they’re having (especially if they feel technically inadequate), you may need to do some serious digging and active listening to ferret this out. This will require, but also help gain trust of your team member.
Another method is to have regular demos, perhaps daily or weekly, as part of your cadence, which will very quickly show who is having issues (or who does not know how to demo).
2) Limitations of having many small tasks
Organiation and prioritization can be difficult and time-consuming. It can often be easier to delegate all of it to the Product Owner (after all, they have final say on prioritization). However, they may not be the expert on which items should be split into smaller items, or they may try to determine too much of the ‘how’, instead of focusing on the ‘what’ and especially the ‘why’.
What this can cause is a disconnection between the ‘why’ and all of the rest of the team. The work can start to feel like an endless stream of little unimportant tasks, rather than a cohesive whole.
My tactic to deal with this would be to have a planning and prioritization session with everyone attending, so the entire team can be and feel involved, and so the entire team understands the why of each of the items (and can influence which ones will be done and not done!)
I was talking to a manager from another company earlier this week, and they had (I thought) a good idea for dealing with this type of issue. I would typify it as being somewhat orthogonal to Scrum, perhaps somewhat orthogonal to Agile. The concept is to give each member of the team a project of their own, where they are completely in charge. This way, they have complete ownership, and ostensibly will be much more engaged. I like this idea, and it helps a lot with the next point:
3) Scrum works well when team members are well-fungible
A lot of Agile and Scrum especially assumes that team members are reasonably fungible, sometimes almost to ‘Mythical Man-Month’ levels. If you have team members who have vastly different specializations (like Valve’s ‘T-shaped individuals'[1]), your prioritization may be greatly limited by their inability to map to your team members’ strengths.
The tactic mentioned above, where you give each team member a small (or large!) project of their own can help a lot here, but depending on how much of a disconnect you have between the composition of your team and what your organization requires, you may need to hire some people.
[1]If you have not read Valve’s Employee Handbook, go and read it now. I’m talking above about their description of employees who are ‘T-shaped’, which means that they have a broad set of skills, but are exceptionally deep in one area.
