Is Scrum based on 'daily reporting'?

Question

Google translates '早请示晚汇报' as 'Consult early and late reporting' or 'Ask for instructions to report back later'. Bing translates as 'Early and late reporting'.

Some translated content:

The politics invaded all aspects of daily life during the Cultural Revolution, as 早请示晚汇报. Every day at a political activity or ceremony, everyone, after getting up or reported to work/study, had to "consult the great leader Chairman Mao," about that day's work, study. At the end of the day/before going to bed, everyone had to confess to the "Great Leader Chairman Mao," that day's work/learning. Late reporting is called "confessing his/her sin," because a day's work or study certainly would contain errors, which delayed revolutionary work; hence, the person would confess, "I am sorry, great leader", akin to "confessing his/her sin." However, as "confessing one's sin," has a serious religious undertone to it, so it was not considered appropriate and was renamed to "late reporting." Anywhere people gathered--schools, army, cadre schools, community centers that provided three meals per day--everyone involved had to appear for the collective report.

Here is another excerpt that sounds beautiful even after machine translation:

Anyway, several times a day for several years removed from the "instructions", "reporting" so that "life" of this short period of time is finally free of political control winding all the time, everyone has a sense of relief.

Ref: Lin Zhao, a blog entry, a news paper article

I feel compelled to be certain that this practice is definitely the source of 'Scrum' process. Some of these similarities cannot simply be ruled out as coincidences. My question is,
"Is there really a relation? If so, should we read some mission statements before we begin work, and we have stand-ups at the end of the day, before we leave?"

Answer 1

A really important point is that the daily stand-up isn't about the team members reporting to the Scrum Master, but about checking in with each other. As a matter of fact, one of the tricks about being a Scrum Master is to find ways to avoid having the team report to you.

The role of the Scrum Master is to make sure that the rules are followed. So as far as daily Scrums are concerned, the Scrum Master's only real function is to make sure that they are held each day. He doesn't even have to attend himself.

Technically, the Scrum Master's other role is to clear impediments that are revealed during the stand-up. Personally, I'd prefer that the Team looked at each impediment and figured out for themselves what they want done about it. That may indeed involve the SM doing something to clear the impediment, but only if that's the way the TE

Answer 2

First, let's not confuse Scrum and Agile. Scrum is an Agile process, but it does not equate to Agile. What you're describing is Scrum.

Whether Scrum is based on the daily reporting that you describe is open for debate. I would not be surprised if there is an evolutionary chain of techniques from one to the other, but Scrum is not based on a system of subjugation.

Scrum is significantly different from "daily reporting" in that you are not reporting daily to be monitored or punished if you have made mistakes, you are reporting because if you don't then the average developer's tendency is to not ask for help when he's in trouble.

Without Scrum, something which appeared should have taken one day will sometimes flow over because the developer's knowledge base is lacking. But he is determined to fix it himself. Often, it transpires that developers will wait 3-4 days and then, realising that they should have asked for help earlier, will allow that problem to drag on for as long as it takes. I'll be honest, I've been there.

In those cases, standups would have identified that after one day, when something promised is not delivered and another developer can say "I can help with that."

There are many other blockers to a developer's work, other than lack of knowledge. Those things can lead the same way. The idea of Scrum is to have someone removing those blocks without humiliating the developer who hit them.

Going back to your daily reporting, that was quite the opposite approach. That was to force people to work harder by knowing that, if they didn't, they'd get in trouble that night. And to top it off, they didn't even get to make their own estimates, so a supervisor could set whatever expectations they wanted.

None of this relates to Scrum.

To answer your final question, I think the difference between reporting at the start of every day and reporting twice a day sums up that psychological difference. There is trust that you've done your best. Go home and sleep, come back and tell us about how things are progressing in the morning.

Answer 3

Perhaps. If the purpose is to beat down developers, then a 'stand-up' probably isn't a good idea. If the purpose instead is to make sure everyone has the same picture of project state then there might be some merit.

Answer 4

If you do Scrum correctly you do reporting all day. You have your Scrum board and everybody can come and see your current status = anybody can see what is done, what is in progress and what is pending due to impediment. Scrum board should also contain burndown chart so anybody can also see how is your progress changing and the trend.

If you use cards with different colour you can also immediately show what are common tasks, what are infrastructure tasks, bugs, etc.

The important point is that everybody can see that but during the sprint there should be no changes or complaints about team's performance. Sprint is team's safe zone and team members are empowered to make their own commitment to amount of features delivered during the sprint. They know the best how many features they are able to deliver.

You also have stand-ups where anybody can come and listen how team members answers three questions every day:

• What did I do yesterday?
• What will I do today?
• What impediments I have?

Important is that everybody can come and listen but only team members are allowed to speak. If anybody outside of the team interrupts the meeting Scrum master should ask him to leave. Scrum master's responsibility is also solving impediments as fast as possible or escalate them. Time for stand-up is team decision but it should be always in the same time.

If you have electronic system for tracking tasks / user stories you can probably also have virtual scrum board and email subscriptions for burndown charts so anybody involved in the project can check it from his computer.

You have short sprints (2 weeks on average) and review meeting after each spring where anybody can come and see new features in the product.

Scrum as many other agile methodologies provide continuous reporting and transparency without bureaucracy you can see in many companies.

Edit:

There are some additional things which can be considered as "reporting" but they are not prescribed by general Scrum process - they are simply addition considered as useful = continuous improvement.

One such feature is description of risks. During retrospective meeting every team member will get a big list of paper and he write or draw anything he consider as a risk for the project or the next sprint. These pictures should be stuck on a wall in the office so anybody can come and see risks found by the team. Also team will have these risks always visible so they don't forget about them - Product owner can define new user stories based on found risks. After the sprint team can remove solved or obsolete risks and add new papers with new risks.

Answer 5

We all know that the Daily Scrum is more than just reporting. Even reporting isn't exactly the right word to use here. id rather use communicating, even just one at a time. The daily scrum is the most important task of the day as to get everyone in the loop of what happened, what will happen and how did it happen.

It gives everyone a chance to know who to help, who to direct questions to in case something breaks and needs fixing especially if there's an issue that requires the overlap of two or more developers and in turn everyone gets the whole overview of the goals of a given sprint.