In this four-part series, I will share practical tips to help get you get to a place where process doesn’t hinder innovation or agility, but is an essential part of it. Today’s post, Part I, will explore the quarterly cadence Tasktop follows to enable coordination across the entire organization and ensure that we deliver successful releases on a regular basis.
Part 1: Organization-Level Coordination With the Quarterly Cadence Process
Tasktop’s products serve as the glue that bonds the ALM, PPM, and ITSM tools in organizations’ tool landscape. However, we recognize that developing software goes beyond using best-of-breed tools to manage the artifacts that represent the work. Teams outside of the planning, development, and support spectrum play a huge role in the success of a software product throughout its lifetime. Departments like Sales, Pre-Sales, IT, Business Development (BizDev), and Marketing are crucial to a product’s success, and their contributions must be accounted for when coordinating across an organization, especially given the set of dependencies that exist across these and other departments.
Our ability to coordinate across our entire organization is a key component of our success. We’ve been able to accomplish this cross-organizational coordination via what we call the Quarterly Release Cadence. We’ll explore how and why it developed and what it entails shortly, but it’s important to emphasize that though a cross-organizational cadence might seem heavyweight, it’s actually done wonders to keep things moving smoothly across our growing organization, and to evenly distribute the workload and responsibility for release after successful release by giving each team the luxury to focus more of its time on innovation and creativity rather than getting delayed by confusion.
The Quarterly-Release Cadence is crucial not only for coordinating across multiple teams, but to do so while the organization is simultaneously focusing on past, present, and future product versions. We’ll explore these three timeframes and, as we do, it should become apparent that without a process in place managing them concurrently would be untenable.
Here at Tasktop, we regularly look ahead to and prepare for the future. We believe that a successful organization needs to define a vision to serve as a long-term guide for the next few quarters and beyond. And this strategy needs to be evaluated continually to ensure that it’s adjusting to changing market needs. This means we are regularly consulting and adjusting our long-term roadmap, which in turn influences our focus in the shorter term for, say, an upcoming release. And preparing for an upcoming release is a substantial effort in and of itself. To ensure Tasktop’s Engineering group is ready to go when the first sprint of a new release cycle starts, multiple teams work ahead to help determine what we should focus on in a given release and provide features with sufficient definition and direction.
Before Engineering starts to code, they need to know what new features and connectors they’ll be building along with the rough scope and design of those features. Compiling this generally well-defined list is no easy feat. Our connectors are a great example of this. Tasktop integrates a number of systems in the ALM, PPM, and ITSM spaces, and we do so by building connectors to those systems. But before we can start to build such a connector, there are a number of critical steps that need to addressed:
- A list of which connectors we’ll be building for the system we hope to be able to integrate (Management), influenced by information furnished by our field team (Sales, Pre-Sales, Solutions, BizDev).
- Business analysis, to analyze and understand the end system (Product).
- Technical analysis, to evaluate what is technically possible given that system’s APIs (Engineering). Note: This requires access to a given system with a proper license and an environment setup (BizDev and IT).
The new feature side is similar. Before we can build specific features, we generally need to do the following:
- Undertake business analysis and design work (Product/UX).
- Understand technical feasibility and tradeoffs (Engineering).
- Gather input from the field (Pre-Sales, Sales, and BizDev) to know where we should be focusing our time and energy and what would best constitute the feature.
Because of these dependencies, preparation for a given release starts weeks, often months, before the actual opening day of the release. At Tasktop, in fact, we have concrete planning steps defined for the next release as early as Sprint 2 of the current release. Does that make us un-agile? We would actually argue the exact opposite, given that our Quarterly Release Cadence and release preparation process has steps built in to help us react to new demands and ensure that information about our delivery expectation changes is propagated to the right people in the organization at the best time (we’ll explore this more in parts 2 and 4).
Our process reminds us to continually look forward and take actions to define and prepare for what is next in a targeted and reasonable manner, reducing the scramble that would frustrate everyone in the absence of any preparation.
Our preparation for future releases is largely done out of recognition that having release plans and rough feature designs helps kick start teams to build valuable features and ensures that what gets built is actually useful. Indeed, coming into a given release or sprint empty handed would be highly unlikely to produce stories and features with concrete user value in a fixed amount of time. So, though we roughly define and scope features during planning, our aim is never to specify every last detail about a new connector or feature ahead of time. And, inevitably, the ongoing development work exposes even more nuances and questions that need to be answered. Is this particular connector capability important? If so, Product and BizDev might need to consult a partner. How should this new interaction behave in a particular scenario? For that, Engineering needs to work with the Product group. As we can see, the amount of cross-team communication during current feature development can become extensive.
In addition to refining and executing the features planned for a given release, the organization must also handle new requests that we might not have been aware of or that didn’t exist when a release came out. Being able to react to these requests while not distracting Engineering (or thrashing) is key, so we have a process to help us with this as well (we’ll explore this in Part 2). It involves ensuring we have enough information to evaluate the urgency of a given feature and, when necessary, can fast track it for that release, making appropriate tradeoffs to do so.
All the while, there must be organizational-level visibility during a release cycle so that people can know what to expect at the end. Changes are inevitable, and communicating about those changes is essential to ensure that everyone’s expectations align. Tracking the limitations of features as they are built is also important. This continual communication and documentation also facilitates some of the activities led by other teams after a release is complete from a coding perspective.
All of this goes to show that, of course, we have to do a lot of work in the present for the present to keep things running.
Just as there is much that happens before a new feature or connector is built and, of course, while it is being built, much happens afterward. When we develop a new feature or connector, it’s ultimately useless if existing customers and prospects aren’t aware of it, and if our own deployment team doesn’t fully understand it.
Our launch date is a few weeks after the GM build date. Even though the code is written and the build is complete then—and the Engineering group has already begun working on features for the upcoming release—much of the organization is still working on the one about to be launched. With input and notes from the Product team, Marketing is hard at work creating and putting the finishing touches on all materials needed for our launch and making sure the release is being marketed via the appropriate channels, including updates to our partners via our BizDev and Product teams.
Meanwhile, Sales must learn details about the new release’s features so the field can help prospects evaluate and customers deploy the release effectively. Staff from Product, Engineering, Marketing, Pre-Sales, and Sales all work to ensure that the field is successfully enabled in the weeks after code freeze for a given release. Add to this the fact that once a release is successfully out the door, announced to the public and understood internally, there remains the ongoing support process for the lifetime of that product version. So, in addition to preparing for the future and advancing features in the present, all of Tasktop’s departments also deal in the past regularly.
Making Sense of It All: The Quarterly Cadence
How do we make sense of all of these cross-team dependencies and succeed in a world where we simultaneously have to think about the past, the present, and the future? Tasktop’s answer is what we call the quarterly cadence, a diagram that lays out what each group in the company needs to be doing when to ensure the success of the last, the current and the next releases. You can see the outline of ours below:
Note that each department is represented. Their contributions and responsibilities show up in the color-coded diagram. Note also that the diagram aligns the sprints of a release cycle to the months in a quarter—this is essential for everyone to achieve a common understanding of when the when really is, as some of the teams think in sprints (Product, Engineering), while others conceive of time more in quarters (Sales, BizDev, Marketing). This diagram is the best way we’ve found to show activity across the company that happens for each release cycle—in a way that makes sense to everyone.
Origins of the Quarterly Cadence
The genesis of the quarterly cadence was documenting known dependencies across the organization. Those dependencies were easy to see, at least for the very obvious parts of the equation. In fact, this was one of the earliest projects our department took on after I was hired as the first full-time business analyst on the product team. Once dependencies are documented, you can start at either end, see the progression of deadlines, and identify who is responsible for tasks (which sometimes takes negotiation and discussion across teams). Only when all of these aspects are understood and agreed upon, and when their importance is acknowledged, can a company march to the same cross-organization cadence.
As stated, identifying the dependencies was relatively easy—it was the subsequent steps (figuring out what needs to happen by when and by whom) that took more time. Though we had an earlier version of the diagram shared above in the fall of 2013, only since the waning months of 2015 have we fully internalized and reliably followed the quarterly cadence. In the time in between, we were sorting out those sometimes hard-to-agree-upon details.
The quarterly cadence serves as our overall guide but is backed by some more detailed documents that highlight lower level activities that go on each sprint to enable the high-level processes/deliverables shown in the diagram. Keeping the diagram at the right level has been important for us. Including too much information on it would confuse everyone and render the diagram useless.
Today we follow this cadence regularly, with some oversight by the Product team (we start and end each week by consulting it during our standups). As time passes we’ll continue to expand it to include new deliverables and dependencies. Our hope is that one day we’ll have this published for all to see in our offices and, with the ability to add and remove layers to the diagram, departments can have their own printouts that show the activity most relevant to them.
While it may seem counter-intuitive, it’s actually lightened everyone’s workload. Placing the responsibility on individuals to know what needs to get addressed and chase others down to make things happen is unproductive. Because of the quarterly cadence, team members understand the implications of certain activities not happening at a given time. It also helps that everyone now sees the fuller picture beyond his or her particular view of the world. And best of all, because we own this process, if it’s not working out, we can work together to change it so that everyone is benefitting from it. After all, process for the sake of process doesn’t make sense.
- Start by drawing the diagram that illustrates the dependencies at your organization. The original version of our quarterly cadence was made in PowerPoint, but even a simple sketch could suffice to initiate conversations. Having the dependencies documented, though seemingly simple, is key to helping all parts of the organization realize the importance of having a quarterly cadence.
- Start with deliverables and deadlines and work back from there. Establishing what needs to be done by when and by whom is perhaps the most difficult part of establishing a cross-organization plan. In the legend for our diagram above, you’ll see that we differentiate between deliverables, milestones, processes, and meetings. Identifying these different components helped us work through everything.
- Work with each team in your organization to make sure that what is important to them is represented. It’s much easier to get everyone to march toward the same goal if they feel included in the process and see how it will benefit their team.
- Be patient, but insistent. Working through all the details can be time consuming and tiring, and acknowledging little victories along the way will enable you to make it through the process. Ensure you continue to push forward. Change isn’t easy and won’t happen if someone isn’t pushing the issue.
Finally, acknowledge that iteration and evolution are key. It would be impossible to get everything included and right the first time. In fact, talking to other groups to get things going initially is necessary and will mean a lot of adjustments while trying to establish the process (but it’s a good thing since the cadence will be refined to work more easily for more people!). And even when your organization adopts a cadence, as the company changes and/or grows, it’ll constantly need to evaluate what is and isn’t working, meaning the process will evolve over time—another positive outcome.
And there you have it—a real-world example demonstrating that process at an organizational level, when implemented thoughtfully (gasp!), can actually help enable agility.