An agile team was recently asked by a manager to prepare and distribute a weekly status report. What is your reaction when you read this? For some, this may seem quite normal. For others, you may need more context behind the request before reacting.
If your reaction is anything like mine, you’re probably thinking something seems amiss. While I’m not saying status reports should never be produced, when an agile team is being asked for one we should probably ask why.
From my experience, the primary reason for a request for status is because the team is not radiating enough information back into the organization. The natural energy and cadence of a well-functioning agile team rarely requires a status report. If the team is being asked to produce a status report either there are lingering dysfunctions in the organization beyond the control of the team OR the objective of the team should be to begin to radiate enough information until the status report is no longer necessary.
Becoming a radiating team should require very little additional effort and there is a wide range of existing information an Agile team produces to satisfy the requestors need for status. In short, we have the antidote to status reports. Here’s how:
Radiate intention through a product backlog. The backlog declares unequivocally what the team deems important to build and the sequence in which they will build it. The backlog could also contain experiments the product owner would like to try to validate a hypothesis. Provide access to a read-only version of this in a shared location so all interested parties can review and discuss. The product owner can field any open questions or requests for change.
Radiate progress through a real-time task wall. The task wall indicates movement. With a prioritized backlog, we also know this movement is always working towards completing valuable work. If the task wall is stale (i.e. tasks remain in progress for days) people should get nervous. Put the task wall in a public place or if your task wall is virtual, allow read-only access to this as well. The details won’t matter to most people outside of the team but seeing movement and energy does.
Radiate commitment (or forecast) through a burn-down chart. Or a burn-up chart. This chart will radiate the teams ability to deliver a product increment and when the deployment will occur. For many leaders or stakeholders, this is all they need to know. Are we going to deliver when we said we would deliver?
Radiate blockers listed in an impediment list. Impediments solved within the team could stay within the team but organizational impediments and dysfunctions can be radiated to all who will listen. Removing big impediments is the primary responsibility of managers in an agile organization.
Radiate speed by displaying velocity. If a task wall represents movement, velocity means we are moving in the right direction and getting things done. I’m not advocating the publishing of velocity outside of team boundaries but I believe a confident, radiating agile team should be transparent enough to say we are getting faster or slower.
In summary, when asked to provide a status report, point the requestor to the product backlog (what we are working on for the foreseeable future), the task wall (real-time movement towards bringing the backlog to life), a burn-down chart (over or under-commitment towards releasing the product based on empirical data ), a list of impediments the team can’t resolve (informing leadership of organizational blockers keeping them from effectively delivering) and some indication of team agility or speed (is the team delivering value with speed and craftsmanship). Status requestors can then choose what satisfies their need for status and someone on the team can guild them to it.
If your team is not radiating enough information around progress and team dynamics, there’s a good chance a request for status will be in your future. Agree? Disagree? Feel free to share your thoughts in the comments below.
By the way, to help with radiating your team information, here is an example team health dashboard I previously published. You can receive version 2 of this dashboard (seen below with more features and metrics than the first version) by becoming an Illustrated Agile subscriber. Existing subscribers can find a link and password in the latest email from Illustrated Agile.
4 replies on “Becoming a Radiating Team”
A team can also really shine during the sprint review, showing off what they have accomplished.
So true Nico! The sprint review is an amazing place for the team to radiate progress to the whole organization. Thanks for sharing!
[…] ⬅ Becoming a Radiating Team […]
[…] Becoming a Radiating Team A sure sign a team is not radiating information is when someone requests a status report. Transparency should be a natural part of the DNA of an agile team. […]