Does the Agile Project Leader Exist?
Written by Mike Cottmeyer Thursday, 28 June 2007 12:22
What better way to get a blog on Agile Project Leadership kicked off than to challenge the very assertion that there is such a thing as an Agile Project Leader. Is the idea of an Agile Project Leader even a valid concept? Could we not make the case that Leadership is Leadership no matter what the context or problem domain? If we are going to use the word “Agile” as a modifier in front of the words “Project Leader”, what does it really mean? What new information are we trying to convey about that person? What does it tell someone about you that they did not already know?
Let’s break down the phrase “Agile Project Leadership” and all get on the same page about what these words mean.
Websters defines leadership as the “act or instance of leading” and leading as “guiding on a way, especially by going in advance”. While one can certainly use this as a working definition, it does not seem to capture the nuance or power associated with the word “Leadership”. Since this is not a particularly satisfying definition, I have included several quotes from others on what it means to be a leader:
The key ideas embodied in these quotes are that leadership is about service, setting direction, doing the right things, empowering, and developing your people.
One would think that the definition of a Project should be a little easier to handle. Using Websters again to get us started, a project is defined as a “specific plan or design”. A quick search on the web seems to hit closer to the mark. On Wikipedia for instance, a project is defined as a “one time endeavor undertaken to create a unique product or service”.
Project Leadership then seems to involve being out in front, guiding the way, serving the team, doing the right things, empowering, motivating, and developing your people; all within the context of a finite, one-time endeavor undertaken to create something unique. It appears that this might be just enough of a definitition to cover both general “Project Leadership” and “Agile Project Leadership”. Why bother modifying this description with the word “Agile”.
Well, before we dismiss the idea, let’s explore just what “Agile” means in a little more detail.
Websters has two interesting definitions for the word Agile: “Marked by ready abilility to move with quick and easy grace” and “having a quick and resourcful and adaptable character”. Wikipedia is all over the place with the word “Agile” but bringing it into the software context does make things a bit more clear. Agile software development is defined as a software development framework that promotes evolutionary change throughout the entire life-cycle of the project. The key point in this definition is that Agile promotes evolutionary change through the life of the project.
It seems then that the new information about a leader imparted by the word “Agile” is that the “Agile Project Leader” also has the added ability to move quickly, be adaptable, and promote evolutionary change through the life of the project. Is it possible then to make the case that this idea of Agility is really embodied in our orginal definition of a “Project Leader”? Is it not implied by the requirement to be out in front or to do the right thing?
The problem with stopping with the textbook definition of Agile is that the word “Agile”, in the context of an “Agile Software Development Project”, is actually a bigger concept than we have just implied. While an Agile Project Leader would need to be able to move quickly, be adaptable, and promote evolutionary change; the Agile Software Development movement is founded on a set of very specific principles that intentionally promote a culture of adaptability and evolutionary change. Not just any principles pass the test to be considered Agile no matter how close they may meet the textbook definition fo Agility.
The founders of the Agile movement have crafted a set of beliefs intented to unify the various factions within the Agile community and define what it means to be Agile. These beliefs are embodied in a document called the Agile Manifesto and establish a value system for the Agile practitioner. Sometime after the Manifesto was created, another group of leaders created a similar set of unifying statements specifically for the Agile Leader. This belief system is called the Declaraton of Interdependence. Both are available online but are included here for easy reference.
- 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, we value the items on the left more.
Declaration of Interdependence
We are a community of project leaders that are highly successful at delivering results. To achieve these results:
- We increase return on investment by making continuous flow of value our focus.
- We deliver reliable results by engaging customers in frequent interactions and shared ownership.
- We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
- We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- We boost performance through group accountability for results and shared responsibility for team effectiveness.
- We improve effectiveness and reliability through situationally specific strategies, processes and practices.
In addition to these unifying principles, the Agile community appears to be coalescing around series of best practices that in turn support the principles and desired outcomes of Agile project teams. Practices such as timeboxing, colocation, customer collaboration, test first development, and pair programming are a few examples of practices believed to deliver the desired outcomes of an Agile project.
So then… what desired outcomes are unique to an Agile Project? Aren’t all projects interested in delivering on-time, on-budget, with all the scope, and with high quality? Are the desired outcomes of an Agile Project any different from the outcomes of a more traditional project? Project Managers are typically evaluated based on the delivery of the project within the agreed upon time, cost, and scope constraints agreed to at the beginning of the project. In a sense, the Agile Project shares these objectives but is not willing to deliver these outcomes at the expense of the team. The Agile Project adds to these traditional outcomes objectives around team health, sustainability of the system, indivudal empowerment, and the means for the team to set itself up to deliver the next project.
For the sake of argument, let’s assume for a moment that there is such a thing as an “Agile Project Leader” and that it is materially different from a standard “Project Leader”. It appears that word “Agility” is not intented to exclusively modify the characteristics of the leader, but implies that leader will employ a set tools and techniques according to a specific set of principles that will support a specific set of desired outcomes. These principles, tools and techniques, and desired outcomes are not static and are expected to evolve as the community matures in its understanding. The Agile community is too new to have a static body of knowledge and the establishment of such would seem to go against the very principles the movement was founded on. With that said, there is clearly a direction and there is clearly an accepted baseline.
So what does all this mean for the fate of our Agile Project Leader?
The logical conclusion is that an Agile Project Leader is differentiated from a Traditional Project Leader by their ability to apply specifc strategies based on the the tools, techniques, and principles associated with the Agile Software Development community and embodied in the Agile Manifesto and the Declaration of Interdependence. It seems that much past that Leadership is just Leadership.