Agile project management using the Cynefin framework

Project managers and leaders often struggle to determine how to approach a problem. What are the appropriate ALM tools? Which software development methodology is most appropriate? The Cynefin (pronouned kuh-NEV-in) framework created by Dave Snowden is one in which situations or projects are categorized into one of five complexity domains: Simple, complicated, complex, chaotic or disorder. At the May 2012 Denver Agile User Group Meeting, Senior Agile Coach Brad Swanson demonstrated the complexity domains through the Cynefin Lego Game and explained how leaders can use the Cynefin framework to make decisions, foster strong teams and determine when Agile practices are most appropriate.

Simple: Best practice

The Agile meeting began by separating the audience into groups sitting at separate tables each with a large pile of Legos. The first exercise was for each group to separate the Legos by color as quickly as possible. The teams were all able to accomplish this task very easily. This was an example of a task that would be classified in the “simple” domain of the Cynefin framework.

One of the characteristics of tasks that are in the simple domain is that the best practices are clear. While some might argue that software development is rarely “simple,” there may be cases in which an application is stable and rarely changes. Best practices such as maintenance processes are well-defined and repeatable.

Swanson said that when tasks fall into the simple domain, a command and control style of leadership is often effective. Though this is not an Agile style of leadership, in those rare cases where development is “simple,” using an Agile framework such as Scrum, may be unnecessary and considered overkill.

This echoes the thoughts of Mitch Lacey in his recent interview with SearchSoftwareQuality.com, in which he says, “In simple projects, you won’t have a lot of change. Scrum and XP were designed to handle large amounts of change, so I’m not sure what people would learn other than the basic mechanics.”

Complicated: Good practice

The next Lego exercise was to build a patterned structure given a set of conditions. This exercise was more complicated than the first, but still relatively straight forward.

After each exercise, Swanson asked the groups questions around communication and group dynamics. Did leaders emerge?  As the rules got a little more complicated, those who were more familiar with the task (in this case, Legos) took control.

Swanson said when you are working with complicated projects, you “know what you don’t know” and you seek out experts. In the case of software development projects, this would be the time you would rely on subject matter experts or consultants with specialized skills to augment the staff.

Complex: Emergent practice

The complex Lego exercise added some additional challenge. In addition to the rules (or requirements) of the previous exercise, the teams now were to build a vehicle or animal, each person could only touch one color of Lego and team members weren’t allowed to talk. Teams also were periodically asked to switch tables and work with a different set of Legos.

Of course, there was some frustration on the team as members struggled to communicate and were unsure of exactly what the others were doing. It was difficult to come up with a strategy. When projects fall in the complex domain, we know there are unknowns and we work iteratively to discover the unknowns. Over time, the best practices emerge through continual learning.

Swanson equated this domain as most closely mirroring Agile software development. “I view Scrum and Agile processes and iterative processes in general as a pattern or solution that makes sense in a complex domain because we’re intentionally creating short experiments, we’re probing, we’re sensing what happens, then responding and our solutions tend to emerge. It’s a framework that was intentionally designed to work well in that complex domain.”

Chaotic: Novel practice

The final Lego exercise was similar to the last, only this time, teams not only switched tables, but team members were tapped on the shoulder randomly and directed to go to different tables. When this happened they were suddenly with a new group, and unable to talk, so there was even a greater challenge in understanding their new group’s strategy.

This switching of groups, on top of all the complexity of the previous exercise, created a lot of confusion, which is trait of the chaotic domain. Swanson noted that when managers reorganize groups or switch people from team to team, it can create chaos.

Though chaos isn’t comfortable, it isn’t always bad. Getting too comfortable in a simple model of best practice might prevent us from growing or innovating.

Swanson compared the chaotic to the complex domain. “In the complex domain, cause and effect can be known, but only in retrospect. You don’t have prior knowledge of cause and effect. In the chaotic domain, cause and effect shift continuously. In this domain you first act, then sense and then respond.”

Swanson said that a Harvard Business review talked about 9-11 being in the chaotic domain. “First you must act and bring some order to the situation.”

Disorder

The final domain in the Cynefin model is one that Swanson didn’t demonstrate. He joked that it might be something like scattering all the Legos into a big pile in the middle of the room and turning the lights out and trying to build the Eiffel Tower.

Final thoughts

When asked whether introducing Scrum would throw the team into chaos, Swanson answered, “That’s one of those disruptions that will change the way everyone’s been doing things. We might intentionally introduce some chaos and then bring things back. Hopefully, with some good coaching and training you can avoid the chaos and bring things back into the complex or complicated domain pretty quickly.”

While wrapping up, Swanson summarized how leaders could use the model. “The intent behind the framework is that different situations might be in different domains and therefore you might respond in different ways. Think about what situation you’re in and think about the response to that, and use that to guide how to go about solving the problem.”