Let’s say you have a stand up that is developer only and has only 5 developers. Well within the 2 pizza box limit and really how much smaller can a team get.
A standup where developers are sharing what they are working on and people are actually paying attention means that as a developer I have to pay attention to 4 different technical discussions in the span of 15 mins.
The context switching and mental energy required to do that is tremendous especially when you may already be in the midst of working on your own complicated and mentally taxing project.
And this is the best case scenario. Throw in larger teams, throw in non devs, etc and it only gets exponentially more complicated from there.
The whole idea behind daily stand ups is broken.
What you want, at most, is a 1-2 per week regular status update, at the end of the day, when you’re already mentally tired so the time wouldn’t be better spent elsewhere, and good enough team relation building that you can approach each other directly when you need something.
Agile/scrum tries to replace team building with status updates. When in reality, what one needs is team members to get familiar enough with each other so they know that Jack really gets the post lunch slowdown, so after lunch is probably the best time to approach him because he may not be actively working on anything, while Jill likes to sort out all her emails and communications first thing in the morning and then focus on her work in long uninterrupted stretches, so that’s when I should reach out to her for questions/discussions.
And you need to build the ability in your teammates to be able to think about the bigger picture, and decide whether the question they need answered by Jill right now while she is in the middle of her deep work is really urgent and important enough that it warrants breaking her flow or not, or if it can wait till the next day or if it’s short and simple enough, till you guys get lunch together today.
The Big Lie is that team building can be replaced by process. And the Big Lie is pushed (with the best intentions) because team building cannot be packaged and sold as a 3 day workshop (well, it is, but that comes across as inauthentic and doesn’t usually work well, and team retreats have lost the majority of their flavor because honestly I don’t want to get to know the vast majority of my colleagues outside of our work lives). What it comes down to is good leadership to build a strong team culture, and that’s harder to find and develop.
So instead of making the effort and learning to accept that you will have failures where the wrong person is made team leader, or they were made team leader too early and building feedback mechanisms to identify such mistakes and hopefully correct them ASAP, we resort tom3 day workshops that teach agile and that you can replace culture with regular stand up meetings.
> The Big Lie is that team building can be replaced by process.
This! They try to do it backwards: instead of building the team that will organically end up having standups over coffee in the morning, forcing the behaviour in the hopes that will build the team.
> have to pay attention to 4 different technical discussions
Seems like a mistake to have actual technical discussions in a stand-up. So yesterday I've worked on X feature, I've gotten pretty far but I'm being blocked because of a dependency on Y feature. I'd like to continue today, developer Z (who is working on Y feature) can we discuss this after the stand-up? Of course, I could've communicated this before - and maybe I've already done that, but the rest of the team doesn't know. What if they want to pick up a new story that has a dependency as well. Should all this communication just happen in emails or slack messages? That's fine I guess but it doesn't hurt to have 15 minutes to get a good view of what the rest of the team is doing.
Once you get into the nitty gritty you should honestly just say hey let's take a subset of this group and discuss it after. Works for us. Non-dev people shouldn't be there, or at least shouldn't get turns unless they're actually working on issues in the sprint.
A standup where developers are sharing what they are working on and people are actually paying attention means that as a developer I have to pay attention to 4 different technical discussions in the span of 15 mins.
The context switching and mental energy required to do that is tremendous especially when you may already be in the midst of working on your own complicated and mentally taxing project.
And this is the best case scenario. Throw in larger teams, throw in non devs, etc and it only gets exponentially more complicated from there.
The whole idea behind daily stand ups is broken.
What you want, at most, is a 1-2 per week regular status update, at the end of the day, when you’re already mentally tired so the time wouldn’t be better spent elsewhere, and good enough team relation building that you can approach each other directly when you need something.
Agile/scrum tries to replace team building with status updates. When in reality, what one needs is team members to get familiar enough with each other so they know that Jack really gets the post lunch slowdown, so after lunch is probably the best time to approach him because he may not be actively working on anything, while Jill likes to sort out all her emails and communications first thing in the morning and then focus on her work in long uninterrupted stretches, so that’s when I should reach out to her for questions/discussions.
And you need to build the ability in your teammates to be able to think about the bigger picture, and decide whether the question they need answered by Jill right now while she is in the middle of her deep work is really urgent and important enough that it warrants breaking her flow or not, or if it can wait till the next day or if it’s short and simple enough, till you guys get lunch together today.
The Big Lie is that team building can be replaced by process. And the Big Lie is pushed (with the best intentions) because team building cannot be packaged and sold as a 3 day workshop (well, it is, but that comes across as inauthentic and doesn’t usually work well, and team retreats have lost the majority of their flavor because honestly I don’t want to get to know the vast majority of my colleagues outside of our work lives). What it comes down to is good leadership to build a strong team culture, and that’s harder to find and develop.
So instead of making the effort and learning to accept that you will have failures where the wrong person is made team leader, or they were made team leader too early and building feedback mechanisms to identify such mistakes and hopefully correct them ASAP, we resort tom3 day workshops that teach agile and that you can replace culture with regular stand up meetings.