page =
url = https://blog.dustinkirkland.com
from the canyon edge
When adapting the coordinated, time-based release cycle to a given organization, the first thing to consider is the time frame. After talking to all of our stakeholders, 6-month releases, like Ubuntu or OpenStack felt a little too long, a little too slow, for Apex and our customers. Most of the engineering teams were already quite agile and utilizing 2-week sprints, so getting product requirements for 26-weeks (13 sprints) seemed a little unwieldy. Quarterly cycles, however, can be pretty tough to see through, for anything but the smallest individual projects (frankly, Kubernetes struggles with the pace at times). Moreover, all of the projects I’ve been involved in, have struggled with the end of year holidays, in November, December, and January. Thus, we actually settled on a 16-week cycle, which amounts to roughly 4-month cycles. That translates to 3 full cycles per year, with 48 weeks of development, while still allowing for 4 weeks of holidays.
Our cycles are named for the year in which it will complete (launch), and with a letter as an iterator. In 2020, we launch Apex 20a (March), Apex 20b (July), and Apex 20c (November), and looking forward to 2021, we should see Apex 21a (March), Apex 21b (July), and Apex 21c (November). The “c” cycles are a few extra weeks, to account for the holidays near the end of the year. These aren’t really “versions”, as Apex is more like “software as a service”, rather than “delivered software”, like Ubuntu, OpenStack, and Kubernetes. Also, conversationally, we're referring to the cycles with the season -- so Apex 20a is our "Spring" launch, 20b will be our "Summer" launch, and 20c will be our "Autumn" launch.
The Prioritization Summit brings together our product managers with all of our key stakeholders – sales executives working with new business prospects, our client relationship managers working with existing customers, as well as our own IT, operations, and site reliability engineers tasked with keeping Apex running on a day to day basis. Each product manager works with their stakeholders to gather CUJs (critical user journeys) and map those into patterns of similar, weighted product requests. Product Managers generally spend about 2 weeks on that work, which culminates in a session where the Product Manager presents the consensus priorities for their product area for review by the broader product team. Based on this work, each product manager then starts working on their PRDs (product requirements documents), for the next 3-4 weeks. Our Prioritization Summit is about a dozen, hour-long sessions, spread over three days in the same week. We exit the Prioritization Summit with clear stakeholder consensus on stack-ranked priorities for each product family.
The Planning Summit signals the end of the PRD-writing period, during which product managers worked closely with their engineering counterparts, digesting all of those product requests and priorities, and turn those into product requirements written in RFC2119 -style language (must, should, may, etc.). At the end of that process, each Product Manager and their technical counterpart lead an hour-long session with their plan for the next cycle, including fairly detailed commitments as to the major changes we should expect to be delivered. Our Planning Summit is about a dozen, hour long sessions, spread over three days in the same week. We exit the Planning Summit with clear product and engineering consensus on work commitments across the product portfolio, for the upcoming cycle. This marks the beginning of the development portion of the cycle.
For the next few weeks, product managers spend the majority of their time with Apex customers and prospects. Each of us on the product team carry specific OKRs (objectives and key results), to spend meaningful time with our existing correspondents and prospects, communicating our product roadmaps and gathering feedback on their experiences. We take detailed notes, and all of this data filters directly into our future Prioritization Summits.
At the middle of our release cycle (week 8 of 16), we bring together the same Product Managers and technical leads to report on status of the first 8 weeks (4 sprints), and recalibrate the remaining work for the cycle. Without exception, there are always new, late-breaking product requests or requirements that emerge, after the prioritization and planning summits. Some of these are urgent, and we must accommodate, which usually means something else gets deferred to the next cycle. Sometimes, we were a little too optimistic with our work estimates , and again we need to adjust. Occasionally, we’re ahead of schedule and we can cherry-pick some other bite-sized items to bring into scope. In any case, we will exit the Mid-cycle Summit with a very clear line-of-sight on our deliverables by the end of the cycle.
With any scope adjustments well understood, the product team shifts into “go-to-market" mode. Over these next 3 weeks, Product Managers are working with our Marketing counterparts, writing release notes, creating marketing content, educating our sales teams, and working through signoffs on our launch checklists.
Apex 20a launched on March 31, 2020, as our first release using the methodologies described above. Apex clients can find detailed release notes in the Apex Developer Portal . This cycle began with a Prioritization Summit in October 2019, a Planning Summit in November 2019, and a Mid-cycle Summit in January 2020. This cycle involved 17-weeks of development.
Our work on Apex 20b is already well underway, having held our Prioritization Summit in February 2020, and we’re holding our Planning Summit this week (March 2020). Our Mid-cycle Summit will be held in May 2020, and we will launch Apex 20b in July 2020.
Thursday, April 2, 2020
When adapting the coordinated, time-based release cycle to a given organization, the first thing to consider is the time frame. After talking to all of our stakeholders, 6-month releases, like Ubuntu or OpenStack felt a little too long, a little too slow, for Apex and our customers. Most of the engineering teams were already quite agile and utilizing 2-week sprints, so getting product requirements for 26-weeks (13 sprints) seemed a little unwieldy. Quarterly cycles, however, can be pretty tough to see through, for anything but the smallest individual projects (frankly, Kubernetes struggles with the pace at times). Moreover, all of the projects I’ve been involved in, have struggled with the end of year holidays, in November, December, and January. Thus, we actually settled on a 16-week cycle, which amounts to roughly 4-month cycles. That translates to 3 full cycles per year, with 48 weeks of development, while still allowing for 4 weeks of holidays.
Our cycles are named for the year in which it will complete (launch), and with a letter as an iterator. In 2020, we launch Apex 20a (March), Apex 20b (July), and Apex 20c (November), and looking forward to 2021, we should see Apex 21a (March), Apex 21b (July), and Apex 21c (November). The “c” cycles are a few extra weeks, to account for the holidays near the end of the year. These aren’t really “versions”, as Apex is more like “software as a service”, rather than “delivered software”, like Ubuntu, OpenStack, and Kubernetes. Also, conversationally, we're referring to the cycles with the season -- so Apex 20a is our "Spring" launch, 20b will be our "Summer" launch, and 20c will be our "Autumn" launch.
The Prioritization Summit brings together our product managers with all of our key stakeholders – sales executives working with new business prospects, our client relationship managers working with existing customers, as well as our own IT, operations, and site reliability engineers tasked with keeping Apex running on a day to day basis. Each product manager works with their stakeholders to gather CUJs (critical user journeys) and map those into patterns of similar, weighted product requests. Product Managers generally spend about 2 weeks on that work, which culminates in a session where the Product Manager presents the consensus priorities for their product area for review by the broader product team. Based on this work, each product manager then starts working on their PRDs (product requirements documents), for the next 3-4 weeks. Our Prioritization Summit is about a dozen, hour-long sessions, spread over three days in the same week. We exit the Prioritization Summit with clear stakeholder consensus on stack-ranked priorities for each product family.
The Planning Summit signals the end of the PRD-writing period, during which product managers worked closely with their engineering counterparts, digesting all of those product requests and priorities, and turn those into product requirements written in RFC2119 -style language (must, should, may, etc.). At the end of that process, each Product Manager and their technical counterpart lead an hour-long session with their plan for the next cycle, including fairly detailed commitments as to the major changes we should expect to be delivered. Our Planning Summit is about a dozen, hour long sessions, spread over three days in the same week. We exit the Planning Summit with clear product and engineering consensus on work commitments across the product portfolio, for the upcoming cycle. This marks the beginning of the development portion of the cycle.
For the next few weeks, product managers spend the majority of their time with Apex customers and prospects. Each of us on the product team carry specific OKRs (objectives and key results), to spend meaningful time with our existing correspondents and prospects, communicating our product roadmaps and gathering feedback on their experiences. We take detailed notes, and all of this data filters directly into our future Prioritization Summits.
At the middle of our release cycle (week 8 of 16), we bring together the same Product Managers and technical leads to report on status of the first 8 weeks (4 sprints), and recalibrate the remaining work for the cycle. Without exception, there are always new, late-breaking product requests or requirements that emerge, after the prioritization and planning summits. Some of these are urgent, and we must accommodate, which usually means something else gets deferred to the next cycle. Sometimes, we were a little too optimistic with our work estimates , and again we need to adjust. Occasionally, we’re ahead of schedule and we can cherry-pick some other bite-sized items to bring into scope. In any case, we will exit the Mid-cycle Summit with a very clear line-of-sight on our deliverables by the end of the cycle.
With any scope adjustments well understood, the product team shifts into “go-to-market" mode. Over these next 3 weeks, Product Managers are working with our Marketing counterparts, writing release notes, creating marketing content, educating our sales teams, and working through signoffs on our launch checklists.
Apex 20a launched on March 31, 2020, as our first release using the methodologies described above. Apex clients can find detailed release notes in the Apex Developer Portal . This cycle began with a Prioritization Summit in October 2019, a Planning Summit in November 2019, and a Mid-cycle Summit in January 2020. This cycle involved 17-weeks of development.
Our work on Apex 20b is already well underway, having held our Prioritization Summit in February 2020, and we’re holding our Planning Summit this week (March 2020). Our Mid-cycle Summit will be held in May 2020, and we will launch Apex 20b in July 2020.