Back in my early days as a project manager, at first I was mainly working on waterfall type projects. It didn’t take long until I was asked to bring on a virtual remote team for agile software development. I was told I would need to continue creating a project plan that was baselined, and that it had to have all the normal metrics as before. This was no easy task, as I soon found out that in agile development, it is more about developing earlier on and understanding that requirements change frequently. This was opposed to the heavier up front planning and holding to set schedules that I was use to.
With the teams moving towards agile development, I realized the traditional baselined project plan that my upper management was requiring of me wouldn’t be ideal moving forward. This led me to looking into better ways to maintain reports for how my team was doing in agile development. After researching the reporting options further, I learned that I could break up the portion the team would be doing into high level amounts of work we wanted the team to perform over the span of several two-week sprints. Then, I baselined each estimated sprint separately from the next as it was assumed it would not be exactly as planned. This was easy enough to convince my manager to let me try out, but I still had my doubts that this would be an ideal reporting format. Along with keeping each sprint baselined, I was asked to keep all the dependencies in line, as well as all the other metrics one could think of in the project plan. Some of the requested metrics were earned value (EVM), schedule performance index (SPI), and cost performance index (CPI). With my project plan, I was instructed that the planning portion was to be done up front, and once the work was to be done then the team could start developing the product in sprints or iterations. Then after the development was complete, I was instructed that then it entered into the deployment and release phase.
Also per my manager, the planning stages with stakeholders and product owners had to be baselined as well separately. This wasn’t too bad to maintain for one project and one team, but once we started working with several projects at the same time this was getting hard to keep accurate due to all the re-baselines within each project plan. This was still doable, but I started to notice it didn’t seem to be the most practical or realistic approach to reporting for customers and stakeholders, let alone for the team to look at for their own awareness. The stakeholders and end users didn’t even seem to care about these project plans, or think they provided much value. As a project manager, this approach didn’t really seem to help me much either. That said, every situation can vary from the next. If the project manager does find this useful, that’s fine, as long they don’t force this upon the scrum team but instead use it more for their own reference.
Once I started to play the role of scrum master for the dev teams abroad, I soon started have a more realistic approach for how metrics are maintained for agile development teams. Also, I started to look closer at the plan, analyze, develop, and release stages to see if it was truly agile, or simply waterfall with the agile label. Yes, it had the iteration portion covered, but I wondered if the plan and analyze phase had to be so big and up front and separate from the iterations with the development. Same for the deployment and release phase, I continued to ask myself if this was truly agile. Don’t get me wrong, we did leave areas for continuous feedback from the customers, but it just seemed to lean more towards over planning up front. This also seemed to be the case for the release portion, just seemed to be more at the end of a long period, instead of frequently at the end of each iteration. At last, we were given updated and official training where I became internally certified as an Scrum Project Manager. This further opened my eyes to how project managers fit in with agile development. I learned that the role of project manager is very different from that of a scrum master. Also, I learned that the project manager’s involvement should be very high level when it comes to planning and forecasting timelines of the work the scrum teams were doing. The project manager can work with the scrum master to get agile metrics from the scrum team (e.g velocity and burn down reports) to help with forecasting estimations of when certain work might be done. Using the team’s velocity, the scrum master can look at the backlog and help the project manager forecast what might get done in future sprints for timeline estimation. The comparison between project manager and scrum master is a growing topic, as they are very different but some companies fail when trying to combine them into the same role. I see the value of project managers working with agile teams, when done right. For more on this growing topic, check out some links I’ve provided below: