Release Planning is becoming a controversial topic in the Agile community. Purest are saying that if you are doing true Scrum you should release working software often – as soon as an MVP is ready. The Team should be releasing frequently in order to learn from their customers and users. I agree 100% with this paradigm; however, on large scale projects with many teams, stakeholders, dependencies, and risks this can be difficult.
We work with many clients who are developing larger software projects. In organization with multiple teams and product owners, priorities can be to coordinate. These clients are not large enough to implement a full Scaled Agile framework, so release planning sessions gain importance.
I recently facilitated a Release Planning session for an organization which took an interesting turn. The meeting became less about writing Epics and Stories, reviewing velocity, and charting a path towards release success. Don’t get me wrong, we definitely accomplished these tasks. The more important lesson from the activity, however, was getting everyone on the same page.
I started the session by asking everyone in the room to quickly define the scope of the next release on a post-it note. It was clear from other conversations I had with the people in the room that they had already completed dozens of meeting to define the release. I figured this was a no brainer.
I received about 6 different visions. Not just slightly different but COMPLETELY different. How could this be, how could the dozens of meetings not have generated a scope plan? Simple: Personal Agendas. Everyone in the room had a different agenda and view point (reduce customer complaints, simplify architecture, upgrade platform, introduce cool features, etc.). Planning had taken place in silos. Each department had meetings to discuss scope, but no one had ever brought the silos together.
We took a quick detour and spent an hour defining scope by listening to each person’s ideas, priorities, and customers needs and wants. At the end of the first hour we had a well-defined understanding, which helped simplify the release planning and give the Product Owner and Team a cross-functional release target.
On large scale projects with many teams, stakeholders, dependencies, and risks – sometimes reducing silos and creating understanding before building a release plan is the simply the smartest way to go.Talk to Us Today