This is the fourth post in a series of blog entries on how to begin establishing your agile teams in an environment that is predominately still waterfall. Posts in the series include:
Integrating into your PMO's status reporting
Over the longer term the ideal here is to change how statusing is done on your agile teams. Until that is in place you will probably need to comply with the same standards as the waterfall teams. If you have a PM assigned to your agile team this is a great way for them to help keep the team performing by keeping the complexity of status reporting out of their way. The PM would use resources already available from the agile team (e.g., Product Roadmap / Backlog, Sprint Plans, discussions during daily stand-ups) to craft the status report. The goal should be to not ask the team to do any other work for the status report beyond what they are already doing in their agile processes.
A certain amount of adjusting will need to be made if your status reports track things that just don't exist in an agile environment. For example, if your status reports break down into traditional waterfall phases (Analysis, Design, Development, UAT, etc) these phases won't apply to your agile teams. You will also need to decide what to consider a 'project.' How you decide to do status reporting depends on how the team is funded and the nature of the work the team is doing. Consider the following 3 options for statusing an agile team:
- Status for each Sprint
In its simplest form you could consider each sprint as its own project. The status report would report on the health of the sprint, and could include information from the sprint review as part of the project wrap-up. The decision to report this way will depend on how often you report status and the length of your sprint. If you report weekly and you have a 4 week sprint length this approach would be meaningful. On the other hand if you report monthly and have a 2 week sprint, you could not use this approach, as you would be reporting on sprints that started and finished before any status report was done.
- Status for each Feature
If you plan sprints around larger epics or features you could report status for each feature being worked on. Typically a feature is worked on over many sprints. You could treat each sprint that a feature is being worked on as a phase of development for that sprint. You would report on the work completed for a feature in that sprint and could even project completion dates based on the team’s velocity for that feature.
- Status for each Release
If you are releasing with each sprint but plan major releases as features are completed you could do status reporting at the release level. You would plan multiple sprints into a major release and multiple features to be completed in that set of sprints. Each sprint would still be considered a phase of the overall release. At the end of each sprint you would show overall progress towards the completion of the major features planned for the release as well as any other work completed in that sprint.
Migrating away from Status Reporting
Of course, agile (specifically scrum) already has a mechanism in place to demonstrate progress and solicit stakeholder feedback on the work completed in a sprint, the Sprint Review. If possible look in to moving away from delivering status reports and instead inviting the people who normally receive status reports to attend the Sprint Review at the end of each sprint. You can ease in to this transition by first inviting the team to do a mini-sprint review in the status meeting to introduce stakeholders to the concept. Once they are comfortable with the review invite them to join the full Sprint Review. At that point you can discuss the need for an actual status report as opposed to them just attending the Sprint Review.
If there are other processes you’d like to see addressed in these posts, please leave suggestions in the comments.