I have spent a lot of my and the team's time creating release plans. Release plans that:
- Show dates around when features will be done
- Show dates we plan on iteratively releasing through the course of the next month, quarter, and/or year.
- That I used to ‘manage up’ so that bosses knew my team and I were busy fulfilling our ‘commitments’.
- I felt it motivated employees.
All the while, I knew these release plans to be entirely made up. Let me illustrate this with a chart.
(Image 1.0 a release burndown chart I once used with a Scrum Team)
Image 1.0 was a chart that a Scrum Team and I used to set expectations around a release. Some context… There was not a ton of trust in this organization. Our release plan was based on finishing four major features which the business wanted us to “commit” to before they funded our product.
The people funding our product wanted to make sure that we were working hard and meeting our “commitments”. They wanted proof of that so we frequently showed this chart in Sprint Reviews and the Product Owner had it handy when they came knocking at her door. Management and stakeholders found this chart very satisfying. We were on the path to success!
What you cannot see on this chart is that the team released at least once a month throughout the duration of these six months. Quality was excellent as few production bugs caused problems, and support was reasonably low. We had hooks into what user activity was happening and frequently surveyed them. Users were satisfied with the product, and the Product Owner regularly interacted with them changing her plan as a result of those conversations. Interestingly, this chart doesn’t say anything at all about those things at all. We’d mention these things in Sprint Reviews but management, and stakeholders wanted to see “the chart”.
In reality, the chart in Image 1.0 was completely made up. The Scrum Team maintained it as a means of keeping management and stakeholders off our backs. We knew what really mattered: satisfying the users. So we spent the time necessary to keep management at bay, making them feel comfortable about us working hard towards achieving our commitment.
You can judge these tactics and talk about how we didn’t adhere to Scrum values and how we lacked transparency by doing such a thing. I understand that angle. We were under pressure, and our jobs were on the line. We did what we thought was right by throwing up smoke while concentrating on what we knew we really needed to concentrate on getting and maintaining satisfied customers. That was winning, and we knew it.
We wasted a ton of time creating that chart. Here are a few activities that the Scrum Team did for that chart:
- Release Plan Report Creation/Maintenance
- Requirements Gathering Discussions
- Management/Massaging the Product Backlog
- Refinement (Estimation, Decomposition, etc.)
- Meetings to talk about all these things
These activities can be (and often times are) waste. Especially when overdone. If it isn’t helping us get real signals about our existing or potential customers, how we can more quickly learn about how what we shipped has impacted customers, and/or telling us what is limiting us from being effective, I’m not sure if it's worth spending time on these things when we could be building. These activities were a distraction away from our customers. Quite frankly, we were wasting time making management happy with a chart that was fake.
How much time do you and your team spend creating release plans? What are the activities you and your time perform to create these plans? How much money is that costing? Why aren’t you spending that time building experiments?
There are major problems with putting all your eggs in a Release Plan basket. I have witnessed a lot of teams believe in them, above all else, while ignoring value and quality. As if some chart that contains made-up metrics shows that there is customer satisfaction when the chart is finally satisfied. Then I’ve seen teams crash and burn with disappointed users who receive a low-quality product that didn’t fulfill their needs. But… their release plan charts looked great!
What could we do instead to do a better job of setting expectations? Use Evidence-Based Management (EBM).
Evidence-Based Management (EBM) is a framework that helps people, teams, and organizations make better-informed decisions to help them achieve their goals. If EBM is new to you, start by reading the EBM guide here: https://www.scrum.org/resources/evidence-based-management-guide.
I wish I knew as much about Evidence-Based Management then as I do now. How we started and ran this product being developed would have been based on reality rather than a fake chart.
Before we even started, I would have centered the conversation with management, stakeholders, and the team around creating good, measurable, outcome-oriented goals. We could have quite easily and in little time, created alignment with the strategic goal by crafting our first intermediate goal followed by creating an immediate tactical goal for which would would immediately begin working towards accomplishing.
We could have leveraged the Key Value Areas (KVAs) to show supporting evidence that we were heading in the right direction toward the goals. We wouldn’t have to hide that our secret agenda was to placate management while satisfying users. We wouldn't have had to create non-sensical Product Backlog Items that we estimated but never touched.
I feel like we could have engaged in more robust conversations rather than creating a false sense of security with the release planning chart. The product was good, but it could have been great. Don’t fall into this trap.
Although I discussed in brief how I would have changed my approach with EBM there is a world to uncover about EBM and how you could use it. Outside of the EBM guide, I wrote an article that may be helpful: https://www.scrum.org/resources/blog/3-questions-consider-when-getting-started-evidence-based-management-ebm.
Learn more about me by checking out my profile:https://www.scrum.org/todd-miller