Every day in our two-week sprint we start the day with a 15-minute scrum meeting in which all of the team members working on the sprint discuss our daily progress.  I’ve been working with a fairly consistent team for close to two years and one question that sometimes comes up is who leads the team.

There are a lot of ways to answer this question, depending upon how one defines the word ‘lead’ in this context.  In some ways we are led by the market.  Our goal is to provide useful solutions to painful and pervasive market problems; this means that our entire focus is market-driven.  We try to build solutions that impact not just one client but an entire market segment.  We don’t want to be led by our own ideas or by the charismatic influence of one person – instead we want the market to provide direction about what we should build and when we should build it.  But that’s kind of abstract.

From a different perspective, our sprint team is led by the scrum master (which to my geeky ears sounds like something that would fit here: http://www.wizards.com/dnd/).  This person sets up and facilitates our daily meetings, keeps the team on task, identifies and elevates any obstacles we encounter, and makes sure that we are moving toward our sprint goals.  The Agile teams I have been part of have kept this role relatively informal, although in general the coding lead or the testing lead has filled this position.  However, this person doesn’t provide direction to the team or the project; she facilitates our group process rather than leading us.  So that answer doesn’t quite feel right either.

As a company, we recently went through a gap analysis session with a team from Pragmatic Marketing (you can find a link to their very helpful material on the sidebar of this blog).  As we examined the thirty-seven identified responsibilities of a product management organization, we found that different people would be best to lead different aspects of this process.  In some cases the product manager could best lead, while in others the leadership of strategic marketing or business-line leaders would be a better fit.  The idea that different people might step into leadership at different places along the development cycle feels like a better understanding of how Agile works.  Even here, however, I don’t think this quite captures the way leadership works on our scrum teams.

In my experience, the best encapsulation of how leadership works on an Agile scrum team comes from one of the twelve principles of Agile: “The best architectures, requirements, and designs emerge from self-organizing teams.”  Our scrum team is not leader-less, but leadership is such a fluid concept that it feels more accurate to call us self-organizing.  When we are functioning at our best, no one is calling the shots.  Instead we respond to each other’s ideas and influence, collectively creating better processes and products than any of us could have dreamed up on our own.  We naturally defer to one another’s expertise where appropriate, and we collaborate in multiple ways during each sprint.

As we embark on our current sprint with no identified leader of our team, things don’t feel disorganized.  We planned together, we talk together multiple times each day, and we know what we are trying to accomplish in the next two weeks.  We aren’t without leadership; we are self-organizing around the larger and smaller pieces of what we’ll accomplish together.  I’ve seen this produce some amazing things in the past months of working together and I have high hopes for what we’ll do this sprint.  Of course, in truth it’s not that simple.