This is the second in a series of articles that will give you strategies for aligning your Agile work to your organizational structures. The first article focused on delivering Agile projects within existing Project, Process and Quality Management frameworks. In this article, the focus is on delivering Agile projects within the existing corporate reporting structures of your organization.
Agile approaches provide a number of mechanisms for tracking progress, including formal reports (e.g. executive dashboards), status update tools (e.g. WIP boards and product backlogs), and ongoing communication with stakeholders.
The ideal Agile reporting environment would leverage these tools without asking staff to do extra (often redundant) work to meet corporate reporting requirements. Specifically, this would involve using:
This model would allow Agile teams to continue to use the reporting tools that are a standard (and natural) part of their Agile work; and not require corporate reporting to 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 business value generated by their staff members.
In most organizations, however, 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.
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, 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 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 on 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 work. (This quarterly reporting structure for Agile work was introduced to me by Europe’s first Certified Scrum Trainer, Joseph Pelrine.)
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 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.
For budget tracking, executive dashboards and backlogs allow you to identify the historical, current and planned utilization of your Agile teams at any point in time. Where staff members are fully allocated to Agile work, these tools allow you to:
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 return on investment than your organization is likely to mandate.
If your organization uses a standard time-tracking tool, 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 recording all of their day-to-day work in two systems.
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. As Agile reporting tools gather most (if not all) of the detailed information needed as input into your departmental reporting, the challenge for you is not getting staff to retrospectively fill in their timesheets, to provide status updates on three-week-old work, or to 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.
There are no products in your shopping cart.
| 0 Items |
Membership at BPMInstitute.org includes access to our other communities
