Manage Learn to apply best practices and optimize your operations.

Agile organizations still need project status reports

A worrisome trend is emerging as more organizations adopt agile practices -- disavowal of project status reports.

A senior vice president at a 2000-person software company was talking to me about her frustration with the firm's...

agile development team and its dim view of project status reports.

"How am I supposed to run a company when every time I ask for an update people tell me that I am being too pushy? They say, 'Just trust that we will do it.'

"How can I trust them if I don't know what they are doing?"   

Later I was talking with a CEO at a growing software company. His lament?

"Half my sales team wants to kill my product development team because they won't give them any kind of roadmap. The development team says, 'We are agile and we can't give you dates.'"

As more and more organizations adopt agile practices, such complaints about the lack of project status reports are becoming common. But agile practices -- generally understood to mean software development that is done in increments, tested often, delivered in bits and adjusted as necessary -- do not prohibit project status reports. Why is this happening?

Root of the problem

For many years IT leaders have asked development teams -- agile or otherwise -- to update them on the status of projects, information that they then would often use against their teams to push them harder. Teams, however, quickly learn to report only good news. Bad news gets obfuscated until it is urgent. Thus the common green, green, green, RED!! pattern of so many projects. I have seen it for decades.

Far too often agile development teams and contributors want the ownership of the work but don't want the responsibility of reporting on the work.

How the tables have turned! Agile coaches are now telling their managers to stop asking them for project status reports.

As an agile coach and expert of many years, I have serious problems with this perspective and I think it is much more damaging than it appears.

The refusal by agile teams to provide project status reports shows a fundamental disrespect for the work that managers and leaders do.

Managers, to be sure, need teams and individual contributors or there would be no product or service to provide to the customers.

Teams and individual contributors also need managers because, as an organization scales, it becomes impossible for every person to know what every other person is doing. Management is responsible for aggregating and disseminating information.

Teams and contributors are responsible for creating and maintaining. Managers provide vision and guardrails.

In small organizations it is advisable that managers attend the meetings and events where the agile teams and contributors are discussing the status of the work. Firsthand knowledge is always better than reading project status reports.

Unfortunately, managers can't be everywhere. At scale, some sort of reporting is necessary -- and even more necessary when directors, vice presidents and C-suite leaders need to be kept in the loop. These people are all responsible for steering the high-level direction of the organization. They need to know what is happening. They need project status reports.

Proactive project status reports

It's not hard to see where the pushback is coming from. In the traditional manager/ team relationship, the manager demands information about the status of the project. Not much context for why is given and, as noted, the information obtained is often used against the team to apply more pressure to get more done, or to find blame for why things aren't done.

Under this scenario, these no-status-report agile coaches are partially right. If team members and contributors are going to actually have ownership of their work, managers should stop demanding to know the status of the work. 

But -- and here is the crux of the matter -- teams should be providing information proactively.

As I advised the two executives cited above, if you want this to happen in your organization you need to find mutual respect. Managers need to have deep respect for the work done by the teams and contributors while teams and contributors need to have just as deep of a respect for the work done by managers. It is this second part that is missing in the message from agile coaching.  

How to get there

Managers, you need to redefine project status. Respectfully explain to your teams and individual contributors why you need the information, what decisions it will influence, and how the information will be used. Maybe the teams and contributors will come up with a new and creative way of providing that information.

Teams, you need to redefine ownership of the work. Far too often agile development teams and contributors want the ownership of the work but don't want the responsibility of reporting on the work.

Managers need teams and contributors and the latter need managers. Learn to respect each other and honor the work that you each do.

About the author:
Joseph Flahiff is an internationally recognized leadership and organizational agility expert at 
Whitewater Projects, Inc. He has worked with Fortune 50 and Fortune 500 companies, government agencies, start-ups and publicly traded firms, where he has been lauded by executives as an experienced, pragmatic and innovative adviser. He is the author of Being Agile in a Waterfall World: A practical guide for complex organizations.

Next Steps

Recent columns by Flahiff:

How to scale a business

Delegator or talent-stifling micromanager: What kind of leader are you?

Eight tips for optimizing your distributed team

Organizational agility: Destruction, then rebirth

This was last published in August 2016

Dig Deeper on Enterprise application development, DevOps and software agility



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Why are agile development teams balking at giving project status reports?
If product managers and sales team are not given access to the product being developed then it's a really weird version of agile. To an extent that it's not agile, I'd say :)
Since most “agile” implementations are a modified version of scrum or kanban, isn’t project status communicated at the stand-up meeting, the sprint retrospective, or on the team board?
Mike, you pointed to something I was about to highlight -- many ceremonies do, in fact, report status, often in forms other than a status report. But the audience is limited to "Team Members" (in the strictest use of the Scrum term). As Joseph points out, "At scale, some [other] sort of reporting is necessary".

One way to motivate wider status reporting is to acknowledge that there are many levels of "team" or "team member", and that feedback loops are fundamental to all Agile practices.

Another way to motivate this other sort of reporting is to have the product development team realize how much status reporting happens in their normal work flow (e.g. casual communications, daily stand-up, sprint retrospective, pair-wise work, issue tracking systems) and to ask them how they could coordinate the work without this status information.  They would soon realize that status reporting (not just a status report) is crucial to their work, and, by inference to the work of (extended) team members.

So much for status reporting and status reports.  Now on to status meetings.  Ugh...

Highly productive teams have realized that status *meetings* are an inefficient mechanism for status *reporting*, and have created "information radiators" and "interaction patterns" that get the right information to the right people without dragging the whole team into interactions that neither require their input nor their attention.  Status meetings -- boring!!!  It's like taking attendance in grade school -- the information is only intersting to someone outside the classroom.

Agile is so loosely applied label. Some teams may refrain from "project status report" others have sophisticated tracking and accurate burndown charts.
Agreed AlbertGareev. 
Burndown or burn up charts are useful. However, at scale these tools benefit from a narrative that describes the story surrounding the data.  
Shouldn't the managers and sales team be included in planning and coordination meeting to gather insight into status and progress?