CHAPTER 15: REPORTING ON AGILE PROJECTS
Monitoring the business value and progress of the Agile work in your department can begin from the moment each project starts, and continue well before the whole-of-life business value of the overall initiative is evident.
As described in Chapter 10: Using Agile Tools and Chapter 11: Measuring Agile Success, Agile approaches provide a number of mechanisms for tracking progress, which include formal reports (e.g. executive dashboards), status update tools (e.g. WIP boards and product backlogs), and ongoing communication with stakeholders. Arguably, however, the most valuable measure of the Agile team’s progress is their delivery of tangible outputs. For iterative Agile methodologies, such as Scrum and FDD™, the presentation of working software occurs at the end of each iteration. This means that, at fixed timeframes (generally once a month), you are able to see firsthand whether these approaches are delivering their agreed outcomes (i.e. business value).
Equally important, the project teams themselves are able to use these Agile tools to monitor their own progress during each iteration, and to adjust their ongoing work as needed to meet their agreed commitments.
This positions Agile reporting as an intrinsic tool that enables staff to monitor and self-manage their work – identifying and addressing issues that impede their progress – not an added overhead that distracts them from delivering value to the organization.
The ideal Agile reporting environment would leverage the tools described in Chapter 10: Using Agile Tools without asking staff to do extra (often redundant) work to meet corporate reporting requirements. Specifically, this would involve using:
• Executive dashboards to provide an overview of work completed and pending, budget utilization, resource utilization, and issues raised
• Backlogs, Kanban charts and other detailed progress tracking tools for where management requires further information
• Communication methods – other than paper reporting – to provide an update on work progress, such as participation in daily stand-up meetings and iterative review sessions.
This ideal model means that Agile teams could continue to use the reporting tools that are a standard (and natural) part of their Agile work; and that corporate reporting would not be a separate overhead for staff that takes them away from their core work.
Equally, in this ideal model, management would be satisfied with keeping track of work progress through executive dashboards, with access to backlogs, Kanban charts, etc. – and even attending daily stand-up meetings or iterative review sessions – where more detail is required.
Detailed staff time-tracking would be less of a focus for the department than tracking the productivity of staff members. Therefore, timesheets would not be required in this model, as detailed information about resource allocations and work would be continually available to management through the backlogs.
Even in an ideal model, however, it is reasonable to expect that some level of budget management – and, therefore, budget reporting – will be needed by the department. The Agile budgeting mechanisms described in Chapter 14: Budgeting for Agile Work would continue to provide the required levels of departmental budget tracking without creating unnecessary additional overheads for staff.
In most organizations, every department is required to provide consistent budget, resourcing, time tracking, work status, risks and issue details through a number of standard corporate reports. The IT department is no exception. Therefore, the following provides strategies for aligning your department’s Agile work with the mandatory corporate reporting structures in your organization.
Aligning Agile work with reporting cycles
The most efficient way to incorporate Agile work into your overall departmental reporting requirements is to align iterative work to correspond with your standard reporting cycles.
If your department is required to provide corporate reporting on a monthly basis (e.g. on the last business day of each month), then the four-week iterations within an Agile project could be timed to correspond with this. This means that Agile teams could use the presentation of working software at the end of each iteration to report on their progress, in conjunction with the standard reporting cycles for the organization overall. The completion of each iteration would also provide you with the corresponding details on resource and budget utilization for the previous month, along with an up-to-date summary of work delivered, the project status and any outstanding issues during that iteration. Note that this information can also be extracted across multiple iterations, but it would be more time-consuming to isolate information, such as partially completed functionality or temporary issues that are expected to be resolved at the next iterative review session.
If your department is required to provide corporate reporting on a quarterly basis (i.e. every 13 weeks), then you can align the outcomes from three cumulative four-week (or six cumulative two-week) iterations to correspond with this cycle, with the potential for staff to utilize the remaining week in each quarter to assist in reporting, undertake training, or do other required departmental work62.
Where the Agile work in your department is an ongoing process, annual reporting can be structured as the cumulative result of 12 four-week iterations within or across multiple projects. However, it is likely that you will need to combine the information gathered through Agile tools with the tracking tools used in the other traditional project work in your department to achieve this.
For departmental reporting that falls within iterations (e.g. weekly reporting or ad hoc reporting requests), the information tracked on a daily basis in the backlog tools – and rolled into the executive dashboard – should provide you with the detail that you need to calculate the metrics. This information will not be as readily encapsulated as the results from a completed iteration, but it is likely to provide far more detail than the half-completed timesheets and quickly drafted status update e-mails that tend to be used for ad hoc reporting in traditional project environments.
The budget-tracking measures identified in Chapter 14: Budgeting for Agile Work provide mechanisms for you to identify and track Agile project work against allocated budget dollars.
Executive dashboards and backlogs further allow you to identify the historical, current and planned utilization of resources on your Agile teams at any point in time. Where staff members are fully allocated to Agile work, these tools allow you to:
• Calculate the overall time that has been spent for each project across all resources
• Estimate the remaining resource time based on work allocated for subsequent iterations.
The irony is that most corporate budget reports focus exclusively on the amount of money expended by the project, not on the business value generated for that expenditure. With Agile tools, you actually have more information available for you to track your ROI than your organization is likely to require.
Resource and time tracking
If there is a standard time-tracking tool used by the organization, the members of the Agile team may have to do some redundant work to record their project work in the backlog, and then separately record their time in the corporate reporting tool. However, once there is a substantial enough commitment to Agile in your department (and a critical mass of your staff using these approaches), it may be valuable for you to consider having the team build an interface between your backlog tools and your time-tracking system, so that work on Agile projects is pre-populated into the timesheet. Staff may still need to supplement the pre-populated timesheet with the work done on traditional projects, other departmental work, corporate meetings, etc., but this should be minimal in comparison to separately recording all of their day-to-day work.
The more discretion that your department has to align Agile work with standard corporate reporting cycles, the easier it will be to allow the standard reporting tools used in Agile work to feed into your departmental reporting requirements.
It is important to note that Agile reporting tools gather most (if not all) of the detailed information needed as input into your departmental reporting. So, the challenge for you is not in getting staff to retrospectively fill in their timesheets, provide status updates on three-week-old work, or put together ad hoc estimates of their planned work; the challenge is in combining the more extensive detail from your Agile projects with the limited detail available from the traditional projects in your department.