Agile Release Planning Kick-Starts Agile Adoption
Organizations just starting out in their Agile adoption are eager to begin seeing results. After proper Agile teams have been formed and trained in the basics of Agile, they are ready to begin practicing. But what is the first step in your Agile adoption, where should they start? Agile Release Planning is the answer.
Agile Adoption : Release Planning
Agile Release Planning enables teams to speed up their Agile adoption. It brings the stakeholders together in a working session focused on developing the software requirements and plans to develop the software incrementally and iteratively. Risks, issues, dependencies and assumptions are identified and addressed in the planning.
This kick-starts the Agile adoption practices, enables teams to begin delivering results quickly, and sets them up for success with the release. A recent coaching engagement provided a good example of this.
An Agile development team had been formed to build the next generation platform for a Resource and Operational Planning tool suite. A new platform with a single, common database and user interface was needed to better integrate and present the product offerings, in line with the product vision and roadmap. The legacy platform had become overly burdened with technical debt after years of ad hoc development, and became costly to support and extend.
The new team was in its forming stage. There were conflicting views and differences in understanding of the requirements for the next generation platform. There were strong differences of opinion about what and how to leverage from the existing platform architecture and code base, which was large and complex.
Most of the new team came from the legacy platform development team. But the Product Owner (PO) and Product Manager (PM), two developers and a tester were from a different but similar product suite. The PO had recently been part of a similar platform uplift program for the other product suite, and had a developer background. As such, the PO had strong opinions about how to execute this project, including on the subject of architecture and code reuse. He strongly advocated for starting over with a new clean architecture since, for example, the existing platform had lots of business logic tightly coupled with the UI.
But the legacy development team members were very concerned about doing this. They were counting on re-using a lot of the legacy code (and architecture). In their minds, that would be the fastest way to complete the project, since they were very experienced in development of the legacy platform.
Agile Adoption : Release Planning Workshop
To overcome these issues, we held a Release Planning Workshop. Representatives from Product Management, Development, and other stakeholders in the release were in attendance. Our workshop began with an intentional focus on reviewing the business goals and associated product vision and roadmap, as a precursor to talking about architecture, epics, features, and stories. This quickly made it clear to Product Management that they were not fully prepared to discuss the platform requirements in this manner.
We were able to identify some epics/ features and stories on that first day of the workshop, but it was mostly a training exercise for the team to learn what and how we do release planning to improve their Agile adoption. With this new understanding, Product Management asked for a week to go “do their homework” to fully prepare for another try at Agile release planning.
Agile Adoption : Outcomes
We reconvened a week later for “take two” of release planning. This time we made rapid progress and accomplished the goals of release planning. Notable outcomes include the following.
1) Development finally understood and accepted that Product Management wanted a new, simplified, de-coupled architecture – not just a refactoring of the existing architecture. This would be the basis for a normalization of how data entry, processing, and presentation would be done across products/ features running on the new, common platform.
2) Delivery date would be negotiable as the project progressed. Development had been assuming that there would be a fixed due date 9-12 months later, which they would be pressured to accept, even though it would be high risk to commit to a delivery date that far out. But Product Management did not have a fixed due date in mind. Instead, getting the new platform they envisioned was the priority for them. They could be flexible about the final completion date.
3) Product Management did want to see incremental milestones of progress, and fortunately, that is exactly what Agile release planning is designed to provide. The plan was for Development to deliver a release every quarter, internally only, incrementally and iteratively building up the platform with every internal release, leading up to the final product release.
4) With a well-groomed release backlog coming out of the gate, the team could begin planning and executing sprints, and gauging their velocity. This in turn would enable refining of the release plan as the project progressed.
5) The team delivered a demo by the end of the second sprint, and every sprint thereafter. They recently made their first quarterly release milestone.
Agile Adoption : Summary
For a new development team with only basic Agile training prior to release planning, within two weeks we had a mutually agreed upon viable release plan that enabled the team to begin executing sprints aligned to the first quarterly release. They had learned how to capture product requirements as user/ role and goal –centric epics, features and stories, create acceptance criteria, estimate stories in relative story points, and they were ready for the first sprint planning and execution.
Without good Agile release planning, teams often try to start sprinting with a poorly groomed backlog, with no clear direction towards delivering on release goals. This can result in wasted time and effort (money), engraining of bad habits, as well as frustration and disappointment with Agile adoption.