What's wrong with a status pull?

Question

This morning my manager was trying to reschedule the weekly synch; I pointed out that it was a status pull and might not be worth the effort to reschedule. Manager replied that it was convenient.

Obviously status pull is always convenient for the manager. Obviously it is inconvenient (and formally "waste" ) for everyone else in the meeting. But is there any documented reason, formal theory or other grounds for why status pulls are bad? (Quick google search yielded scan results, most of which are about git pulls.)

We work for the manager, so if it is convenient for the manager, it is obviously good, even if it is bad for the organization. But if I were inclined to try to persuade the manager that we should pursue an option that is good for the organization, even if slightly less convenient for the manager, what are the grounds for that argument?

D. Espina points out an unstated assumption:

Status pull: A meeting in which subordinates in turn report status to their manager. During this time no work is accomplished; all staff are pulled from productive activities to passively listening to their manager absorb status information.

Monitoring work is vital; performing oversight has been the majority of my career. But work and status can be monitored through review of artifacts, through previously agreed on KPI, through written submission of status information, through 1:1 meetings, etc. Status pull refers only to the meeting where an entire team listens passively sits and listens while one active person tells the manager a story.

(Implicit in the question is, "What is a superior alternative to a status pull?")

(We're not agile, scrum is merely the name we give to the lipstick we spread on the pig. We love to use the vocabulary of scrum, but recoil in horror from the notion that teams could do anything other than what the manager directs.)

(While I was submitting the question, manager replied that status pulls are directed as mandatory by their management, no discretion. But I'd still like to know if there is a researched/well reasoned case that could be made in an alternate reality where the enterprise cared about actually getting things done rather than micromanagement)

Answer 1

TL;DR: Reporting status is not bad; wasting people's time to get information that should be readily available is bad.

---

In a team where collaboration and transparency are nurtured, the status of each work item should be available for anyone, anytime. If a manager needs to report the status of the work, there should be means for the team to provide it in an asynchronous, effortless way.

Expecting that a team can work autonomously with zero transparency and no reporting makes no sense (under normal circumstances).

With that said, assuming the team is using any digital Kanban / Scrum board, most (if not all) questions about progress status could be observed there. One would just need to extract if from there.

Granted, it's easier to ask people directly rather than understanding how the team organises its work. But it'd be a one-off investment from the manager that'd pay off pretty fast:

• the team would only need to keep updating the Kanban / Scrum board (and needless to say this board should be useful for the team);
• the manager could have not a daily update, but a real time update on whatever he wants to know!

What is in progress? How long are we taking to deliver something? How's our trending going? Are we going to make it to this sprint? All these questions are answered there already. No team's time required (beyond the minutes updating the board itself).

Answer 2

I am not sure how one would even structure a research study to test your hypothesis. Reports always benefit those who are consuming the information, not those who are providing it. And the time and whatever other resources are necessary to provide those reports should have been allocated so stopping work to provide those reports should not interfere with "getting the work done." If it does, then the schedules and budgets were poorly planned and that should get fixed.

Without status reports, how do you monitor the work?

EDIT: @Tiago made a great point regarding more efficient ways to capture status. I agree with his sentiment, that it becomes inefficient to gather verbal reports when the same data are available through other channels. So if data are only being repeated from what is clearly visible using other, more elegant ways, then the redundancy and waste are clearly visible and should be easily argued. However, there needs to be the opportunity for those consuming information to be able to "dig deeper" on the data that do not clearly exhibit cause or contributing drivers or new risks or whatever else consumers of information need to truly understand what is going on so that they can articulate to their stakeholders and make decisions at their level. In my personal experience, I have never seen such a dashboard or scorecard that did not require or that did not cause more questions and concerns and additional analytics. That doesn't mean those elegant reporting capabilities are not out there; I just never had the luxury of experiencing it. So I always plan for and allow time and money for status pulls and I endeavor to make them as seamless and efficient as I can. But I am confident that those providing the status still find it a waste of time.

Answer 3

A "Status Pull" Primarily Solves for Poor Visibility

Obviously [a] status pull is always convenient for the manager. Obviously it is inconvenient (and formally "waste") for everyone else in the meeting.

Neither of these things is intrinsically true. However, the way traditional status pulls are structured is often problematic because it's generally inefficient. For example, a single hour-long status pull with 20 people where each reports status for 5 minutes consumes 20 person hours. That's a lot of time and money spent in the aggregate, and it's even worse if 55 minutes of each such hour provides no value for 18/20 people in the meeting.

Now multiply that time by the number of such routine status pulls. If you do even one such status pull a week, that's 80-100 person hours consumed each calendar month. That's a very large cost center with arguably limited value for both the participants, the organization, and the project's financial sponsor.

In project management, agile or not, an information radiator allows those with a vested interest in the status, artifacts, or data from the project can easily access them without involving unrelated or disinterested third parties. While good information radiation is a common component of most agile frameworks (think kanban cards and boards, Sprint Backlogs, burn-down charts, cumulative flow diagrams, etc.) good project managers in more traditional frameworks often leverage the concept of more-efficient communications plans in their status gathering and reporting as well.

In general, if status pulls are not simply a defect in the organizational culture, they are most likely being used as a solution for poor visibility into or within the project. Rethinking how the project tracks progress and communicates about the project, both internally and to external stakeholders, often leads to more efficient solutions than a traditional status pull.