Part One

I’ve been working as an agile mentor for a few years now. (This is a mentor of agile software development teams, not a mentor of all things bendy – just so we’re clear.) In this role, I’ve built up a fair amount of experience in helping teams overcome technical /process problems and I’ve recently become interested in the softer side of agile software development teams – the psychology behind agility.

It all started when I watched a video on YouTube “The Surprising Truth of What Motivates Us” http://www.youtube.com/watch?v=u6XAPnuFjJc which is a summary of the book of the same name by Dan Pink.  By pure coincidence, on the same day I watched the Youtube video, I read  some review comments on a paper that debated whether the term “empowerment” or “autonomy” should be used when talking about the goals for true agility. It was an interesting discussion and it made me question some of my previous assumptions.

The first question is – what is the difference between autonomy and empowerment? A colleague said that in the simplest terms empowerment is given whereas autonomy is taken. If you look at definitions of the two words in the simplest form, they are:

Autonomy - the power or right of self-government

Empowerment - the giving or delegation of power or authority; authorization

Read More

The motto "less is more" is often used in art and architecture circles to refer to a philosophy of minimalism ( http://en.wikipedia.org/wiki/Minimalism). Minimalism is related to a concept often referred to as Occam's Razor (http://en.wikipedia.org/wiki/Occam%27s_razor), or the idea that the simplest possible explanation should be chosen when considering alternatives.

These concepts came back to me as I considered the situation on a team with which we had been working.  The team was making reasonable progress, but it was clear that a couple of team members were struggling a bit.  The dilemma was this: does the team join together to help bring the team members along or do they, to use the vernacular from a well-known television program, "vote them off the island".

Conventional wisdom says that more people can get more work done than fewer people, but as Fred Brooks observed long ago in "The Mythical  Man Month", more people frequently do not get as much done, and adding people to a project can actually slow down velocity.  To apply Occam's Razor, we should have exactly as many people as we need on a project to get the work done, not a person more.  To apply the principle of minimalism, we actually ought to be a little understaffed.

People tend to perform better when there is a little stress.  As hunter-gatherers long ago, we probably hunted better with a little hunger driving us on; a full stomach leads to a kind of sleepy complacency.  We need goals that are just a little beyond our reach, as observed Robert Browning when he said that "a man's reach should exceed his grasp".

All this is a nice theory, but what about our team?  In true self-organizing fashion, the team decided that it would make more progress with fewer people.  The result?  The velocity of the team actually went up, proving that, at least for this team, less was indeed more.