Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Real-World Software Development: Daily Standups

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In case of an agile development being used for a project (Scrum, Kanban, etc), wouldn't longer (30 to 45 minutes) biweekly standups (that could take place each Wednesday and Friday) be more efficient and less distracting for the developers than daily standups of 15 minutes? Have you tried it for any of your projects?
 
Sheriff
Posts: 15815
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Al Razor wrote:In case of an agile development being used for a project (Scrum, Kanban, etc), wouldn't longer (30 to 45 minutes) biweekly standups (that could take place each Wednesday and Friday) be more efficient and less distracting for the developers than daily standups of 15 minutes? Have you tried it for any of your projects?


The book in this week's promo does not go into Agile Software development process like Scrum/Kanban/etc. or practices like Daily Standup Meeting as far as I can tell from the Table of Contents.

Your question hints at a basic misunderstanding of the purpose of the daily standup. It's not a status meeting, it's a planning meeting. The purpose is so that everyone is aware of what needs to be done for the day, what work is blocked, and who needs to collaborate to complete the outstanding work or remove impediments so the blocked work can continue. This meeting is held daily to increase communication and hasten feedback between team members. The more feedback you get and the faster you get it, the quicker you're able to adjust your plans and work. Mature teams might not even do a daily standup because they collaborate so closely together throughout the day and they are getting feedback and adapting their plans all the time. Moving the other way to a longer and less frequent "standup" is an anti-pattern for agility and should be taken as a warning sign that the team is regressing to less productive ways of working.

For teams who are not as mature or collaborative in their work, the daily standup becomes a boring status meeting where you're not really very interested in or affected by what others are doing. This means that you're just a group of individuals working independently, not really an effective and collaborative team and the daily standup just becomes a big waste of time. The "fix" to this is not to stop having them but to retrospect about how you're working and make changes so that the daily standup does what it's supposed to do.
 
Junilu Lacar
Sheriff
Posts: 15815
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In a dysfunctional standup meeting, the Scrum Master usually "goes around the room" and asks each person the three questions: What did you do yesterday, what are you doing today, and what's getting in your way? This format quickly devolves into a daily status meeting and does little to nothing to promote communication and collaboration. If your Scrum Master is the "hub" of this conversation, then you have a status meeting.

I like to have my teams focus on the work instead. That is, the team stands in front of the board where all the user story cards are (could be physical board or a big monitor if you're using software like VersionOne or Rally). We start from the right side with the things in progress and talk about the items we've been working on, who can help with those items, if they can be moved to done, if they're blocked, and who needs to get together after to talk about details. We avoid going into details in the standup. Then we move left and talk about items in the "TODO" column, and whether or not we are able to pull more story cards into the DOING column.

All this shouldn't take more than 15 minutes, especially if you have an ideal team size of 7±2 people. During all this, the Scrum Master should be largely silent, only speaking if the team starts getting into too much detail or if they ask to escalate an impediment outside the team for resolution.
 
Ranch Hand
Posts: 227
1
Python Ruby Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Don't some of us feel the same way on one or the other time during the the so called "stand up calls" , it
boils down to the effectiveness of the Stand up calls per se.
Nowadays this idea is being tossed around freely and end up being a misplaced and misunderstood priorities
of the stand up calls We should have a constant feed back loop in place to to check the effectiveness of the
stand up calls.

AS Junilu rightly pointed out most of the time the stand up calls are turning into stand up status calls
and nothing gets achieved ,  some one should seriously take a look into as how these ceremonies are
conducted

Thanks
Sundar
 
Al Razor
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Junilu and Sundar.
In my case the issue was that the team members were working on a few not related projects and developers would spend quite a lot of time every day listening to the information that isn't related to their project or their tasks. This was somewhat resolved by breaking a single large team into multiple smaller teams and each of these teams have a separate time segments for daily standups.
 
Paper beats rock. Scissors beats tiny ad.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic