Tips for Reporting on Agile Projects
When you’re a product manager working with agile teams to release a product to market, you typically serve more stakeholders than just your market. Most product owners are also responsible for reporting progress on investment and return to a committee, a boss, a leadership team, a board, shareholders… the list of people you answer to may be short or long, but it almost certainly exists.
Reporting to those stakeholders is not an easy task, because agile thinking tends to encourage change; value is maximized by empirically shifting scope as releases happen and data is gathered. Frameworks like Scrum and Kanban do a great job of helping teams and product owners harness the power of iterative release, but projecting timelines or budget is very challenging when those two things are based on ever-evolving scope.
The reality in most businesses is that, regardless of uncertainty resulting from real-world factors or mechanics of your development framework, you can’t stop reporting or projecting. Investment is… well, investment! Projects with no budget are tough to fund, and unfunded product development doesn’t develop very far or fast.
How do you balance the need to report without compromising agile values? If you’re a product manager in an agile world or serving in a product owner role on a Scrum team, these concepts might help:
Educate First, Then Do it Again, Then Don’t Stop
You might not be an expert, but if you’re a product manager working with an agile team, you probably know something about the development framework you’re using. If you’re practicing Scrum, you’re probably in the Product Owner role, helping keep the team oriented with statements of vision, value, and validation. You’re probably writing or helping write requirements, keeping those organized, and evaluating the team’s work before it goes to your stakeholders. Those stakeholders probably know a lot less about Scrum, agile thinking, lean principles, or whatever other thought process goes into your framework for development. They show up to give you feedback, either on the product itself or on the investment they’re making into the product.
This is important to remember: empathize with your stakeholders. Remember how little they know, or maybe care, about your framework. Don’t assume they see the inherent value in iterative processes or the power in changing scope to maximize value. They just want to know how much they get for how much they spend and how soon it will arrive.
With that in mind, take a few minutes to give your stakeholders a synopsis of your product’s development lifecycle. Do it the first time you meet with them. Do it the second time. Do it every time after that. The context of that lifecycle will help frame up their reception of your release and the feedback they give. It shifts “do you like this?” conversations to “what would you like to see change?” It avoids the “when will we be done?” question and redirects it to “what do you think we should prioritize next?”
Stabilize Your Vision, Lead with Why, and Don’t Be Bullied
As the product manager or Product Owner, depending on your framework, it’s critical that you establish a vision for your product. What problem are you solving? Who are you solving it for? This vision should be the answer to “why” you’re developing the product, not the answer to “what” it will do. This means that whatever change your scope may undergo, whatever data you may gather from releasing to your market, whatever new ideas get added, the vision will remain stable. Vision should only change when development stops on the product and you start building something different.
It should be the guide for what constitutes value in your product. It should not only help you say yes to the right things, but no, or at the very least not yet to the things that aren’t clearly in service to the vision.
Your vision should be able to withstand a pummeling from your stakeholders. When they ask why a certain feature wasn’t included in the latest release, or why their feature is further down the list from another, the vision should serve as explanation. Don’t let your vision be bullied by even the loudest stakeholders: if their request doesn’t serve the product vision, or isn’t as valuable as another request, it’s not right for your product. Or at least it isn’t yet.
Make it part of your routine in communication with stakeholders and budget-keepers to not only remind them of the framework’s purpose, but the purpose and vision for your product. Make that the context for every sprint review, budget review, and release announcement.
Use Data and Make it Visual
Okay, so you’re constantly educating your stakeholders on the framework you’re using to maximize value and reminding them of the vision of your product. That should be helping build trust, but delivering working software is the proof, the ultimate trust builder. How do you know your software is working? Because it compiles? Because it can be seen on a device at a specific location? But how do you know it’s bringing value?
A good product owner, one armed with a strong vision and empowered to provide the team with true value and validation, doesn’t work from their gut. They use data to measure adherence to the vision, and they make that data presentable to both the dev team and their stakeholders.
If you want to bridge the gap between report-needy stakeholders and the ever-evolving scope of your project, make it visual to them. Use real data about the budget, timeline, release schedules, and the highest value items you prioritized for release. The facts are the facts, and when they’re based on data and prepared in an easy-to-consume fashion, your rationale for steering the product’s development is not only obvious to you, it’s obvious to others as well.
Be the Leader Who Pushes Software Initiatives Forward
Get an Aptera Team on Your Side