Agile Software Development, Status Reports, Review Meetings: What to expect?

If you would have ever written a work order, you would have seen that there is a section for Project Governance and Communication. Every Template will have this in some form or other and its mandatory to fill this section. Typically what happens in a services company is that, someone writes a work order and someone else executes a project.

If the person who is going to execute the project doesn’t contribute to writing work order, then whatever is written in that document becomes meaningless to him/her (unless someone else has set is as a culture in the team and a new person takes over).

In most of the companies, there is some process group which will mandate the Project Managers to fill in the Status Report Templates and you know what happens.

No one reads the documents. Why? I can tell you from my experience that if you send a word document as an attachment no one will open it. Ok, people have seen this problem enough. So, there is this concept of on-line dashboards etc… and i am sure we all know how many people really look into it on a regular basis.

Why is this problem? When we all know the importance of reports (in atleast an offshore/onsite environment), why does it happen in this way?
a. It becomes as a ceremony.
b. Status reports contains too many Micro Details than what needs to be given.
c. My Product Owner/Contact Point knows exactly what we are doing. We interact daily.
After couple of weeks, people decide its ok to skip this. When a Project Manager doesn’t get any response/question for any of the status reports he/she has sent, the motivation factor goes down. Over the period, either the PM sends it as a formality or starts ignoring this.

How do we address this?
1. When you start a project agree upon the
a. Review period and who will be the members for the Review Period.
b. Expectations on the Status Reports (Cycle and Contents)
2. Typically the contents for the Status Report should be
a. Base Schedule, Cost, Scope
b. Where do we stand in terms of the above
c. What changes has been introduced (in terms of scope) since the last review.
d. Work Accomplished since last review (Talk about the features not tasks here).
e. Impact of the Changes in terms of Schedule, Cost and Scope.
f. Updated delivery date and cost
g. If you have defined Critical Success Factors of the Project, have an overview of how we are doing against each success factors.
h. Velocity Chart (Refer this article Are we there yet? from Johanna Rothman
3. Send the Status Report to all the stakeholders before the Review Meeting.
4. Do the Review Meeting only with this.
5. Make sure all your stakeholders are attending this meeting.. In typical engagements the senior management from both sides get involved for first few times and after that they will slowly move out. If you do not see the senior Management (from both sides) joining the call, please send a RED FLAG to everyone. Finally, someone is spending money for doing something and if they do not have time to see what has come out, it means that the Project is Not Important for them. Its better to stop it there than taking it forward and getting into a messy state.

In my opinion, plan this meeting once in 2 or 3 weeks. It will help you to show some progress from the last time and it will be easy for everyone to judge where we stand and whether there are any progress.

In offshore development, providing visibility is very important and provide the visibility to all the stakeholders as many ways as possible.

We are talking about Status Reporting. Why the title has Agile Software development?

Now you may say that, Boss we have moved to Agile Software Development long back. This is a very old story. You don’t seem to understand Agile. Why do we need all this in Agile?
True, I am not saying No. But what you have to understand is only your execution environment has changed to Agile (You, Your team and may be your Product Owner and Architect on the other side). The remaining people has not even understood what agile means. For them, all that matters is Money. The Rest goes in the backseat. Business is not done with TRUST/HEART. Its done with Brain and Money becomes the most important thing.

Other thing i keep hearing is boss, we do not know what we want. Thats why we do agile development. We may not be able to define the base scope, schedule and cost If you are into such thing, for god’s sake please stop the work immediately there.

In an offshore setup, you will never know when a project becomes into RED. Its not always the delivery which causes a project to goto RED. There could be n number of reasons. But, believe me. Irrespective of all, the default thing to be blamed is delivery.

Apart from helping the customer to get business value, its the responsibility of the Project Manager to protect his team, himself, his company and his contact person (product owner or Vice President or Architect… whoever it is) on the other side.

Learn this lesson and you will have better life as a Manager.

As a manager, one of the most important goal one should have is to reach a smooth end to every project.

Happy Learning !!!