I was surprised by the objection that the ‘stories talk’ Daily Scrum would take too long. So we looked beyond the surface issue to understand the underlying context.
Is your Daily Scrum dragging on? In this episode, Peter & Richard dive into a real-world case of a 20-person Scrum team struggling with long, ineffective Daily Scrums. We explore why simply changing the format isn’t always the answer and uncover deeper issues in team structure and work organization. Learn how to identify if Scrum is the right fit for your team, when to consider alternatives like Kanban, and practical steps to improve collaboration and efficiency. Whether you’re an Agile coach, Scrum Master, or team member, you’ll gain valuable insights on optimizing your Agile practices for better results.
Learn More
Dive deeper into how we look at Agile, Scrum, and other ways to improve team collaboration. Check out the resources, articles, and training opportunities available on our site. And don’t forget to check out our other episodes – we cover a wide range of topics to help you and your team work more effectively.
Subscribe, Like, Share
If you haven’t subscribed to the show yet on YouTube or your favorite podcast app, why not do that now? We’re planning to continue shipping an episode every week, and we’d love to have you on the journey with us. Click to subscribe now.
And please rate and review the HW Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share. Your help spreading the word is super meaningful to us!
Episode transcription
Peter Green
Welcome to this mail bag edition of the Humanizing Work Show. Every so often, we like to feature a challenge from a client or listener because we see patterns that might be helpful to others.
Richard Lawrence
This week, we’re digging into a situation that a coach at one of our clients experienced. She had a lot of knowledge and experience that would be useful to the team she was coaching, but she was running into resistance.
Peter
You may remember from our Daily Scrum episode, which was episode number 59, that we like a Daily Scrum format that’s different from the common person-by-person report of what they did yesterday, what they’re going to do today, and what impediments are in their way. We like instead what we call the “stories talk” approach, which puts the focus on the work the team’s doing together rather than how busy each individual is. This is a great antidote to a Daily Scrum that has become a boring status report.
Richard
So, this particular coach was encouraging a team to try out that “stories talk” style Daily Scrum. But the team was resistant because they thought it would take too long. So, she asked us about it to see if we could help overcome the resistance. And it turns out there were layers below this particular presenting issue with the Daily Scrum.
Peter
There are always layers, right? But before we get into all of that…
This show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on our website, humanizingwork.com, and schedule a conversation with us if your organization wants to see stronger results in those areas.
And, if you want to support the show, the best thing you can do if you’re watching on YouTube is like and share this episode, subscribe to the show, and click the bell icon to get notified of new episodes, and drop us a comment with your thoughts and questions on today’s topic. If you’re listening on your podcasting app, the best thing you can do is rate & review it there and share this episode with your thoughts and questions on your socials.
Richard
All right, back to the topic, I was surprised by the objection that the stories talk Daily Scrum would take too long. Because, in my experience, it’s actually a way to make the Daily Scrum faster and more focused. So, I asked some follow up questions.
And it turned out that this team had 20 team members and over 60 items in the sprint backlog. Each person mostly worked on their own stuff.
This brings up some interesting, shall we say, opportunities for improvement. And the Daily Scrum may be part of that, but it’s not obvious that that’s the place to start.
Peter
Yeah, the first thing that sticks out to me is that team size.
The Scrum Guide recommends 5-9 people as the right size for a Scrum team. The idea there is that 5 people is often a minimum size to be big enough to be fully cross-functional, enough people that you need to start needing some minimal process framework like Scrum, and 9 people is about as big as you’d want to be to still be able to collaborate easily.
Richard
My thinking on team size has actually changed a bit over the years. Twenty years ago, I’d experienced how much easier it was to collaborate on a small team—like 5 or 6 people—so I agreed pretty strongly with the Scrum Guide advice.
But then I encountered teams where you couldn’t get a sufficiently cross-functional team with 9 people to actually deliver an increment of value. Which meant, if you did small teams, there was lots of dependency management and lots of rework as work items went back and forth between teams. This was particularly common in big orgs working on systems that had been around a while. Specialties were narrow and deep, and so a cross-functional team needed a lot of specialties represented on it.
As I learned more about complexity and collaboration, it became clear that we want to build teams around complexity because teams are the best context for the collaboration that complex problems require. So, now I’m more comfortable with larger teams if the context demands it. At least as a temporary move.
Peter
I think that’s probably true, especially for a team that’s focused on delivery. If a team is focused primarily on early stage discovery, things like that, where there might be many decisions and potentially pivots happening on an almost daily basis, 20 people is going to be too big to do that effectively. You’d probably need some smaller sub group to focus on decision making and the rest of the people to focus on technical problem solving.
Richard
In any case, back to this particular challenge…The 20-person Scrum team was at least a hint that something unusual might be going on.
To make sense of it, we needed to look at the nature of the work. The big question to me: How much do the team members collaborate on the work?
I’ve seen large teams where 4 or 5 or even more people would need to work together on each work item. They had different specialties that needed to come together to deliver value.
In this case, it sounded like there were 60ish items in the sprint backlog and everybody was doing their own thing.
Peter
Which explains why they didn’t love the Daily Scrum!
Richard
Yeah, for sure, but it still doesn’t really tell us if collaboration is needed. Because when there are that many work items and that much parallel work happening, there are two possibilities:
One is that the work has been broken up too far. They’ve gone beyond increments of value and they’ve broken the work into individual tasks and components. If they put those pieces back together, they might find meaningful slices that would benefit from collaboration.
The other possibility, though, is that the work really is discrete, individual tasks. In that case, we don’t really have a team. We have a group that does meetings to coordinate the work.
Peter
And if that’s the case, they probably don’t need to bother with a lot of Scrum, which is optimized for collaborating around a shared commitment.
Richard
Right. So, here’s the sequence of things I’d consider doing as a coach in this situation:
First, see if there are meaningful increments of value that would benefit from the team collaborating. If so, I’d work with the team’s Product Owner to reshape the top of the backlog to reflect that. And one way to get at that, that we do in our team launch sequence, actually, is ask the product owner or stake holders if there was one important thing this team cloud accomplish in the next sprint, what would that be, and see if they describe something that would require multiple people even if it’s not reflected on the backlog. And once you’ve done that, it would be worth trying the stories talk daily scrum to put the focus on that shared commitment and how the team’s going to collaborate to achieve it. Then, over the course of a sprint or two, I’d be watching to see if stable, similarly skilled sub teams emerge, and if they do, it may be worth inviting the team to explore splitting into two smaller teams that pull from the same backlog.
Peter
Of course, that path assumes the work fits Scrum and you’re optimizing for using Scrum well.
Right.
If that’s not the case—if you really do have a group of people doing separate but related work—Scrum’s probably not necessary. You’d probably be better off with something like a Kanban system where you don’t have to talk about all the work items or behave like you have a shared commitment. You can still have regular coordination points. But the focus will be on what other people need to know in order to do their work effectively.
Richard
Especially in organizations who are in the midst of adopting Scrum and are seeing benefit from it on a lot of their teams, it’s tempting to stretch practices like shared commitments, user stories, etc. way beyond what they’re made for. Because if Scrum works, it must work everywhere!
As our listeners know, we’re big fans of bare-bones Scrum as a starting point for things like product development. It’s just not the right tool for everything. If the assumptions behind Scrum—like the need to collaborate to deliver value—aren’t true, you’re not going to see the benefit you’re hoping for. You’re better off using an approach that fits your work more naturally.
Peter
So to wrap up, when you run into challenges implementing any kind of practice, particularly Agile practices like Scrum:
- First, look beyond the surface issue to understand the underlying context
- Second, consider whether the practice fits the nature of your work
- Third, be willing to adapt or try different approaches that better suit your team’s needs
Richard
Right. It’s important to remember that the goal isn’t to rigidly follow a framework, but to improve collaboration and deliver value more effectively.
Peter
If you found this discussion helpful, we invite you to dive deeper into how we look at Agile, Scrum, and other ways to improve team collaboration. Visit our website at humanizingwork.com for more resources, articles, and training opportunities. And don’t forget to check out our other episodes – we cover a wide range of topics to help you and your team work more effectively.
Thanks for tuning in, and we’ll see you next time on the Humanizing Work Show!
Last updated