5

We are running a project with a team of around 60 people using Scrum. Half of the team reports to one project manager; half to another project manager. Those 2 project managers meet with the test lead and the program manager in a daily Scrum of Scrums (SoS). Given that this is new, there is some concern about keeping the SoS short and efficient.

I've read several good articles on the topic of SoS, but most focus on technical integration between the Scrum teams via the SoS. What about reporting non-technical issues and status during the SoS?

Specifically, the project managers are not technical (and neither is the program manager). How detailed should the (non-technical) report be in the SoS and how can we keep this short and efficient?

Improve this question
5
  • @Balinjdl, Welcome to PMSE. This could be a better fit for the main site. But it still needs refinement. As it currently is written, it's a polling question. To make it a better fit (and to get better feedback), what is the specific challenge you are trying to address? Would it be accurate to rephrase your question as how to keep a SoS short and efficient given that reporting on non-technical issues can take a long time to cover in a meeting?
    – Mark Phillips
    Commented Jan 21, 2013 at 22:30
  • @MarkPhillips Yes, that would be accurate. I'm primarily interested in the non-technical side of the SoS, since the project managers are not (in this example) technical. Thanks for the suggestion and the welcome!
    – balinjdl
    Commented Jan 22, 2013 at 3:02
  • Hi balinjdl, I edited to eliminate the poll and focus on the suggestions from Mark. Please feel free to edit further if my edits miss the spirit of your question. :) Hope this helps!
    – jmort253
    Commented Jan 22, 2013 at 4:48
  • In reflecting on the question, one item that comes to mind is what (if anything) should be recorded during the meeting as "meeting minutes"? Do I record the completed, planned, and impediment info, just the impediment info, or some subset for each meeting? Or do I not record anything (though having a written record would be helpful for the attendees)? Should I create a new question or should I re-work the existing question to spell this out more clearly?
    – balinjdl
    Commented Jan 23, 2013 at 13:26
  • @balinjdl You've already got several sub-questions going in this one. I think your questions about meeting artificts should definitely be separate.
    – Todd A. Jacobs ♦
    Commented Jan 23, 2013 at 16:43

3 Answers 3

Reset to default
2

How to keep them short: Don't disseminating status or solving technical problems. Do that after.

With 60 people in your Scrum Teams you would likely have between 7 and 10 Teams that all meet individually. It would be impossible for your two Project Managers to attend all of the Daily Scrums and you should trust the Development Teams to bring the relevant information to your attention after the meeting.

Daily Scrum - The purpose of this meeting is for the Development Team (3-9 people) to get together and understand what they still have left to do and to update their plan. There is really no requirement for a Project Manager to attend the Daily Scrum except as an observer and any information that the Development Team thinks needs to come to the attention of either the Scrum Master or the Product Owner is up to them.

Scrum of Scrums - Each Development Team should elect a representative to attend the Scrum of Scrums to allow the same information to be passed between the Development Teams so that they can minimise dependencies and make sure that all of the Development Teams have all of their work integrated and tested by the end of the Sprint. Again this is about the Development Teams themselves and not about Project Management.

That all said, you can have as many other meeting that you like about whatever you like outside of those two specific instances.

Improve this answer
4

The thing is that the Scrum meeting shouldn't be technical. There is a meeting called Community of Practice (CoP) and that meeting is for the Scrum Teams to talk about technical problems. So if you can keep the technical discussions out of the Scrum or Scrum-of-Scrums, your managers will be just fine. It is up to the Scrum Master and how he mentors others doing these meetings.

In the organization (>500) of a friend of mine, they have a weekly SoS for organisational issues, and a CoP for technical ones. They are very happy about this setup, because it works for them. Managers go to the SoS, tech leads go to the CoP. Product Owners go to both.

Improve this answer
1
3

Don't Give Reports During Scrum-of-Scrums

Your question has a great title that already contains the seeds of your answer, but I think the body of your question obfuscates the issue. You ask (emphasis mine):

How to keep a Scrum of Scrums meeting short and efficient given that reporting on non-technical issues can take a long time?

You are exactly correct: reporting (technical or otherwise) can be a big time-sink, and reporting upstream is not the intent of an agile meeting. That isn't to say that agile practices are antithetical to reporting per se, but that agile frameworks like Scrum aim to make project status easily visible to any interested party through artifacts like burn-down charts, product and sprint backlogs, and team-managed processes such as Kanban-style storyboards.

The Scrum-of-Scrums is a dependency-coordination meeting between teams. If someone is pulling or pushing status (yes, pushing; I've seen this done) during the meeting, the process is being applied incorrectly.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.