I strongly disagree with the author’s stance, in part because I effectively implemented this in a previous team and it went poorly.
I was made team lead of a small subset of an infrastructure team. We had internal features we worked on (mostly efficiency and reliability improvements, sometimes major undertakings), as well as bugfixes from clients of our infrastructure. When I was made team lead, I inherited a twice-weekly “bug overview” meeting that served as a kind of standup/planning meeting for the team. I immediately declared it wasteful and unnecessary, because we could just work on the bugs “as they came in” (I even wrote a Chrome extension to watch the bug tracker for new issues).
What happened? Plenty of client bugs went neglected for weeks, with increasing anger from said clients. Some engineers worked all the time on feature work (ignoring clients), while some worked all the time on client work (making no progress on features and heading toward burnout). The team as a whole had no place or time to identify prioritization errors and have it be effective. After a few months I realized what had happened, reinstated the bug overview meeting and things started to recover (I’m simplifying and condensing a lot here, but reinstating the regular meeting did improve the situation greatly).
Psychologically, a standup provides a socially acceptable space to provide feedback on other’s priorities and receive feedback on your own. It can be really, really hard to stay focused on previously set goals, and I find some kind of regular planning meeting opens up opportunities for the team to help itself stay on track.
A planning meeting shouldn’t be the same as stand-up, though? If you kill the meeting that puts the work in order then, yeah, I’m not surprised that things went off the rails. I imagine you could have killed the stand-up part and kept the prioritisation part, and things might have been fine.
Psychologically, a standup provides a socially acceptable space to provide feedback on other’s priorities and receive feedback on your own.
I don’t think this should be part of stand-up. I think this is part of planning, when you (should) have all the stakeholders in the room.
When do those “You don’t need part x of the religion called Scrum” articles stop?
The author works with probably senior people on an already well defined product with a clear vision. Great. The author also realises that blindly adding metholodgies to your workflow doesn’t help at all.
I am waiting for people writing articles like: “Form follows Function”. If you want to create a great product but have no clue about your market and work with different sets of people, maybe find a way to align them. Do you need StandUps for this? Maybe, maybe not. Who actually cares?
The one big problem about software products is: Nobody cares if the product exists or not, and most of the engineers work there to pay their rent. Scrum does a great job in keeping things tight so nobody wanders off dreaming about what they actually wanted to do with their lives.
I did tons of projects in the past for different clients. And you will quickly see what motivates the team and at which level of expertise they are operating. If you create your own product you deeply care about with people who are intrinsic motivated to help you, then you will create your own way of doing things simply because you just care about this one thing.
Then, the function is clear and form follows. Will the form have some parts of Scrum or other things? Maybe, maybe not. But all the articles just say: If you follow x (form) then you will become y (function). But no happy person has ever done that. If you want something (y: function) then you will find the right form to get there.
One way I’ve seen daily standups work well is when you have an imminent release or a P0 bug that the team is working to address. The standup is set up for an explicit and temporary purpose and dissolves after the situation is gone.
Otherwise, I’ve seen standups devolve into people just mentioning what they’re working on, prioritizing looks over substantiative progress.
Yep - even when I was in a 100% waterfall environment, when something really important was looming management would come past every morning and gather everyone to discuss the plan.
I feel like perhaps standup is at its most useful when you’re working on something that makes the C-level execs nervous.
I personally don’t like standups but we do them so that designers know what devs do and vice-versa. It’s an opportunity to keep everyone in sync (we’re about 10 people). We do it once a week and keep it short. The article seems to skip over the fact that teams are not always performing well, or even just functional – processes and methodologies are necessary tools to help smooth out changes in mood and composition of the team. That being said, it’s good to see people questioning now established practices.
I strongly disagree with the author’s stance, in part because I effectively implemented this in a previous team and it went poorly.
I was made team lead of a small subset of an infrastructure team. We had internal features we worked on (mostly efficiency and reliability improvements, sometimes major undertakings), as well as bugfixes from clients of our infrastructure. When I was made team lead, I inherited a twice-weekly “bug overview” meeting that served as a kind of standup/planning meeting for the team. I immediately declared it wasteful and unnecessary, because we could just work on the bugs “as they came in” (I even wrote a Chrome extension to watch the bug tracker for new issues).
What happened? Plenty of client bugs went neglected for weeks, with increasing anger from said clients. Some engineers worked all the time on feature work (ignoring clients), while some worked all the time on client work (making no progress on features and heading toward burnout). The team as a whole had no place or time to identify prioritization errors and have it be effective. After a few months I realized what had happened, reinstated the bug overview meeting and things started to recover (I’m simplifying and condensing a lot here, but reinstating the regular meeting did improve the situation greatly).
Psychologically, a standup provides a socially acceptable space to provide feedback on other’s priorities and receive feedback on your own. It can be really, really hard to stay focused on previously set goals, and I find some kind of regular planning meeting opens up opportunities for the team to help itself stay on track.
A planning meeting shouldn’t be the same as stand-up, though? If you kill the meeting that puts the work in order then, yeah, I’m not surprised that things went off the rails. I imagine you could have killed the stand-up part and kept the prioritisation part, and things might have been fine.
I don’t think this should be part of stand-up. I think this is part of planning, when you (should) have all the stakeholders in the room.
When do those “You don’t need part x of the religion called Scrum” articles stop?
The author works with probably senior people on an already well defined product with a clear vision. Great. The author also realises that blindly adding metholodgies to your workflow doesn’t help at all.
I am waiting for people writing articles like: “Form follows Function”. If you want to create a great product but have no clue about your market and work with different sets of people, maybe find a way to align them. Do you need StandUps for this? Maybe, maybe not. Who actually cares?
The one big problem about software products is: Nobody cares if the product exists or not, and most of the engineers work there to pay their rent. Scrum does a great job in keeping things tight so nobody wanders off dreaming about what they actually wanted to do with their lives.
I did tons of projects in the past for different clients. And you will quickly see what motivates the team and at which level of expertise they are operating. If you create your own product you deeply care about with people who are intrinsic motivated to help you, then you will create your own way of doing things simply because you just care about this one thing.
Then, the function is clear and form follows. Will the form have some parts of Scrum or other things? Maybe, maybe not. But all the articles just say: If you follow x (form) then you will become y (function). But no happy person has ever done that. If you want something (y: function) then you will find the right form to get there.
One way I’ve seen daily standups work well is when you have an imminent release or a P0 bug that the team is working to address. The standup is set up for an explicit and temporary purpose and dissolves after the situation is gone.
Otherwise, I’ve seen standups devolve into people just mentioning what they’re working on, prioritizing looks over substantiative progress.
Yep - even when I was in a 100% waterfall environment, when something really important was looming management would come past every morning and gather everyone to discuss the plan.
I feel like perhaps standup is at its most useful when you’re working on something that makes the C-level execs nervous.
That’s a good rule of thumb. We had a daily standup for about a week when we were about to release our product.
Exactly. Otherwise it’s just an annoying ping every day.
Productivity is the greatest source of waste.
I personally don’t like standups but we do them so that designers know what devs do and vice-versa. It’s an opportunity to keep everyone in sync (we’re about 10 people). We do it once a week and keep it short. The article seems to skip over the fact that teams are not always performing well, or even just functional – processes and methodologies are necessary tools to help smooth out changes in mood and composition of the team. That being said, it’s good to see people questioning now established practices.
This is just the traditional weekly team meeting.
Yes I do.