Herding Cats

Software development in general, and video game development in particular, is a highly creative activity that has more in common with film production than it does with physical engineering.  Furthermore, in all but the simplest cases it is a team, rather than individual, effort.  Alistair Cockburn, a well-known software development methodologist, refers to software development as a Cooperative Game similar in spirit to mountain climbing (you only win if everyone gets to the top and down again safely).

So how exactly do you get a team of creative people to all pull in the same direction and produce something greater than they could individually?  I mean we’re talking about a challenge that many software professionals not-too-kindly refer to as “herding cats”.


Probably the most widely used attempt to solve this problem is to document a set of standards and norms that all teams follow.  The industry is rife with such standards: ISO-EIC, IEEE, TQM, CMM, etc.  Some management teams even choose to lead an effort to define a custom process for the teams to follow.  In fact, I’m not too proud to admit my own involvement in more than one of these efforts over the years.  Either way, the idea is to control behavior in a way that results in successful software delivery.  In my 17+ years experience, this kind of approach leads to marginal results improvement at best.  Software developers, designers, and artists are all very intelligent, creative people.  The notion of “control” is an illusion.

Another approach, the so-called Agile approach, stems from two key principles: get everyone to buy in to a core set of values and motivate teams to aggressively deliver on those values.  The desired result is the same as the previous approach: people following a process in order to deliver.  However, the execution differences are critical.  The first difference relates to the values you choose.  The second difference relates to how teams are motivated.

So what values should software development shops use?  All Agile methodologies, regardless of differences in execution, are inspired by the values espoused in the Agile Manifesto (agilemanifesto.org).

Agile values:

 Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


That is, while there is value in the items on the right, agile methods value the items on the left more.  These values, along with the related 12 principles of agile software development, emphasize maximizing time spent on value creation and minimizing time spent on efforts that are secondary to that goal.

So what about the challenge of motivating teams to follow these values?  To answer that, all you need do is open any leadership book written in the past decade.  Motivation is not a function of management or compliance. You may obtain compliant surface behaviours but true motivation will only come from individuals themselves.  This means, among other things, putting control of local processes into the hands of those most affected.  This approach can make some less confident leaders quail (“what if they do it wrong?”, “what if they sandbag?”).  Two elements are key here.  The first is the four values themselves with a focus on maximizing the delivery of value to customers.  The second is fully embracing periodic introspection and adaptation including the development of a culture that feels safe in experimenting.

Clearly there is much more to any particular Agile implementation, but I don’t have the room in this short article to get into the common practices of Agile systems. My purpose here was merely to introduce a different way of thinking about leading software development and other creative teams.

I’ll close with some observations regarding the types of benefits one can expect to see when “moving to Agile”.  I myself have led the move to Agile for software teams at two very different companies (one from a structured, traditional process and another from a more ad hoc “process”).  Unfortunately, I’ve also witnessed a systematic attack on an Agile process which included a management mandate to a more traditional process (but that’s a story for another time).  In my experience, I have witnessed the following types of benefits when moving to agile.

  • Increased transparency and communication within and between software teams
  • Increased transparency and communication between the software teams and the business teams
  • Increased morale and a “we’re all in this together” mentality
  • Increased teamwork
  • Development of a craftsmanship culture

You will, no doubt, find that the teams will get all kinds of things wrong, but fear not.  Experimentation and adaptation are essential.  If you’re experimenting but not making any “mistakes” then you’re missing much of the potential benefits of agility.

About the Author: Peter Scheyen

Leave a comment