olly - Fotolia

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

Dig Deeper on Enterprise application development, DevOps and software agility

Join the conversation


Send me notifications when other members comment.

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?
Hey Sorry. I haven't been getting notifications on these. 
NO. Read the article. 
I am talking about in larger organizations. Small ones sure. but larger ones, NO! Status (Progress or problems) must be PROACTIVELY communicated by the teams.  
When I hear agile coaches tell manger's to stop asking for status... it pisses me off.  managers/project managers shouldn't HAVE to ask for status. Teams should be SHOVING status at them. Larger companies need more types of communication. Michael Wolf (see his comment below) shared a great analogy with me earlier this week. 
Did you know that grasshoppers don't have lungs? They don't need them. But horses do. With a grasshopper nothing is more than a few cells away from the surface, they get all the oxygen they need through their skin. But with a horse needs lungs, esophagus, alveoli, etc... because they are larger and need different organs to run well.  
I totally agree that managers should not ask for status...because teams should actively be providing it to them in a form that they can use.  
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?
Yes, but at scale, they cannot. someone needs to realize that it is in the best interest of the team to provide these people, who have the ability and responsibility, to help with the information they need int order to do that. 
I find that most good leaders actually want to help their teams. They just need to know how they can help. If the teams aren't telling them then they get nervous and start asking for "status".  Push status at them and tell them what you want them to do! 
"Hey We are having trouble with XYZ can you do ABC for us?"
"Hey we are having trouble with XYZ, but we've got it under control. We don't need any help just yet. "
Believe it or not executives are humans. They are trying to do their best with the information they have. If they don't have the information. They will ask for it. As well they should
Joseph - I'm with you. If development is being done for commercial purposes (internal or external) there are time and financial considerations that come into play. Agile (SCRUM) evangelists abhor any reporting that falls outside of the prescribed artifact updates because it exposes the initiative to the hard reality that "we'll finish when we're done" is not an acceptable answer to the question of "where are we?". With respect to burndown/up charts - these are subject to the same issue LOC or any estimation method is bound by - it's a guess.

While the idealized notion of rapidly creating software with a high-performing, self-forming, self-sufficient team working along side the dedicated, always available and all-powerful Product Owner, is enticing, my guess is the percentage of initiatives world-wide that have all these elements (along with the organizational backing required to support these roles) is incredibly small.

Which means that sooner or later, marketing, sales or finance will be looking for visibility ('status') that can answer the fundamental questions: will it cost what we budgeted, will it be finished when we need it?

Whether it will "do what we think it should", is a status question the Product Owner should be able to answer without hesitation whenever asked. As well, it should not be the team or the Scrum Master asking for help if they run into trouble. The PO is the voice of the customer and should know if help is needed and seek it out if results are not forthcoming or progress is at an unacceptable rate.

@CCasey, Agreed. The number of people actually forming agile organizations is really small.  Many are content to add some agile practices to their existing organization (culture and leadership) and call it good. 
The truth is they often do receive benefit in the order of 10-25% improvement in effectiveness. But they will never see the 200-400% improvements that are possible when you really change the whole organization, culture, and leadership. 
Being agile is a fundamentally different way of conceiving work. It is not some development practices.  
I did this CIOMinute video about how agility fully implemented affects the whole organization.