PRINCE2 Agile 2016
Previous Section   Next Section

17.4 Agile concepts and techniques

17.4.1 The Cynefin framework

The Cynefin framework (pronounced kuh-nev-in) was created by David Snowden. It is a decision-making framework that has been designed to help understand and determine the level of complexity in a given situation or environment.

In the context of PRINCE2 Agile this can be used to help understand and determine the level of complexity facing a project or potential project.

17.4.1.1 The five domains

The Cynefin framework identifies five domains which describe the relationship between ‘cause’ and ‘effect’ of events and interactions, and therefore determines how complex an environment is. In simple terms, if x happens and results in y, what is the relationship between x and y? Is it to be expected and always happens, or could it be completely unexpected and in fact random?

The five relationships are identified as:

  • obvious where the relationship is obvious and is usually addressed by ‘best practice’
  • complicated where some form of analysis or expertise is required to understand the relationship, which is usually addressed by ‘good practice’ where there may be several different options available
  • complex where the relationship can only be understood in retrospect and is addressed by ‘emergent practice’ which may evolve to a new way of working
  • chaotic where there is no apparent relationship, and any way of working is described as novel
  • disorder where the relationship is unknown.

The Cynefin framework is shown in Figure 17.3. The central area of the figure represents the fifth domain of ‘disorder’. The boundary between ‘obvious’ and ‘chaotic’ is, in fact, a ‘cliff’. To transition between these two domains is regarded as potentially catastrophic, whereas transitioning across any of the other boundaries is not.

Figure 17.3 The Cynefin framework

Figure 17.3 The Cynefin framework

17.4.1.2 When to use Cynefin and what to use it for

During Starting up a Project and Initiating a Project this framework can be used to understand (or attempt to understand), the complexity of a project. The framework can be used to analyse two areas:

  • the level of complexity of the final product in terms of the output, outcome and benefits (e.g. whether it is highly innovative and there is little knowledge of how well it will sell)
  • the level of complexity of the project environment covering things such as the levels of co-location, collaboration and experience (e.g. there are many teams involved from all around the world).

17.4.1.3 Assessing the level of complexity

Correctly assessing the level of complexity of the product and the project environment can help to determine the appropriate use of PRINCE2 and agile. It can be the case that certain areas of a project have different levels of complexity (e.g. the user interface of a control panel may be highly volatile and difficult to design, whereas the internal mechanics may be reasonably straightforward).

17.4.1.4 An example of a complex or chaotic situation

If the output from a project is a highly innovative children’s toy that is very different from anything currently in the marketplace then approaches such as Lean Startup (where strong emphasis is placed on learning quickly) and techniques such as spiking and prototyping are likely to be appropriate at the delivery level.

Making the PRINCE2 processes as short as possible and using many stages may also be appropriate and the project could feel very much like an experiment, or a series of experiments.

17.4.1.5 An example of a complicated situation

As an alternative to the previous example, if the same organization was creating a new board game for adults and it had done this many times before, it may use 4-weekly timeboxes to execute the delivery and may have very few stage boundaries.

In the second example it may even be the case that the level of complexity does not warrant the use of PRINCE2 and the work should be carried out as BAU.

The Cynefin framework should not be used as a categorization tool, as one of the principles behind it is that people have a natural tendency to categorize complexity according to their own experiences and preferences. A person who is used to working in the complicated domain may well have a tendency to approach a problem by analysing it, whereas a different person who is used to working in the complex domain may approach the same problem by running an experiment.

If the level of complexity is assessed collaboratively there is more likelihood that it will be correctly determined and PRINCE2 will be configured appropriately.

When a project is in progress it is possible that the level of complexity of the project, or the product, may change and migrate across the domain boundaries. PRINCE2 and the agile approaches being used may then need to be tuned (e.g. timebox durations may need to be shortened or lengthened; more customer demos may be required).

17.4.1.6 Evolving PRINCE2 in an agile context with Cynefin

The Cynefin framework can also be used to apply the learnings from a project to other projects and evolve the use of PRINCE2 and agile throughout an organization. A project framework may typically exist in the complicated domain (‘good practice’) but that is a matter of choice for an organization as it may be more beneficial to see it in the complex domain (‘emergent practice’). One approach would be to assign different areas of the project framework to their most appropriate domain (e.g. some innovative agile techniques that may be unproven may be used when in the chaotic domain).

One specific area the Cynefin framework focuses on is the area of complacency which exists between the obvious and the chaotic domains (referred to earlier as the cliff). An example of this would be where the use of PRINCE2 Agile becomes robotic and routine, as when it is applied inappropriately and not adapted to suit the environment or the level of uncertainty. Perhaps it has become stale as it only exists in the obvious domain and therefore does not change or evolve and is regarded as a simple thing to do. This can lead to what Cynefin describes as a crisis or catastrophe, when a sudden realization occurs that an approach is no longer fit for purpose (e.g. a major project disaster occurs because the underlying process is no longer appropriate).

17.4.1.7 Appropriateness

The Cynefin framework can help with how PRINCE2 is configured for projects of varying degrees of uncertainty. In a similar way to driving a car, there is a need to understand the prevailing conditions (e.g. it is snowing, it is dark – then drive in the most appropriate way using the controls that are available).

Previous Section   Next Section