Agile Planning

Cynefin Decision Framework and Agility

cynefin image

I had the pleasure of being one of four Agile panelists answering questions at the Tampa Bay PMI Symposium (good turn out with more than 300 registered).  One of the other panelists, my friend and respected Agilist Steven Granese, mentioned the Cynefin Model.  After that discussion, I felt it would be good to discuss the Cynefin Model and how it supports an Agile process, especially when dealing with complex situations.  So, here it goes …

The world is complex and shows no sign of abatement.  The military learned this as they dealt with different autonomous Al-Qaeda (AQ) cells.  Teams of our military personnel did not have time to contact command to formulate or validate plans.  They couldn’t identify many set patterns because AQ would continuously adapt.  Our military could not be even relatively sure that the same tactical action would yield the same result in each situation.  So, they dropped the silos between teams and departments and opened up communication; empowering the individual teams.  Previous information that was on a need to know basis was now available.  They let their units make decisions, probe with different tactics and then share the learning later on.  This problem area certainly fit in the complex domain of the Cynefin Framework.

Cynefin (pronounced kuh-nev’-in) is a leader’s decision framework developed by David Snowden that aligns things into defined domains.  The framework was developed for knowledge management and strategy, but I believe can assist us in identifying the need for Agile software development.  Cynefin prescribes the way to act on something is based on the domain it falls in.

The five Cynefin domains are:

Obvious or Simple (the known) – We’ve seen this a million times and as such can categorize and respond according to established best practices.  The relationship between cause and effect is well known.

Complicated (the knowable) – Although we don’t immediately know what is happening, we can analyze the situation and come to a conclusion of what must be done.  We can enlist experts to analyze, set up constraints and a process addressing resolution.

Complex (the unknowable) – We’re not able to determine what will cause a particular result. The best course of action is to conduct experiments and check if any or all take us in the correct direction.  A lot of time when human opinion and decision is involved we could be working in this area; simply because humans are complex beings.

Chaotic (the incoherent) – The situation is very unstable.  We don’t have time to experiment or probe since the situation is dire and we need to act.  An IT issue that must be taken care of immediately with no delay may be categorized as such.  If we have no time to figure out a system deadlock issue, we may opt to get ourselves out of this chaotic state by rebooting the server.

Disorder (not determined) – Anything whose domain has not been determined falls into this domain.

Cynefin Table

Image provided by:

The Cynefin Model suggests that we identify the domain type and respond accordingly.  Agile (Scrum for example) is geared to operate in the Complex domain.  The Agile methodology offers the proper Cynefin response to the uncertainty present in many software development projects.  It is inherently adaptive and uses the “probe, sense, respond” method.  Waterfall could handle Obvious and Complicated domain issues, but would fall flat when faced with a complex situation.

Software development offers issues that fall into all the domain areas, but if you use Waterfall you will be at high risk delivering anything in the complex domain area.  If you use Agile, you could have some minor inefficiencies compared to waterfall in the simple domain, but you will reduce or eliminate the high risk of failure in the complicated, complex and chaotic domains.  It seems sound reasoning then if you’ve got any unknowns involved then your software development projects would be minimizing risk by following the Agile methodology rather than Waterfall.

Consider Innovation During Capacity Planning

Innovation Turtle

What I’ve learned is that “Innovation happens when and where it happens”.  You can’t schedule innovation and you can’t create innovation by committee.  Think about it … when do innovative solutions pop into your head?  A moment of time when your mind is free?   During an impromptu discussion with co-workers?  These are the times that innovation happens and although they are not scheduled we need to have time in our day for it. If people are fully tasked with assigned activities throughout the sprint then innovation dies. Even if an innovative idea surfaces, it is immediately squashed by the all ready full plate of commitments and is not given another thought.  Innovation is responsible for the features that will “WOW” the customer.  If your product doesn’t include any of these then you’re going to have a tough time rising above your competition. Collaboration and being a good corporate citizen requires time also.  If you’re having difficulty establishing sprint capacity and at the same time allocating time for innovation, collaboration, learning and good corporate citizenship then take a look at the formula below.  This example is for a 2 week sprint (each developer does this):

  1. Total the number of hours needed for meetings, other scheduled events (scrum events/ceremonies count here), vacation, career building activities, etc. We will call that “Planned Interruptions”.
  2. Potential Available Time = Total hours in the sprint minus Planned Interruptions.
  3. Determine a “Load Factor” which is the percentage of “Potential Available Time” you will allocate to assigned work (planned tasks within the sprint).  Let’s go with 85% for your first iteration and adjust it as needed for future sprints.
  4. Available Time = Potential Available Time * Load Factor.
  5. Unplanned Interruptions = Potential Available Time – Available Time

So if we had determined 12 hours of Planned Interruptions for this developer for a 10 day (8 hours/day) sprint/iteration with a Load Factor of 85% then we would come up with:

Potential Available Time = 80 -12 = 68 hours
Available Time = 68 * .85 =  57.8 = 58 hours (rounded)
Unplanned Interruptions = 68 – 58 = 10 hours

Load Factor Table Image

This would mean with a Load Factor of 85% this developer has an average of 5.8 hours/day to allocate to assigned sprint tasks. Remember, you determine/adjust the Load Factor as you gain experience with your sprints.  Hopefully, this formula can assist teams just starting out on how to assign initial sprint capacity or use it for the long haul if you like.

Unplanned interruptions is where innovation occurs, because it is dedicated to collaboration and collaboration breeds innovation.  It is allocated for any collaboration work that needs to be done outside of assigned tasks and planned interruptions. So, don’t squash innovation and good corporate citizenship at your organization.  Allow for unplanned interruptions, team empowerment and trust to drive innovation forward.