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.
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.
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