Month: October 2015

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: InfoQ.com

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.

Utilizing “Lean Coffee” for Large Team Retrospectives

Scrum defines the optimal team size as 3 to 9 people.  I’ll skirt by the team size discussion for right now and just accept that there are large teams out there – a couple of which I have direct experience with.  With these larger teams comes corresponding issues; one of which is conducting an effective retrospective.

It is more difficult for larger teams to conduct retrospectives.  It can be difficult to get everyone involved or everyone is competing at once to be heard.  Whatever the issue, the impact is exasperated by the large team size and group facilitation becomes exponentially more difficult.

Enter LEAN COFFEE …

When we began using a Lean Coffee approach for our large team retrospectives the process became more efficient and effective.  The Lean Coffee facilitation method is usually used to promote learning and I think we’ve put the method to good use in our large team retrospectives.  Take a look at it in the image below and then I’ll continue on to explain how we applied it within our retrospectives.

Lean Coffee

In applying Lean Coffee to the Retrospective, we proceeded as follows:

As in a normal retrospective, the scrum master (facilitator) sets the stage along with gathering and sharing objective data in order to define the focus of the retrospective. The retrospective preparation steps should not be skipped.  If a specific theme is warranted then that would end up being the target of your brainstorm topics in step 2.

Step 1:  Create a simple Kanban –For this scenario, we separated the team into groups (recommend no more than 4 people per group; 5 at the very most) with each group setting up their Kanban as depicted above.

Step 2:  Brainstorm Topics – The topic was to identify what the group felt went well and what we needed to improve upon within the last sprint (no specific focus this time).  Each person independently (no discussion with others) wrote multiple topic themes with one topic theme per post-it.  All of the topic themes post-its were placed in the “To Discuss” column of the Kanban.  We allowed 5 minutes for this step.

Step 3:  Pitch Your Topics – Each individual explained the idea behind any of the post-its that they contributed.  This was done in a concise manner and the scrum master monitored to make sure that nobody was discussing or solving the issue, since this part of the exercise is only to ensure that everyone understands the meaning of the topic theme written on the post it.  We allowed 10 minutes for this step.

Step 4:  Prioritize What To Discuss – Each group member was allocated 3 dots to vote on the topic theme(s) that they thought were most important to discuss.  We allowed 2 minutes for this step.

Step 5:  Manage Flow of Conversation – We determined that we would allocate six sessions of 5 minutes each and would thumb vote at the end of each session to see if we wanted to continue the conversation.

Step 6: Discuss – The topic theme post it with the most dot votes was moved to the “Discussing” Kanban column and the team began to discuss the topic and identify what action items could be taken to ensure improvement in the following sprints, if applicable.  Any action items were captured on the post it.  If we were done discussing the topic theme post it then it was moved to the “Discussed” Kanban column and the next topic theme post it was moved into the “Discussing” Kanban column.

Step 7:  Lock in the Learning – At the end of the last discussion session, we nominated a spokesperson for each group and they alternated sharing their topic themes and action items with the full team.  Time was allowed for discussion.  This step took about 30 minutes and we were able to share and discuss among the whole team 4 “went well” topic themes and 7 “improvement” topic themes (with one topic being a duplicate across groups).  We then took about 15 minutes to record the results and create Product Backlog Items (PBIs)/ tasks to be carried out ensuring action on the identified improvements.

In conclusion, by utilizing Lean Coffee, we were able to separate the large team into smaller groups which later came together to share and educate the whole team.   Separating into smaller groups allowed for better and fuller participation and decreased the usual time needed for the large group retrospective.