We’ve all been there. You’ve started a new agile team and things are going great. Your team is working together wonderfully, your customers are thrilled to be invited into the process, and your organization is absolutely astounded by the amount of value you’ve delivered in such a short time.
But, inevitably, you eventually hear that phrase that no agile team ever wants to hear: “Your team is doing great! When can I see a Gantt chart?”
If you’ve ever worked on an agile project, then you’ve probably realized that the types of reporting that are beneficial to an agile team are very different than those that are beneficial to a traditional team. This is because agile and traditional project management approaches are based on fundamentally different ideas, and the reports used by these approaches reflect those differences.
One common difference between these two types of reporting is that traditional project management reporting is often based on individual performance while agile reporting shifts the focus to the team’s performance, as a whole.
For example, it’s not unusual to see traditional reports focused on metrics such as lines of code an individual has committed, hours an individual has worked, or bugs an individual has fixed. Agile reports, on the other hand, tend to focus on metrics such as the number of points a team delivered in a previous sprint or the estimated amount of business value delivered in a previous release. These metrics better capture the amount of work that a team has delivered as a whole rather than incentivizing the members of that team to compete against one another.
Another difference is that traditional project management reporting tends to view how well a team is adhering to the project constraints of budget and schedule as the ultimate measure of a team’s success. While these metrics are important, they’re a poor proxy for how your actual customers will measure the success of your product. By contrast, many agile metrics are built around predicting the tangible business value that a team is delivering sprint over sprint as well as how well that work is actually solving your customer’s problems.
A side effect of this is that the reports used by agile teams tend to be less granular since they are often intended to inform the underlying context in which the team is operating, rather than to be used as the single indicator of whether a team succeeded or failed. While this can ultimately lead to more informed decision making and thus better outcomes for the team, it also explains why some traditional managers might feel that agile reports don’t provide the level of visibility they need if they’re accustomed to making decisions from a distance based only on a set of numbers.
But what if you’re still unable to convince your manager to throw away her Gantt charts in favor of a more agile reporting tool? Don’t despair; you can still find success by taking the time first to understand the underlying needs behind your manager’s requests. Often discovering the reason behind a request not only helps you communicate more effectively with the requestor, but it can also help you better understand what types of reports will best suit their needs.
One way to better understand this is to consider how your manager’s own success is being judged. In particular, what results might your manager be accountable for and how might that accountability incentivize their behavior. For example, is your manager directly accountable for the success or failure of each project under their purview, or are they merely viewed as a reporting channel to the higher level leadership in your organization? The level of accountability you manager has can significantly influence how hands-on they insist on being with your team.
Another way to gain insight into what might be influencing your manager’s behavior is to consider who your manager is reporting to themselves. Specifically, is your manager reporting directly to the C-suite who will be making executive decisions directly from your manager’s information, or are they reporting to a lower level of leadership, such as the VP level, who might be spinning those reports up to the C-suite for their own gain? If this is the case, then taking a few moments to consider the different types of information that each level might be interested in, as well as the biases that might exist at each level, can be very enlightening.
The answer to the questions above can help inform what types of reports may be the most informative to your manager.
For example, if your manager is most interested in the day to day activities of your team then a report that tracks your team’s progress at the daily level, such as a Burnup Chart or Cumulative Flow Diagram, might be of the most use. Reports such as these will provide insight into how your team is progressing as well as give your manager more frequent opportunities to step in if she fears that your team may be veering off course.
On the other hand, if your manager is most interested in the long-term view, then she may see the most benefit from a report that provides long-term strategic insights such a Release Burnup. This report can provide guidance as to how your team is trending over the long term, as well as provide an early warning if it appears that your team may be veering off track.
These are just two of the agile reports that can add value in an agile context, once you’ve taken the time to understand exactly what questions your manager is seeking to answer.
However, most importantly, you must help your manager understand that reporting in an agile context is but one piece of the puzzle of your team’s progress. If your manager wants to understand the whole picture of how your team is progressing, then the most effective way to do so is to begin interacting with your team on a regular basis such as attending sprint reviews, daily standups, or seeking other opportunities to provide regular feedback.
This is because even the best reporting pales in comparison to the amount of information that can be gleaned from regular interactions with the team.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
Tags: How to
