On Project Management

I hear about Agile sometimes from co-workers, spoken either with reverence or absolute disgust. And no discussion on Agile is complete without a rant on its cornerstone: scrums.

I thought I’d mention here the only project that I ever worked on where any sort of project management technique that was deployed actually worked.

I once worked as a team lead on a project (in a different company) that had over-run its costs and was on the verge of cancellation because the PM (who was also the scrum master) gave us the wrong requirements document. (dramatic pause)

The CEO came over to me and asked me to take over, what with us now not having a PM till they could hire another. I used this opportunity to push for a change to our scrum process, which I felt was not working (though it had nothing to with the aforementioned derailment) and asked him to give me leeway to follow a different process.

Cut to 3 months down the line, we managed to wrap up the project. Here were the changes we initiated:

• Standup meetings sucked because everyone wanted to talk about minutiae in their stories, and consult with others on technical issues they were grappling with. We cut it down to each dev reporting one thing and one thing only: was the story he was working on proceeding as expected. If it wasn’t, what was the new ETA of the story? Devs could say: “Gosh, I have no idea now that this bottleneck is stymying me”. I’d enter a large number in the num days left column of that story and move on. I’d revisit them as described in below.
• Previously, devs were expected to update their own story estimates every day on an online tool. This didn’t happen. Also, devs didn’t want to look like they were taking “too long” for something, so they’d estimate optimistically and overshoot. Instead, I used my discretion and updated all the story estimates in a Microsoft Project doc myself every day. When a junior dev said it would take him 8 hours more, I’d tell him: “let’s just make it 16 hours more to be safe”. The key change was: I did the timeline updates for all team members by myself and did it religiously.
• This resulted in a system where I would send the Project docs to the CEO every Friday. Now the CEO could clearly see possible problem areas of over-run as soon as they occurred. This thus enabled both him and me to respond to them quickly: either assign more resources to our team for short durations or rejig more problematic stories to the most senior devs.

The biggest lesson I learned in the process was that managers/execs don’t all necessarily want to keep breathing down your neck, or make you run faster than you want to. They just want to be told as soon as problems occur rather than letting delays build. Usually, once they knew what the issues were, they were very helpful. It was also a virtuous cycle: the execs now trusted the team’s ability to execute, and the team, in turn, felt more confident to turn to the execs for help when there were bottlenecks.

I also learnt that Microsoft Project is a planner’s best friend. Not so much the Gantt chart but the timeline view.