Locking Cadences to Optimize the Whole Scaled System – Not Really…

I had a reminder through some recent comments that people view locking cadences in step as a means for optimizing the whole of the system and not for individual teams (by allowing them to choose the cadences at which they wish to deliver).  this is used to justified in the case of when you have a need for a program.  I think this is missing the point, so I am going to go through some explanations.  I really like how Jurgen Appelo has applied David Snowden’s Cynefin framework to work systems so I am going to illustrate my rationale using some of his work.

So let us start with a team:

Programs_Explained_in_Mgmt3.0_speak-1Teams are simple to understand, predominantly because of their simple structure with few people; however they are  complex in nature because we are dealing with humans.  Sometimes we can’t even predict our own behavior, much less a whole team’s.  Next, let’s think of where most policies and processes wind up…Programs_Explained_in_Mgmt3.0_speak-2Good processes (and their accompanying policies), try to add order into systems; this is particularly true of many of the scaling systems out there (SAFe, DAD, to some degree LeSS) where structure and process is imposed on the ‘program’ system in order to achieve more predictability.  Unfortunately most of these are quite complicated in nature; some have helped by providing well diagrammed (some even animated) pictures, but there is still no denying the complicated nature of their arrangements to attempt to get predictability.

This is very well intentioned, yet what happens in reality is the following:

Programs_Explained_in_Mgmt3.0_speak-3The complicated-ordered process thrown on a simple-complex team yields a complicated-complex result.  This isn’t achieving what we wanted… and we’re just talking about a single team! And if we expand this to many teams such as we would have in a program, this is the best case we can hope to achieve.  It may become complicated and chaotic as the additive results yield less predictable results. Programs_Explained_in_Mgmt3.0_speak-4So why is this happening?

It’s because we humans create complex social systems.  There’s a reason why we value individuals and interactions over processes and tools; the latter can be complicated in nature perhaps and yet they are ordered in nature, while people systems can be either simple or complicated, yet are always at best complex.  People aren’t robots, so our behavior is never entirely predictable.

And yet… we try and put systems in place that have unintended consequences, such as imposing cadences on teams to get more order (predictability) out of them.  Think about the last time you had something forced on you that you disdained; it probably had you at best working at less than motivated – it sucked the motivation out of you, so you didn’t perform as predictably as desired. And at worst case, you went and found a new job and now the team was thrown into reforming and restorming to get back to renorming and performing.

Each team and its individuals will be different, perhaps some won’t care that much about the ‘normalization’ of cadence.  But some will have deep negative impacts that will occur.

So I ask you what ‘system’ are we trying to optimize? The process or the people?  Imposing a process to de-optimize how humans perform seems to me have many potential negative longterm effects; besides losing good people or demotivating people, even if this happens to only one team out of ten, it sends a signal that people don’t control their work system at all, that any element can be changed on a whim. Basically apply the pants principle and let teams adopt as simple a process as possible, including the orchestration.  As Saint-Exupery said, simplicity is not achieved by deciding on not when there is more to add, but deciding on when there is not more to take away.

Programs_Explained_in_Mgmt3.0_speak-6 Does this mean that locking cadences can’t ever be adopted? Not at all… Facilitate teams to select a good cadence within themselves firstand then collaborate with other teams to find how to best orchestrate delivery.  This may result in lockstep cadences or perhaps a creative branching and merging strategy. This could be done during team chartering by holding a futurespective. Regular intra-team retrospectives could help teams identify when changes need to occur. Simply installing a locked cadence at the beginning may result in a sub-optimal approach as it overlooks the people part of the equation.

6 thoughts on “Locking Cadences to Optimize the Whole Scaled System – Not Really…

  1. Great points Paul. I’m definitely guilty of doing this, while not directly applying SAFe or any specific framework I’ve definitely required teams to follow the same cadence. Good things to think about…

    Like

    Reply
    • Thanks Matt – I’m not opposed to cadences being locked, but it’s an orchestration problem that can be solved by the teams themselves and not needing to be imposed by any approach.

      Thanks for the input on the convo!
      Paul

      Like

      Reply
      • Definitely. I’ve stopped other mandates before saying that the team can solve that on their own (often something to try to avoid a potential problem down the road which may never even occur). Time to practice what I preach I guess 🙂

        Like

  2. Pingback: Locking Cadences to Optimize the Whole Scaled System – Not Really… | Paul Boos | Development Block

  3. Paul, I appreciate the cleverness of this model. However, I find applying David Snowden’s Cynefin framework to this introduces unnecessary complexity to the issue. I find it easy to handle with a couple of relevant principles.
    1. iterate faster to course correct and improve process faster.
    2. for release dependent teams, have the synchronization be identical or a multiple of the shortest one, e.g. 2-weeks for some and 1-week for those able to cycle faster.

    One additional point, I have no problem making the Scrum overhead scale proportionately to the Sprint length. So there is no disproportionate overhead with shorter Sprint cycles. Of course, with new team just learning the discipline, everything takes longer until habituated.

    I like to keep it simple. Philosophically it’s like Plato vs Aristotle. Aristotle says things are what they are and we learn about them by interacting with them (poking at them in my words). Plato says true reality is in an unknowable realm… you can guess where that leads in identifying a learning process – in circles. 🙂

    David Snowden’s Cynefin framework is intellectually intriguing, but I find practical problems can be more simply, effectively analyzed – part of which is reducing complexity to the essentials.

    Like

    Reply
    • Thanks for joining the conversation…

      The point of using the Cynefin model, as adapted by Jurgen Appelo, has nothing to do with cadence locking per se. It has everything to do with what you force (install) on a team or not.

      Since we’re dealing with a complex social system of teams, I’d suggest letting the teams determine what they think will work for them – if that is locking cadences, fine, they chose it. If it is something else, then let them run with it. Frequent retrospectives combined with the right level of authority will uncover an optimal solution for that set of teams that need to orchestrate their activities. So rather than prescribe any locking (regardless of length), let the teams decide together how they want to meet the need to regular demonstrate integrated working software.

      Cheers,
      Paul

      Like

      Reply

Leave a comment