How to deal with spending too much time in discussion meetings
We have a daily scrum meeting which never goes over the 15 minutes time box. A new discussions meeting has been added into our daily calender which if there is anything to discuss a developer can add this into the list and after each daily scrum everyone discusses these problems as a team. The issue is we have many things added each day and daily meetings have now gone from 15-30 minutes to 2-4 hours a day because so many things are being added to discuss. I am not the scrum master nor do I usually have things to discuss and half of us end up just listening as we cannot contribute to these issues, but because we have less senior members in the team many things get added and the PO wants to discuss them as a team. Because of this issue development performance has dropped significantly especially loosing 15-20 hours a week of development time.
Does anyone have any ideas how this can be resolved so I can mention these ideas to the Scrum Master - PO?
Thank you to everyone who replies :)
Why are people who don't have anything to contribute to or learn from the meeting present at them? I'm not sure why the Product Owner's desire to discuss things as a whole team matters. The Developers, among themselves, are responsible for creating the Increment, planning the Sprint, adapting their plan, and holding each other accountable.
Although I can see including some less senior team members in certain discussions as a learning activity, that should be at the team's discretion. Forcing people into discussions that they can't help or can't help them is taking them away from other work that can help progress the team toward the Sprint Goals. Plus, once you get the discussions focused on the right topic at the right time with the right people, you may be able to have some in parallel rather than people sitting around and unable to contribute.
Instead of mentioning it to the Scrum Master or Product Owner, bring it up to the entire Scrum Team in a Sprint Retrospective. Let the entire group discuss it. What you see as a problem may be a huge benefit to others. The team should do what is best for all members and not just a few.
You mention a loss of "development time". But isn't design and implementation part of "development time"? To be honest, it sounds like you are upset that you are losing time behind the keyboard writing code. But is the team struggling to deliver value in each Sprint? Are they failing to achieve the Sprint Goals created during Sprint Planning?
This is something that your team should discuss. As a member of that team, I encourage you to bring it up and make your concerns transparent. Discuss it with the team and see if they feel there is another way that the result can be accomplished.
A new discussions meeting has been added into our daily calender which if there is anything to discuss a developer can add this into the list and after each daily scrum everyone discusses these problems as a team.
Why wouldn't there be anything for them to discuss during the rest of the working day? What is the motivation for constraining the ongoing collaboration you describe to a meeting?
Are team members unable to demonstrate teamwork, and to self-organize who discusses what and when? Can collaboration only happen, by exception, if there is a meeting for everyone booked in the calendar?
You have to create gold rule: every team member must talk no more than 1,5 minutes. If more - coffee for all team members
I think any discussion or meeting should come with a timebound agenda. Just by adding a discussion randomly would not be of much help. The agenda keeps the participants focused and aware of the outcome. If any member tries to bring up a discussion out of agenda then that could be questioned and believe me this practice saves a lot of time for all participants. Secondly, once the agenda is set, check if any of the agenda could be taken care in another sprint event such as retro or planning. If yes, put forward your suggestion to the SM.I am sure that would be taken on a positive note. Lastly, discussion meeting happens and the daily scrum is not a replacement of discussion meetings. But make sure the daily scrum is productive and the discussion meeting too.
the product owner is only a listener tothe daily scrum not active participant. if he hijacks the meeting, then it is upto the scrum master to raise the flag and tell him that he has noted down his concerns and will facilitate a meeting with the relevant team members. find the root cause of so many doubts? is it due to poorly written user stories, too big a story, or not having information radiators that indicate the status.?
if new points come up then are they user stories/aditions to existing?-- add it to product backlog and discuss it in grooming call
How do you (Scrum Team) manage to have efficient and timeboxed Scrum events ?
What can you take from these Scrum events in your "other" events ?
one creative way would be to have a timekeeper to keep a watch on the time, have all prerequisites for the meeting ready
daily scrum: sprint backlog remaining hrs updated, burndown ready, risk log available, impediment log filled
sprint planning: have high priority user stories which meet defination of ready
sprint review: environment up and ready for demo, the acceptance criteria flashed per story during demo