Reports for CIO to steer an Agile Organization

This weekend, I read an article which prompted me to think about the various reports a CIO would need to steer an Agile Organization after having made the strategic decision to use the right organizational structure for meeting the many demands placed on his/her organization.

As we all know, an agile organization is?a human-centric organization that responds and adapts quickly to changes in the marketplace or environment and CIOs are often guiding this change in their organizations. The agile organization focuses on satisfying its customer's needs through continuous delivery of valuable products and reports provide visibility to achieving that.

Further, if you are running an important initiative, you use reports to monitor and communicate how well your project or program is doing. If you are facing challenges, risks, issues, then you can get the help you need. If your team are doing a good job, your reports will reflect this – and get you and the team the rewards you deserve. Your regulators, auditors, senior management – all of them look for reports to understand progress against goals and targets.

Once you start using the usual suspects like 1. Burndown, 2. Velocity, 3. Burnup, 4. Scope Change, and 5. Defects Trend; the three Capacity Planning Reports described below would help you immensely.

Capacity Planning is a process whereby an organization comes together to agree on what they are going to focus on in the medium term. There are atleast two outputs from the Capacity Planning process:

1. An ordered backlog of initiatives that the entire organization agrees on.
2. A list of the constraints and options within the organization.

1. Team Capacity/Load Report

Whether you’re starting out with Agile Transformation, or if you’re at various stages of getting there, the most challenging Agile tenet is not having team members spread on multiple projects. The Team Capacity/load Report can help with providing you a snapshot of your team’s workload. It provides at any point in time – what everyone in your team is up to.

For each team member on a project, capture the following information:

• Total capacity in hours = number of hours per day that they are able to dedicate to the project multiplied by number of days that they are allocated to the project.
• Assigned capacity in hours = number of hours (or story points multiplied by average number of hours per story point for the team member’s particular skill) allocated.
• Available capacity in hours = Total capacity – Assigned capacity

Having this information to hand will help manage your team’s allocation better – especially when they are across multiple projects. This sets the stage for Capacity Planning.

Capacity Planning means that for a year the product organization has to come together once a quarter to prioritize an organization wide product backlog based on the available capacity of teams (assumes that the architecture is constructed such that a set of scrum teams are to be able to deliver independently).

The organization wide backlog (known as the meta backlog) is a set of business goals whose success was measured using metrics. For example, reduce the day one churn (number of users that only use the product once and never return), conform to regulatory rules to prevent significant fine or enable asynchronous chat by moving it chat from peer to peer to server based.

Anyone who has worked in a large organization knows that it is pretty much impossible to set up your organization such that every business goal can be delivered by a single scrum team. Several teams are often required to achieve a business goal. Large organizations need to create a single ordered backlog to provide focus and create alignment between the teams.

Once you establish the process to create an ordered backlog, you are able to get better insight into what is actually happening in the delivery. To that end, you have the opportunity to reduce work in progress by over 50% at one of the organizations I worked at.??

The following two reports can help you understand which teams needed their help and support. The reports provide red flags that help you identify issues to resolve. These two reports provide leadership with a system wide view so you can identify constraints. The CIO uses them to solve system wide issues rather than issues with an individual team.

2. Most Backlogs Team Report

Identifies teams that had the most backlog items in progress.?It shows the team name and the effective position in the backlog that they were working. It was possible to drill down on each team to show the items they were working on.

3. Right Priority Order Report

Identifies teams that were working on items in the wrong order according to the organization wide backlog. As an example, 50% of the effort in the organization may be for “Items not on the organization Backlog” because the teams will not be able to work on the backlog item as there will not be enough capacity in the teams acting as the constraint in the system. For this reason, you need the Most Backlogs Team Report as well to identify teams that are spread too thin both for items on the backlog and for items not on the backlog.

Here are a five reports that you may already be using in addition to above three.

1. Burndown Report

The burndown presents the easiest way to track and report status (the proverbial Red/Amber/Green), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide near-real time updates on Sprint progress.

2. Velocity Report

This metric goes hand in hand to help your team achieve ideal burndown. The Velocity report represents the average number of story points a team can take on for a Sprint. This number is based on observing how many story points were delivered during the previous two to three Sprints, and simply calculating the average story points delivered per sprint. You can use the 5 methods in this article to increase velocity.

3. Burnup Reports

Release-level burndown charts help you understand when you can expect to deliver a given scope. And again, note that the accuracy of the burndown improves with time, as the team deliver the first few sprints.

There are limitations with Burndown charts. They don’t bring out issues such as scope creep as clearly for all stakeholders to understand. For a CIO that sits outside the project, it may not be immediately apparent that the team are doing more than they set out to plan. Therefore, the causes for any delays in the project schedule aren’t understood as well as they could be with better information.

A burnup chart plots two key pieces of information – total work (hours, story points etc.) and completed effort (progress against total work). When your release/sprint scope isn’t stable enough, switching from a burndown to a burnup chart will help you identify and report risks and issues more effectively. If on the other hand, your backlog is pretty stable up front, and you don’t see the scope changing regularly, burndown charts will be sufficient to report progress.

4. Scope Change Report

By nature, Agile projects should be open to scope change. By reporting Scope Changes, you demand a certain level of responsibility on the part of the Product Owner. They have the responsibility to think any significant changes through before these are introduced to the project, so they can be prepared to answer any questions about cost/scope creep.

5. Defects Trend Report

Plot defects as they are identified, their resolution and those that remain open on a graph, and you’ll have yourself a visual Defects Trend chart. Defects Trends are useful in tracking defects resolution for a release or product as a whole. Making defects trends visual brings a sense of urgency and accountability among developers, who will (hopefully) work to improve code quality.

Choose to use the reports wisely and ask questions before reaching a conclusion. “Behaviors” were often a result of constraints in the system. For example, at one of the organizations I had worked at, the team is blocked waiting for another team and moved onto the next item. In some cases the product owner was not aware of the impact of too much work in progress which was a “learning opportunity”. In another case, the product owner on the 16th priority was very aggressive at getting their own delivery done such that they put the 1st item at risk.

As in any journey, follow these three tenets for a successful Agile management which will make your business come back to you for more - enable quick wins, demonstrate business impact and build credibility with business stakeholders.

Thanks for reading and please leave a comment or share this article with your thoughts. I am trying to expand my network and would appreciate it very much if you send me an invite to connect or forward to someone you know would find this article useful.?