To get a self-organising team we need to get managements fingers out of the jam pot. The only way that can happen truly is if management have full trust for the team. If you face reality, trust is nothing you get for free it’s something you have to deserve. So how can we deserve trust?
Having a good standard format for reporting is a good way to earn trust since recognition gives control and control gives confidence, which lead to trust. So we have to find a way to repeatedly communicate to management so they feel they can truly trust the team and leave the team to self organise. The report must give feeling of full transparency but at the same time not being too much to chew and definitely not taking too much time to produce. We want to put most of our efforts on the product development and not writing documents, right?
A person from a former customer came up with an excellent idea, short, simple but showed to be very powerful. He suggested to, after each sprint, report the three p: progress, projection and problems. I know, the idea came from a project but it should work also for on going improvements since even they usually have some form of roadmap to follow, including mile stones and releases.
The three p of reporting
Progress – what has happened since the last time? Have we changed the team in any way? Have we reached any milestones? Have product owner added new stories or is the roadmap the same as the last report? What was the velocity and is it stable? The velocity is reported as the difference of how many story points there are left to the release this time compared to what was left before the last sprint. That is, how much closer to goal are we. I call it speed over land in difference to speed through water. If you are used to sailing you know that the difference is the current and in this case the current is bug fixing or fixing technical debt. Trying to tell management that you have a velocity of 30 but are only 10 story points closer to release will only confuse and confusion is a good way to ruin trust.
Projection – To build trust it’s a good idea to decide a road to reach the goal and give an estimation how long the road is. I know this does not sound very agile but if you like to build trust it’s great to have a plan but always communicate the plan might be changed and that management will be informed when it changes. The plan does not need, and even should not be, detailed but a rough idea of included and estimated features are needed. Projection is a way of saying how much is planned to be released and when. It’s a good idea to support your dates with a project burn down chart showing it’s realistic to hit the 0-story-points-left point that date. This implies that definition of done is releasable and no debt is pushed in front unless that is included in the plan and given estimates that are comparable to the other stories.
Problems – What is on the impediment list? What was said at the last retrospective? Especially things management can help you fix is important to include here but also include things the team will work on to become more effective, that helps building trust.
It might takes some hours to build a presentation based on Progress, Projection and Problems but when you have done it once you just need to update it for the next report and that is a quick fix that should only take a couple of minutes.
Good luck building trust and remember that your boss probably has someone to report to and squeezed people doesn’t act rational so make sure you give the information he or she needs to build trust to his or her boss.
Best wishes
/Tomas Björkholm
Your three P:s are interesting in that they map very well onto the three things you report at a daily Scrum meeting:
That’s a good point. Thanks for bringing it up.
The similarity between a good reporting within a team and reporting to management means we are, by using ppp-reporting, a good way on introducing what Jeff Sutherland refers to as Scrum C, where the whole company is using Scrum.