What are the ways for Daily status reporting to make process more easy?

Question

We are currently facing issue for the Daily standup reporting.

We are more than 70 people in the team, and some people are working at client side location as well. So in daily scrum meeting it takes more than 1 hour to just give and take updates.

So for the solution we decided, Only lead will attend meetings and give status reports for the individuals

Now the current issue is, we have no centralized system or tool or way for each person to report to their respective TL in simple way.

Note : We are currently using the mail system but it is very tedious and time taking.

Can anyone suggest a better way to solve this problem and save more time ?

Answer 1

The value of the daily scrum is for people working closely together to sync up on their short-term plan. My first recommendation would be to allow portions of your team working together to organize their own daily scrum where it is helpful.

If you are just tracking progress, I'd look to artifacts that show work progress like taskboards. This way teams, PM's, managers, and so on can all see where any work item stands without bothering anyone.

Answer 2

Our low-tech solution to this has been using a wiki. If the version control tool you are using has an integrated wiki, like Trac or GitHub, you can use that; otherwise you can use a standalone wiki like Confluence.

Set up a parent page for the project; set up a page for each team underneath that. On the team page, put a few instructions on the top explaining that each individual is responsible for updating their status every day by X time, and set up a standard layout, maybe with example dummy text.

My teams have always found this pretty painless.

...

Of course, the meta-question is why are you using the daily standup for status reports. Classically it's not for status, precisely because the team and leads should be able to see status on the wiki, or sprint board, or other tool... which may become obvious once you start using such a tool for status. The classic standup is to identify any blockers, areas that need coordination, etc.

Also, with a team of 70 people that is already composed of subteams, you might want to look for answers on "Scrum of Scrums".

Answer 3

This sounds more like roll call in the army than a daily scrum meeting. You might not be holding your meeting for the right reasons.

The daily scrum is not there to report progress to managers/stakeholders/etc. It's purpose is to sync the team and provide a fallback opportunity to report impedements. As such a daily scrum should be limited to a group of people who's work directly relates to one another.

70 people is way too much. If that's the size of your scrum team look into ways to divide the teams and work into multiple subunits like "Scrum of Scrums" or the Nexus Scrum Framework.

If it's that important to report progress to outside elements on a daily basis consider creating a software scrum board that you update during daily in parallel by multiple smaller teams.

Answer 4

I would suggest using TaskQue. It will help you in getting rid of unuseful meetings by various features.Below are few features of TaskQue:

Discussions: You can create virtual discussions in real time to communicate with your teammates. You don't need to waste time in meetings all the time.

It can help you in optimizing your reporting process. In this system, there is a concept of Tasks, Project, and Workspaces.

WorkSpace:

Workspaces are a collection of projects whereas

Project:

Project is a collection of tasks.

Moreover, it gives a better idea about the team performance through summaries.

Summary: Project SummaryThere are two types of summaries here. First is Workspace Summary and the second one is project summary.Project summary is a visual tool which gives you an idea about the overall performance of the team as well as projects.

Comments: You can add comments below every task. Comments are meant to give your replies and instructions.

Answer 5

You may want to consider doing a "Scrum of Scrums" approach. Smaller groups, limited to 10-15 people max should do their own scrums. Very likely these divisions will fall along module or component lines. Then, you may want to have some sort of "Scrum of Scrums" with only the leads 3 times a week, or some frequency that makes sense for the flow of your team.