How do I do a status report in an agile project? He that never heard this question let him cast the first stone at this post, lol…
Agile is no longer a tendency or fad, it’s a fact. Large corporations have already adopted agile on a path to increasing the return on their products, reducing “monitoring and control” culture and increasing #COLABORATION. However, generally not all levels of the organization are “sticking post-its on the wall” and that’s where we commit sins of #TRANSPARENCY.
…”It’s all on the kanban board, people just have to take a look”…
Something you often hear…
- The team says: Can we bring those people to understand our board?
- PMO says: Of course we can, that would be great, but do they want to?
Ps.: I use the PMO as an example because they’re usually the status villains, right? I took the liberty of playing around with this because I’m a very proud ex-PMO, lol…
The thing is, management agrees to the agile transition and is anxious for results, because they’ve heard such good things, BUT you think they’d also agree to read the kanban board instead of just receiving the status? Normally, no. Their focus is on “the guaranteed result” and not “how did you do it?” (reflected in the kanban board).
But okay, this is a good opportunity to show management we have other ways of following the status of a project: without a schedule, S curve, SPI, change request etc. And another thing, it’s a chance to explain the innovation! After all, what’s the use of doing something cool if no one finds out about it? We must come out of our caves and shout it out: look what we’re going! It’s cool! This will be good for you too!
Thus far I’ve tried to convince you, the SM and PO and Time, that it’s important to reveal what you’re doing within Agile because you’ll be the ones disseminating the #CULTURE and the processes.
Encapsulating the teams’ result
Now let’s talk about how to encapsulate the results we have within the team, for those outside the team:
1. Define the target audience because the relevant content may change, depending on the audience.
2. Understand the target audience’s and team’s concerns because they will give you the right answers. In other words, this is where the art of understanding the whys comes in (#loveTheProblem).
3. Keep it simple, because the report will have a disclosure period, and any of the team will be able to update it.
In practice, the difficulty is in #loveTheProblem, because when we talk with the audience their answer is the solution (I want the schedule, the costs projection …) and we must find out what the concerns are behind these requests in order to put together solution together with the team.
Here are some ideas you can try out:
When the deadline is a great concern
We can use the burn-up + cone of uncertainty:
Cribsheet for putting the above graph in a PowerPoint:
IMPORTANT: The first time management sees the report, make an introduction explaining why and how to read the new graphs.
When changing the scope is a concern
Get the prioritized and categorized backlog:
When the client’s opinion is a concern
We have specific product metrics. Magno talked about them in another post, which you can read here.
When external dependencies are a concern
Get a board with impediments and where they had/will have an impact.
It’s worth recalling that we must be careful with the metrics we use because they’ll shape the team’s behavior. Avelino talked more about this in another post, which you can read here. Understand what metrics to use in accordance with the objective you want to achieve.
Oh! And let’s not forget continuous improvement, right folks? Align everyone involved so we know this is the initial version, it’s interactive and incremental. Get feedback and improve the next one.
If you want to know more about Certified Scrum Product Owner training, check out here!
