Geeks With Blogs

The Life and Times of a Dev Yes, we're really that weird

You’ve all seen this team, maybe you’ve even been on this team.  I certainly know that I have!  What kind of team, you might ask?  It’s the team that is simply dysfunctional.  Many reasons can exist for a team that isn’t working, and team dysfunction is a complex thing that can’t necessarily be isolated into a simple formula that will always work to make people function well on a team. 


Recently, I attended RallyOn in Boulder with Rally Software Development.  This was one of the best user conferences I have attended.  We love the Rally tools for managing agile projects.  One of the tracks that they had at that conference covered the Cynefin framework.  Basically, Cynefin breaks problems down into four different groups:  Simple, Complicated, Complex and Chaos. 


Simple problems can be broken down into simple rules.  If you drop a rock, it will fall.  If you check in code that breaks a unit test, the build will fail.  If your code style doesn’t match StyleCop, you’ll receive rules violations.  These examples are all simple and easy to explain.  Non-technical computer people often think of software development or music as being simply a collection of simple rules that if followed will always give the same result.  As professional software developers, we know this isn’t the case.  The people who think this are the ones buying the cookie cutter websites for ONLY $400, which they soon find out don’t meet any of their needs.


The complicated domain is similar to the simple domain.  Ultimately, problems can be broken down into “rules” that if followed, will yield the same results.  Much scientific work falls into this category.  To an expert, the operation of a jet engine is understandable and the rules associated with that operation can be written and if followed, you’ll get a working jet engine.  Similarly, the rules for setting up a continuous integration environment are complicated, but can be written down and if followed or implemented by an expert, will yield an operating CI environment.  More educated people will often put software development into the complicated domain.  If they just document all of the rules about software development, they’ll have a successful project and it can be outsourced and everything will be great.  Again, senior developers know that this is not true.  Instead, software development really falls into the complex domain.


The complex domain is a domain where cause and effect can only be seen in retrospect.  Much of software development and people management falls into this domain.  If people could anticipate what was going to happen, they would behave differently, but since they can’t, knowing before hand what will happen is not possible.  Great examples of this domain are:  Life, software development, the stock market, politics, corporate fraud, and other people related examples.  Software development teams fall into this category.  Some resources will work very well on one project, and then fail on the next and the reason for that failure often cannot be known in advance.  The rules for building a successful software team are complex.


Chaos is a domain where there is no relationship between cause and effect.  Essentially, trying to predict what will happen with any certainty is not possible.  Serendipitous inventions are a great example of this and much innovative work occurs in the chaos domain.  Some examples:  The sun, avalanches, fires, mob behavior.

Movement in Groups

An important aspect of Cynefin is that problems can move from domain to domain.  Scientists are always trying to move items that appear to be complex or chaotic into the complicated domain.  If they can reduce things down to a set of rules, they have succeeded.  Often, they cannot, and they fail.  Things can move from Simple and Complicated as well.  For example, the music industry had the sale and success of music refined to simple rules.  Get a great artist, record music, put it into a store, get rich.  However, peer to peer sharing moved that from the simple domain to the chaotic domain, something which the music industry has been doing everything they can to change and move it back into the simple domain.  They probably will not succeed.  The genie is out of the lamp, so to speak.

Cynefin and Teams

So what does this have to do with software development?  Quite simply, as stated above, teams and team performance fit into the Complex domain.  Sure, parts are in complicated domain and have good practices, but much of it lies firmly in the Complex domain.  For example, how team members will get along or collaborate is not something that can be predicted with great accuracy in advance, and there are no rules you can use that will guarantee that the team members will get along. 

Everyone on the team, and stakeholders for the project, need to recognize that team dynamics are complex and that no simple set of rules will make a team function.  Agile preaches that the team needs to be self-healing and have the ability to do whatever needs to happen to make the team successful.  This really is the best place to deal with complex team problems.

Too often, external managers will attempt to “fix” the problems on the team.  Often, teams will feel like these managers are actually making things worse on the team.  The managers are viewing the problem as complicated, and in worst case scenarios, simple and probably ARE making the problem worse.

A better solution is to put the problem in front of the team and let them figure out what is going on.  Obviously, since team dynamics are a complex problem, even the strategy of putting the problem in front of the team will not always work.  For example, suppose you have a team where everyone on the team thinks that things are improving and getting better and that the team is adapting.  Everyone, that is, except for a single member of the team, and that single member of the team doesn’t want to bring his issues to the team.  That’s a complex problem, and will need to be handled in the context of the team.  Some teams, once they know that the team member feels the way that he does, will adapt and solve the problem.  Some teams will require management to intervene and come up with a solution.

The most important thing to remember is that these really are complex problems that often fall into the domain of the ScrumMaster.  The ScrumMaster is the person responsible for seeing that such issues are dealt with by the team or the team’s manager.  Avoid jumping to early conclusions.  Fixing complex problems often takes more than one attempt.  Be patient and work together.  What you try first may not succeed.  Don’t give up!  Keep trying!  Eventually, the team will figure out how to make things better.


There’s quite a bit more to the Cynefin framework.  I encourage you to take the time to understand what it can offer.  Happy coding!

Technorati Tags: ,,
Posted on Tuesday, June 14, 2011 11:56 AM | Back to top

Comments on this post: Why Does My Team not WORK!?

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robert May | Powered by: