This post resonates with me. We are not coding machines. We are people. People whose lives, in a healthy work situation, are bigger outside work than in it. And the condition of ourselves is important to the overall health of the team. Knowing that Bob's child is sick, or Sandy's mother just went into hospice can help other members of the team understand why Bob or Sandy is distracted today.
The most productive team i ever worked on started every stand-up with a check-in, going around the room with each person giving an indication of where their head is today. Some might say this was touchy feely crap. We found it helped the whole human be at work, and built a strong team. For this to work, leaders must show the way.
After check-in, we worked the stories, rather than the "what did you do yesterday..." form.
One super great improvement on one of project was to exhale managers from the standup. We had only developers, equal to each other, with intention to help, and we never judged anybody if there was no progress when someone stuck.
Although, it’s not necessary and can be solved in the different way, but teammates need to feel safe in such cases. Of presence of a manager slowly turns standup into the status report, it become less and less productive.
A satnd-up facilitating technique I've grown fond of is "stories attend standup" (as opposed to "team members attend standup), which overtly puts the focus on the stories in the sprint instead of the individual people. The purpose is to break free from the type of standup that has devolved into a status meeting for some manager - by focusing on each story, with whomever is involved in that story yesterday and today, the standup can re-focus on the whole point, delivering stories that were committed to for the sprint (delighting the customer). I could write paragraphs about why and how this can help and how I've witnessed it.
It occurs to me that this is kind of opposite of the purpose that Kent is outlining here (not exactly 180 degrees opposite, maybe more like 130 degrees). I'm curious if the two concepts can coexist. Prevent daily standups from becoming managerial status calls that benefit noone, while at the same time serve the re-connect purpose that's outline here.
A team I'm working with does both separately - there's a 9:15 everyone meeting with a little bit of chat, some downwards comms from leaders and a mention of key activities & info coming up (mostly 'I've booked XYZ environment for training tomorrow', or 'the XYZ environment refresh failed (again) last night'.
Then the squads go into little standups, which differ depending on the team - some of them talk through the board from right to left, some have a less defined process
Back in 2018, my friend Amin Leiman took my framing of standup as "coordination" and switched it over to "synchronization". Sounds a great deal like what you're saying.
And again I feel deeply touched by this formulation of perspective in software development(or more general, driving outcomes together in a professional environment).
This post resonates with me. We are not coding machines. We are people. People whose lives, in a healthy work situation, are bigger outside work than in it. And the condition of ourselves is important to the overall health of the team. Knowing that Bob's child is sick, or Sandy's mother just went into hospice can help other members of the team understand why Bob or Sandy is distracted today.
The most productive team i ever worked on started every stand-up with a check-in, going around the room with each person giving an indication of where their head is today. Some might say this was touchy feely crap. We found it helped the whole human be at work, and built a strong team. For this to work, leaders must show the way.
After check-in, we worked the stories, rather than the "what did you do yesterday..." form.
One super great improvement on one of project was to exhale managers from the standup. We had only developers, equal to each other, with intention to help, and we never judged anybody if there was no progress when someone stuck.
Although, it’s not necessary and can be solved in the different way, but teammates need to feel safe in such cases. Of presence of a manager slowly turns standup into the status report, it become less and less productive.
Congrats! Awesome article!
A satnd-up facilitating technique I've grown fond of is "stories attend standup" (as opposed to "team members attend standup), which overtly puts the focus on the stories in the sprint instead of the individual people. The purpose is to break free from the type of standup that has devolved into a status meeting for some manager - by focusing on each story, with whomever is involved in that story yesterday and today, the standup can re-focus on the whole point, delivering stories that were committed to for the sprint (delighting the customer). I could write paragraphs about why and how this can help and how I've witnessed it.
It occurs to me that this is kind of opposite of the purpose that Kent is outlining here (not exactly 180 degrees opposite, maybe more like 130 degrees). I'm curious if the two concepts can coexist. Prevent daily standups from becoming managerial status calls that benefit noone, while at the same time serve the re-connect purpose that's outline here.
I really like both concepts - can they coexist?
A team I'm working with does both separately - there's a 9:15 everyone meeting with a little bit of chat, some downwards comms from leaders and a mention of key activities & info coming up (mostly 'I've booked XYZ environment for training tomorrow', or 'the XYZ environment refresh failed (again) last night'.
Then the squads go into little standups, which differ depending on the team - some of them talk through the board from right to left, some have a less defined process
That was surprisingly nice.
Back in 2018, my friend Amin Leiman took my framing of standup as "coordination" and switched it over to "synchronization". Sounds a great deal like what you're saying.
And again I feel deeply touched by this formulation of perspective in software development(or more general, driving outcomes together in a professional environment).
Loved the article, putting emphasis on people first approach!