Over the past nine years, Optimizely has grown from a single product company built by a handful of people to a multi-product company with many teams. But its development processes didn’t adapt fast enough to keep up with Optimizely’s growth. Engineers had too many dependencies in flight, designers were added too late in the process to be effective, and the highest value work wasn’t properly prioritized. In the last couple of years, we have improved drastically. Learn how one startup moved from chaos to Scrum and beyond by implementing Enterprise Service Planning (ESP) and the kanban cadences while visualizing all the work on an evolving fifty foot wall, resulting in an increase in our product velocity while decreasing our time to customer value across multiple products and delivery teams.
1. INTRODUCTION
“You never want a serious crisis to go to waste. And what I mean by that [is] it’s an opportunity to do things that you think you could not before.” – Rahm Emanuel
Six months before switching floors I asked for the large wall in the entryway of the fourth floor on which the design, engineering, and product teams would be moving to have floor to ceiling magnetic whiteboards installed. Around the same time we had a small reduction in forces reshaping our organization’s profile to strengthen our team to go up market and acquire more enterprise customers. With that, came more required rigor. Fortunately, we learned about Enterprise Service Planning just as these changes were taking place.
2. BACKGROUND
Optimizely was formed in 2010 having completed a successful Y Combinator startup program. Optimizely offered easy setup for A/B testing. Simply by inserting a single line of JavaScript, someone could start running A/B tests on their website. By 2013, having grown to more than a dozen engineers, product velocity had stalled due to increased communication bandwidth, lots of work in flight, and too many priorities. In 2014, I was hired to help the teams deliver better.
By the close of 2015, we had been running sprints for over a year and a half, and the benefits began to wane. Though we had solved our original problem of product velocity, people were beginning to tire of the sprints themselves. We experienced local optimization since teams were working off their own backlog, often on work that was lower priority than items on other teams’ backlogs. Sprint reviews were poorly attended and retrospectives had become a chore. Innovation, outside of the twice yearly hack weeks, was difficult with not enough time spent on discovery, customer development and prototyping. Critical bottlenecks existed due to the scarcity of some technical skill sets. Something needed to change.
3. ENTERPRISE SERVICES PLANNING
A series of events happened in late 2015 and early 2016 that precipitated our move to Enterprise Service Planning.. First and foremost, was my discovery of a slideshare by Janice Linden-Reed titled “Kanban Cadences & Information Flow.”[1] It is here that I discovered Enterprise Service Planning (ESP) and the kanban cadences.
David Anderson, the originator of Enterprise Service Planning, describes it as “a way of planning, scheduling, sequencing, and selecting work for professional services including all forms of knowledge work and creative work.” [2]
Enterprise Service Planning allowed us to see our company as an ecosystem of interdependent services, where a service is a capability of the system with inputs and outputs with customers, partners, and stakeholders. Figure 1 below is an early attempt to map the various services Optimizely had and how they interacted. Though it is an incomplete representation of all our services (for instance, Legal is missing), it is illustrative of the size and complexity of the services that many companies have.
Figure 1. Services within Optimizely by Jeff Zych
Now that we had identified our services and their most common interactions, we focused on untangling the services associated with our design, engineering and product teams. These included: the product delivery service focused on customer value; the developer productivity service which served our internal development teams; our information services, like IT, Business Systems, and Data Warehouse; and our security, compliance and privacy service, which supported and inputted work into all the other services.
Understanding that our company was an ecosystem of interdependent services by visually mapping it out and seeing the observed capability of each service enabled us to shape demand by showing the past performance of the system, and forecasting in a meaningful and impactful way what would be delivered when. It was not precise, but it was accurate enough, and our forecasts allowed our business to make decisions more quickly with better results.
As you will see later, we focused on visualizing the product delivery service by creating a fifty foot information radiator, affectionately called the “Wall of Work” or WoW board. Some other services were visualized physically as well, including the adjacent information services teams. For teams that did not build physical boards, such as Marketing Automation, Legal, Real Estate and Workplaces Operations, we were able to electronically observe their capabilities since they used Jira to organize their work.
We observed that services may combine or split apart over time depending on evolving organizational needs and structure. For example, over time a couple adjacent services – product education and developer productivity – joined the product delivery service and were added to the wall of work. The former to better align on customer value creation and documentation quality, and the latter due to shared resources and to reduce friction.
4. THE WALL OF WORK
Six months before the design, engineering and product teams switched floors I asked the head of Real Estate to have floor to ceiling magnetic whiteboards installed on the large wall next to the main entrance to the floor. Not only would all the designers, engineers and product people walk by it everyday, so would the CEO and anybody else who had a meeting on the floor. Figure 2 shows the Wall of Work in early 2019.
Figure 2. Wall of Work (early 2019)
The benefits of a large physical information radiator have always felt obvious to me: visibility, transparency and alignment on both the process and the work. It is one thing arguing over a line item in a spreadsheet, an issue in a ticketing system, or an update on a slide. It’s an entirely different matter to be confronted by all the work in flight in relation to each other as they navigate through the various stages of a system’s workflow.
Two stories illustrate the benefits of a big visible information radiator. One day the CEO was talking with the Head of Design about some work that was not yet in flight. The Head of Design promptly walked the CEO to the wall of work and asked him which work that was already in flight should we stop working on. The CEO reviewed all the work in flight and decided that the new work was not as important as the current work in flight. The entire conversation took less than five minutes.
Another time, there was a lot of talk about all the cross-team dependencies we had. To help illustrate this, I attached string to work items that were dependent on one another. Not only did this show some obvious challenges with how we structured the teams and their work, it also allowed us to proceed with completing the work as best we could. Finally, when the dependencies had been resolved, people took turns triumphantly cutting the strings. Subsequently, we also changed how we managed dependencies, primarily by not starting work with dependencies until it could be properly supported.
The wall also helped us evolve our process over time. In particular, it moved from a focus on what was in development and moved both upstream and downstream over time, allowing us to create an end-to-end customer board. Requests, options and ideas would enter on the left side of the board and go through several discovery phases, such as define, design and decide (a queue from which we could pull work that was ready). When work was brought into development, it would cross the commitment line that we had marked with red tape on the physical wall. It was from this commitment point that we could forecast delivery of each item as the work traversed through the develop, deploy and delight phases (deploy consisted of all the work that was in the hands of a single customer all the way until it was rolled out to one hundred percent of our customers).
5. THE KANBAN CADENCES
Perhaps the greatest takeaway from Janice Linden-Reed’s slides were the kanban cadences – seven different meetings, the content of these meetings, and how they interact with one another. Even more helpful were the topics to be covered in each meeting and the kinds of questions to ask in each meeting. I particularly appreciated the statement on slide 17 of the aforementioned slides: “The following meeting descriptions are just typical configurations! You should adjust frequency cadence, duration, attendees based on your organization’s needs. You are likely to adjust over time.” And we did.
While seven meetings and their frequency (cadence) are suggested in the original slides, we have now evolved to nine meetings. Figure 3 below shows these nine meeting and their current frequency at Optimizely.
Figure 3. Kanban Cadences as currently implemented at Optimizely
Upon discovering these cadences, I began by overlaying our existing meetings over them, including the Scrum rituals. For instance, daily standups were both a cadence and Scrum ritual. I supposed the replenishment meetings were similar, or at least occupied, the same space as the Scrum sprint planning meeting. I also considered our existent sprint reviews and sprint retrospectives as similar in nature to the goals of the service delivery review. We had twice yearly strategy review meetings as was suggested in the original slides. Though these meetings were not exactly the same, they were close enough when we first started.
More importantly, were the two suggested cadences we were missing and had no analog for – the operations review and the risk review. These were the gaps we needed to fill first. Our executive team and other key leaders including myself started participating in a weekly operations review that looked at key metrics and services each week for an hour. We also started up, albeit ad hoc, risk reviews. Rather than having a set cadence or meeting for risk reviews, we would follow up with people about risks or weaknesses as we uncovered them in the operation and service delivery reviews. These as needed risk reviews might take the form of a current reality tree or a working group that focused on an area or issue until it was deemed fit for purpose, or good enough.
Some meetings changed over time too, such as the delivery planning meetings. Originally, we had quarterly release planning meetings. However, after several years we removed these due to their inefficiency and replaced them with a delivery planning meeting per large work item, or epic.
As mentioned earlier, the seven cadences as originally proposed were just guidelines, and served as a good starting point. I recommend reviewing the original slides for more details about each meeting. Below I will briefly describe each meeting and how we used them.
The following three meetings ensure the right thing is being built at the right time. This involves a lot of forecasting, limiting work in flight and having a culture of continuous learning, big and small.
- Strategy Review – we were already having these twice a year, a couple months before the new fiscal year and the second half of the year began. They consisted of several days of presentations, discussions, and fun activities. All product managers attended and leaders from other groups, such as design, product education, and engineering, were also invited to participate.
- The Wall of Work Walk – this was a new meeting we added. This meeting is held weekly and is the tactical compliment to the twice yearly strategy review. This meeting allowed us to maintain alignment between the company strategy and all the teams, while also giving us the opportunity to swarm on high value and high risk items.
- Team Planning, or Replenishment, Meeting – these varied team by team. I suspect the best sprint planning meeting could resemble a good replenishment meeting, with all the stakeholders present, hearing each other’s requests, and understanding the implicit prioritization of these requests. The team in turn would show how they were performing and be able to forecast the next set of requests delivered. Both the stakeholders and the team would pick together the next items to be worked on.
The following three meetings focus on each team delivering value, and all are mentioned in the original seven cadences.
- Team Planning, or Replenishment Meeting (also listed above) – served to align the team with the system. The replenishment meeting was when the team decided what would be worked on next.
- Team Standup – a common practice and a great habit for new and old teams alike to keep coordinated and remove impediments.
- Delivery Planning – this meeting evolved over time. At first it was a quarterly release planning, which tied nicely into quarterly OKR planning. Overtime, we removed quarterly release planning and instead focused on a delivery planning meeting per large work item, or epic.
Our delivery planning meeting changed for a variety of reasons. First, teams already had work in flight from the last quarter that rolled over. Second, teams and their products had different rhythms that did not always fit neatly into a quarterly (thirteen week) cycle. Ultimately, the stop and start nature of quarterly release planning hindered our more nimble style of play, and the benefits of four weeks of release planning a year were far outweighed by the economic cost of development slowdown during this time.
The third and final set of meetings help improve the system.
- Service Delivery Review – the meeting that connects the team and its delivery capabilities with customers, partners and stakeholders. These tend to happen once or twice a quarter per service.
- Operations Review – at Optimizely this is a weekly, hour-long meeting where we review all the services and how they are performing. Risks and weaknesses are identified at this meeting, and an owner is assigned to follow-up.
- Risk Review – this represents the meeting called between stakeholders and service leaders to improve, and sometimes fix, a particular service or set of services. This meeting is not formally set in our system. However, the function it provides does exist at Optimizely. We practice kaizen, or continuous improvement, at every level and at every opportunity.
- OKRs (Objectives and Key Results) – we added this to our cadences. Our quarterly company goal-setting and alignment process was not a single meeting; rather it was an up, down and across process that lasted several weeks spanning the quarterly boundary. It helps the company as a whole keep alignment. It also builds trust in the system and across the organization over time.
Some of the meetings are more obvious than others, and some of the meetings I was not running or able to run as well as I like. I recommend starting with the original seven cadences and mapping them to your current meetings. You may discover you are missing one or more of the cadences like we did. Over time you may also add some new one when you perceive gaps in your system. We added two cadences – the Wall of Work Walk and OKRs – and this could change over time. Do what you can do now, and see what you can get away with later.
6. WHAT WE LEARNED
Implementing Enterprise Service Planning has helped our company survive and thrive in an ever changing world.
Recognizing that our company was an ecosystem of interdependent services and mapping them out, we were able to ensure that the right people were talking to each other. We were able to observe each services capabilities and adjust them as necessary.
Creating the Wall of Work, allowed us to communicate with the rest of the company in ways we did not before. We were able to easily share clear, concise updates every week with our counterparts in marketing, sales, success, services, etc. It gave our downstream partners visibility into what was coming towards them – and what was not – and it gave them the opportunity to participate wherever and whenever they wanted.
By implementing and evolving the kanban cadences, we were able to optimize the system for throughput and quality. We were able to identify bottlenecks in the system as they came about and remove them as expediently as possible. We were able to innovate new products and services. And most importantly, we were able to observe our delivery capabilities for each service, which in turn allowed us to forecast more accurately with less effort so that the company could achieve its business goals while minimizing risk.
The gift of hindsight can be 20/20. There are things we could have done differently and, perhaps, gotten to where we are today faster. Sometimes I wonder if we should have rolled this out more formally, and/or faster and/or with external support. Would we be where we are today, or maybe even somewhere better, if we had tried to do it more formally, faster, and with external support, I’m not sure. That being said, I did take a couple classes with David Anderson and Alexei Zheglov to help me with kanban and Enterprise Service Planning. And I read and re-read Janice Linden-Reed’s slides a hundred times.
7. ACKNOWLEDGEMENTS
I would like to thank Rebecca Wirfs-Brock, Susan Burk, and Tarah McMaster for their patience, support and encouragement. I would also like to thank all my fellow Optinauts, past and present, who have gone on this journey with me. Lastly, this paper and everything it describes would not have happened without Janice Linden-Reed and her “Kanban Cadences & Information Flow” slides.
REFERENCES
[1] Linden, Janice. “Kanban Cadences & Information Flow” https://www.slideshare.net/agilemanager/kanban-cadences-information-flow
[2] Anderson, David “Q&A with David Anderson on Enterprise Service Planning” https://www.infoq.com/news/2015/11/enterprise-services-planning/
