Is it time to challenge the norms of Daily Stand-ups?

[Danny Flynn]

The purpose of this discussions is to explore the challenges that the community has faced with Daily Stand-ups, and to understand ways that you overcame them. (in or out of the box)  I also have a few questions at the end, related to the structure of the stand-ups. 

There are several certifying organizations with similar definitions for the Stand-up event...meeting. (Okay that was on purpose. I wanted to make some Agile heads explode.)  I am not sure why, but it does; even though the scrum guide refers to it as a meeting numerous times.

I have included a few below: 

Atlassian -  Daily Standups: How to Run Them - Agile Coach Ep. 8 (2019)

Scrum.org - Daily Scrum: daily time-boxed event of 15 minutes for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.   

Scaled Agile, Inc. - Coordinating with Daily Stand-Up Meetings Each day, the team has a formal event—the Daily Stand-up (DSU) meeting—to understand where they are, escalate problems, and get help from other team members. During this meeting, each team member describes what they did yesterday to advance iteration goals, what they are going to work on today to achieve the iteration goals, and any blocks they are encountering in delivering iteration goals. As this is a daily coordination meeting, the Scrum Master has to keep it short and to the point. The DSU should take no more than 15 minutes and is done standing up in front of the storyboard. But team communication does not end there, as team members interact continuously throughout the iteration. Facilitating such communication is the main reason why ScrumXP prefers that the team be collocated whenever possible.     © Scaled Agile, Inc.  

Scaled Agile Inc - Scrum XP

Then comes the three questions, and don't deviate!!! (Agile gods get angry)

• What did I do yesterday? 
• What will i do today? 
• Impediments or Roadblocks? 

I have found that the Agile community can sometimes be very rigid, even dogmatic about maintaining the structure of this meeting.  

As Development Teams, is it time that we rethink the structure of the meeting, maybe even retool it?  I have encountered some Scrum Masters that were more interested in adherence than information radiation, or meaningful communication among the team.   Meaningful is subjective I know, but isn't that for the Development Team to decide? 

Consider how the Scrum Guide defines this meeting. 

The Scrum Guide defines this meeting's use as, "to inspect progress towards the Sprint Goal, and to inspect how progress is trending toward completing work in the Sprint Backlog." 

The Scrum Guide also says that, "The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Spring Goal.  Some will use questions, some will be more discussion based."  It then suggest the three questions, which have now become mainstream.  

My questions for the Community is,

• What structures have you used in place of the standard Stand-up questions
  • If you used Discussion based methods, did you stay within the 15 minute suggested time?  
• What challenges have you encountered with this meeting? 
  • How did you overcome them? 
• Do you think it is time to potentially re-work this meeting? Remember...have an Agile Mindset!

I look forward to hearing your thoughts! 

[Danny Flynn]

@Lewis Haidt Does an Elite Badge await? 

[Danny Flynn]

@Lewis Haidt bumping this back to the top of your inbox. :) 

[James Bullock]

The thing to challenge is "norms" in preference to effectiveness; external compliance to internal impact; being "Agile" to being useful. "Norms" are suggestions; "Agile" prescriptions  are candidate solutions. You job is to do something useful that works in the situation you are in. 

If turning the crank on already-designed, externally-designed production systems was all it took, we'd just automate all that and dispense with people altogether. Like collab systems, guidelines, protocols, and, yes, 'norms" can give you "human plus" doing the work at hand. That's the point. Or not, if they don't fit for you. That's also the point.

And it's not now "time." It's always "time." Developing how you work is the job. (See the book The Reflective Practitioner: How Professionals Think in Action.)

[Danny Flynn]

I love it!  ...and I agree!  

[Danny Flynn]

I am curious, what could some alternative stand-ups look like?  I understand these questions focus in on, and provide the base information for moving towards a sprint goal from a status perspective.  However, it seems at times that the structure can stifle team information sharing, if every thing is a break out afterwards...that may limit information radiation.  Especially in distributed teams.  

[James Bullock]

I'm reluctant to describe "alternative stand-ups", because "stand-ups" are a very precisely designed element in a very precisely designed work orchestration system, or two if you count XP & SCRUM independently.

Concretely, I've worked in situations where nobody would need or wait for a "stand-up" to deal with something blocking them; others where nobody knew what anybody was trying to do, and others with tons of activity -- formal and informal -- about what people were in principle "doing", and what's "blocking" them, with no delivey or completion protocols or standards.

The work-wrangling protocol that works depends on your situation.

The useful take, I think, is with things like the Atlassian suite you get enough wired-in structure to jump start something, *and* the ability to adopt what you want, ignore what you don't and adapt the tools as helps you most. And synching or enabling current code-prodution is only a small part of what collab tools can support. (That was pretty shameless fan-boy-ing. I feel a little dirty.)