Or “What is the Benefit of Having a Cadence of Meetings?”

Or “Should We Establish a Common Cadence for Planning for Our Organization?”

As we transform organizations to execute in an agile way people often resist the notion of regularly scheduled events such as Iterations / Sprints, Program Increment (in a SAFe implementation), quarterly Portfolio Planning, and so on.

There are a number of reasons for this resistance:

• Leadership cannot be at all places at once: For example, “I am an executive of an organization with 15 Trains. How do I get to all these Planning events if they all happen in the same week?” Or “I am a Product Manager of a product with 10 Teams working on it. How do I get to all the demonstration events of these Teams if they all occur on the same day?”
• Logistics: For example, “I am handling logistics for a Train Planning event. There are 14 other Trains trying to reserve space in this building for a colocated event at the same time? How do I get my meeting scheduled?”
• Philosophical: For example, “We don’t have anything to do with these other Trains or Teams. Why should we schedule our work on the same cadence as other Trains / Teams?”

Most organizations have some level of cadence (for example, yearly budgeting) which is often the cause of a lot of resentment and so it comes to a surprise that agile approaches often drive to establishing a cadence. Agile implementations leverage the notion of a cadence all over the place. For example:

• For Iterations / Sprints we have regularly scheduled ceremonies such as the daily standup, iteration demo, iteration planning and so on.
• For Trains (Program level - team of teams) we have ceremonies such as the scrum-of-scrums, Product Owner synchronization, systems demos, and so on.
• For Portfolio, we have regular ceremonies to make decisions on priorities.

Even pure Kanban teams will often leverage the notion of a cadence so that while they might not adopt a cadence of ceremonies, they will often establish a delivery cadence where they commit to delivering software on a regular schedule (for example, a team might commit to releasing solutions every four weeks). Note that they don’t commit to a specific set of work items that will be included with the release. Instead, they trust their system to deliver work items in priority order. Further you will often see Kanban teams schedule ceremonies (eg team demonstration, and team retrospective).

What is the benefit of these cadences? A cadence turns out to be a base organizing principle. Think about it. If we know absolutely nothing else about what is going on, we can say “let’s see where we are every two weeks” and, while you don’t know anything today, you can set things up so that you find out something in two weeks time, and then the subsequent two weeks, and so on.

Cadence functions as a heartbeat for the organization.

Cadence also becomes a natural time box which allows us to not only to define events that occur regularly but also specify due dates when things are expected to get done. If you combine this idea with the idea of “synchronization” (multiple events happening at the same time) cadence offers a lot of benefits:

• As a base organizing principle, cadence turns unpredictable events into predictable events.
• The time box forces us to make decisions, and stops us from procrastinating. This is something I’ve learned about myself. If I have a due date, I will work to that date. Anecdotally, I once worked with a Team where the question came up “do we really need to do a demonstration?” We decided not to, and the result was that the Team produced about 50% less than in previous Iterations.
• Cadence-based planning limits variability to the time box. By having the time box you can only stray so far from the plan before another event comes along which offers the possibility to correct (based on the new knowledge you have). If you are heading in the wrong direction, you can make an adjustment and, if the time box is small enough, you have limited impact of that wrong decision and can easily change direction.
• Cadence helps smooth the work and therefore makes it more sustainable. If we are planning to a 2 week iteration for example, then there is a limited scope we can do in that period, and limited impacts that can occur, so it’s easier to commit to and do this amount of work helping to building a sustainable pace.
• Cadence makes wait times more predictable. The heartbeat says “every two weeks” or “every quarter” there is another event where you can engage. Average wait time is half that interval.
• When working a set of work that crosses Teams (or Trains), cadence allow us to more easily synchronize activities; is it in this time box or the next time box. While this may seem obvious at a Feature level (I.e. multiple Trains or Teams working together on a Epic or Feature), it can also be used to synchronize organizational (for example, we need to change business direction), personnel (for example, we need to move work to this offshore center), and process issues (for example, we need to adopt this more effective approach to security).
• When working at multiple levels aligned cadence allows two-way flow of information between the various levels: plans come down and feedback goes up. A multi-level cadence is when we have iteration cadence for Teams (say every two weeks) and a quarterly cadence for the Program, and so on up the levels of an organization. For these cases to work well, the sub-cadence should be a whole subset of the major cadence. For example, if the Program is running a 12 week cadence, the Teams would look to running a 2 week cadence as these sub-cadences would line up exactly with the Program cadence and so allow maximum flow of information.
• When working a set of work that requires synchronization, cadence allows us to pull things together and objectively see what we have done. We can easily set up an integration of all the work because we understand what is available at each and every cadence point. You can say “by the end of this time box we expect to see all this working together”, including testing of the integrated solution, and use that demonstration to determine what’s next (pivot, continue, stop).
• Cadence, with a buffer, allows us to deal with uncertainty. We know what we are need to achieve and because we have a buffer, as we discover things or as we are impacted by others that effect our plan we can make adjustments. For example, if the business cannot wait for the next planning event or if we learn something that will allow us to leverage more value out of the work, we can still deal with that situation.
• If you can’t predict delivery, existing programs become feature magnets. A regular, short time box of delivery helps build understanding of what is a priority, what is up next, and what is possible (capacity). This reduces the need to say “yes” to anything feature request by encouraging business level discussions on what is important.
• Cadence helps us to develop the habit to do the important things, not just those currently considered urgent. It helps by scheduling these in advance, thus making a habit of it and providing the capacity to do this. Specific examples of this include the retrospective; which we schedule in advance to ensure we take the time to get better. Similar things can be said for planning meetings to ensure we have taken the time to plan and not just respond to the latest event.
• Cadence helps to reduce the need for ad-hoc status meetings. If we know that the next demonstration is in two weeks time, do we really need intermediary status meetings.
• Cadence helps when tracking metrics. There is a natural time-box which, when complete, you collect the metrics. There is no question of what time period the number applies to since it is that same time-box each time.
• And, more simply, when working a meeting, it can save effort in setting up a meeting. We know we are going to meet every two weeks on this subject, so lets just set the time / agenda / etc up now. For all future events, while we expect preparation work, at least it is not at the level of the base logistics.

