Think about the work inside your organization. If you are delivering software, some of the software is core and critical; other parts of the software are supporting; perhaps other parts are simply cosmetic or informational. Those different aspects most likely have different SLAs.

Look at the software slightly different, perhaps even in your own team. Some changes are easy - the code is clean, fresh, modern with a good test suite that gives you confidence. Perhaps other changes are slightly more complicated because of an integration that is difficult to test. And maybe there is another set of changes where 'the dragons are' - nasty, old code that has always been rushed and needs to be refactored (when we have time, which we never do).

The work across teams is different. The work within teams can be different. So why would you ever have one process to rule them all?

In this session we will talk about variety and variability. We will capture variability using Shewhart charts and identify causes of variability with causal models. Not happy with the amount of variability? We will identify and separate naturally occurring variability from variability caused by the organization that could be remedied.

We will look at U-curves and context to see find the 'appropriate process (like batch size, deployment rate, etc)' for a given team in a given context at a given time.

Lastly, we will talk about how to use variability and its affect on decision making.

Leave this session with the ability to see variability and make better decisions than 'one process to rule them all.'