Notice that the above benefits accrue whether we are operating at the portfolio, program or team level. In fact, if we apply this thinking at all levels, and have a common cadence for the whole organization, these benefit will multiply. That is why we try, where possible, to develop a common heartbeat for the whole organization.

At the highest level the cadence for your shop should be set up based on what makes sense for your business. If, for example, your work is in response to a competitive where the competition is delivering every few weeks, then a quarterly planning session will have limited value. Or if your customer base is unable to accept delivery of new features every quarter, then perhaps a release needs to be established for other business concerns (e.g. marketing might want a regular release of features to coincide with planned workshops).

In a lot of shops I’ve worked in, there is no strong business cadence driver except the yearly budgetary cycle, so we set one up to leverage the benefits. There will be different cadences for different levels of the organization, and the key is to fit these cadences in each other so that everything lines up at critical times. With the budgeted cycle defined yearly, and a “need” to make more regular adjustments based on what we are learning, a typical cadence for an organization will be:

• Yearly: Budgetary and Portfolio
  • Quarterly: Program and Portfolio
    • Bi-Weekly: Team and Program

Notice that teams will have one level, programs another, portfolio another. The key idea is to set sub-cadences so that they start and end on the same dates as the overlaying cadence.

This also provides for another couple of opportunities:

• We don’t have to have the same people involved in every level. For example, we can invite people directly interested in a new capability to attend bi-weekly team demonstrations to provide immediate feedback, while more senior people could attend a program level system demo to ensure we are heading in the right direction from an overall perspective. This type of thinking can be applied to other events as well - planning, retrospectives, and so on.
• When we find that a scheduled meeting doesn’t pull together the information we need, we can set up specific meetings to address those concerns around the cadence that has already been established. For example, let’s say we have a project which has work on 3 trains and we want to understand the current planning for that deliverable. What we could do is set up a pre- and post-quarterly (PI) Planning event to help understand “what we need” and then compare that with “what we will get”.

So what does this look like in reality? We might see the following setup for a 2018 2nd Quarter schedule:

• March 26 - April 3:
  • Portfolio Planning Workshop
  • Pre-Quarterly (PI) Planning meeting for special initiatives.
  • Quarterly (PI) Planning events for each of the Programs (Trains)
• April 4 - July 3: Quarterly execution. Program Increment for the Train
  • April 4: Post-Quarterly (PI) Planning meeting for special initiatives.
  • April 4 - April 17: Team iteration
  • April 18 - May 1 : Team iteration
  • May 2 - May 15 : Team iteration
  • May 16 - May 29 : Team iteration
  • May 30 - June 12 : Team iteration
  • June 13 - June 26 : Team iteration
  • June 27 - July 3 : Team iteration (note short week because 52 weeks means 13 weeks is the norm)

For large organizations you will see some level of scheduling of Trains / Programs and for logistics reasons alone which will require some level of offsetting. A couple of ideas that may help:

• As much as possible try to schedule Trains / Programs that have significant dependencies so they line up. Done properly this will help with planning, progress tracking, and so maximize the benefit.
• Another idea (that I have not tried, but has come up in conversations a couple of times - can you say “experiment”?) is to schedule the cadences so that all the (2 week) Sprint / Iteration boundaries are common across everything. So if we are doing quarterly planning and we have two Trains / Programs, we could set up the planning so that one Train / Program plans on week 1, and the second on week 3. This way integration points (for example, common demonstrations) will fit on to normal Sprint / Iteration boundaries. This, in effect would allow you to maintain the heartbeat.

Most organizations do not magically get everyone on the same cadence at the same time. Organizations tend to grow into it and, as the portfolio level is setup, there is increasing imperative to make it work (because of the benefits seen). Most large organizations still do not get to “all quarterly planning will be done the first week of the quarter” for a number of practical reasons (e.g. no one is at work at the beginning of a new year). So, for example, a number of places I’ve worked see quarterly planning “over a couple of weeks at the beginning of the quarter”. In most cases this is not a problem, and the benefits will still accrue. The key thing is to get close to a common cadence.

The other problems we see are reflected in the areas of resistance listed above.

• Leadership cannot be at all places at once: These cadences provide a new opportunity for leadership. Their participation can be focused on where they provide the most benefit. While most leadership feels like they need to be involved in everything, we are setting things up so that in the normal situation high value work is going to be done (and we should be able to trust that is will get done). There should be less of a need to be “everywhere” just in case, and more of an opportunity to focus our efforts.
• Logistics: As said, pragmatically most organizations set things up so that “all planning is on this week” and the main reason is logistics. Logistical reasons can include things as simple as room availability and as esoteric as bandwidth availability. However once the base schedule is set up, the good news is that this discussion does not have to be revisited. We can use the same sequenced schedule going forward.
• Philosophical: The main objection is related to the notion that teams are “self managing” and that therefore they can do “whatever makes sense for them.” This is a misunderstanding. Nobody does an agile transformation to “be agile”. We are doing it to solve business problems. For many, synchronization of value delivery across multiple teams is a business problem. One approach to deal with this is to establish a common cadence. The business environment defines some of the guardrails of team self management in this instance. Care must be taken when establishing this idea - we need to help the teams understand why we should do this.