A few months ago I received an invitation to speak to the Hartford, CT chapter of the International Institute of Business Analysts (IIBA). The group wanted to hear something about leadership and how the members might improve their leadership skills in their organizations. We discussed several possible presentations and agreed upon a presentation about leadership on Agile projects. This article summarizes that presentation and the suggestions I offered to the group, including ten leadership traits that seem most applicable to Agile development teams.
I don't propose to encapsulate the essence of leadership in ten simple attributes. There are books and organizations that address the topic in detail, including the Agile Project Leadership Network (APLN).1 For now, let us agree that leadership is something that we all understand, whether we can define it formally or not.
The first ten years of the 21st century may go down as the Agile decade when we look back at the progress of software development. Agile development has grown from a handful of consultants presenting at conferences on the better ways they had discovered for developing software, to the point where we now have conferences completely devoted to Agile development. Agility is no longer the bailiwick of small groups of avid proponents; it is now one of the major interests of entire software development organizations that span the technical and application domain spectrum. We still face the problem of misunderstanding Agility, but this occurs whenever new fads arise and transition from novelty to general acceptance.2 If you know the story of the blind men and the elephant, you can understand how elusive the true meaning of Agility -- and Agile leadership -- can be.3
Everyone I talk to agrees that Agile software development is ubiquitous today. Small and large organizations alike have adopted some form of Agility. The topic appears in journals as diverse as the Association of Computing Machinery's Communications and Crosstalk, the military defense journal for software engineering. The push to Agility has become synonymous with improving the way we develop software systems.
Just as the term "Agile" can mean different things to different practitioners, the same applies to the term "Agile leadership." My frame of reference is that of a software developer. The problem doesn't resolve itself if we just consider leadership. We'll just have to agree to work with this "fuzziness" as we discuss effective ways of becoming a leader on an Agile project.
I typically ask the audience at my presentations -- like the one I did recently for the IIBA -- whether they are using Agile methods. The number of hands raised has increased over the last few years. Then I ask those who are using such methods what they mean by Agile. While I am not surprised at the number of different responses I receive, I am surprised when there is considerable agreement among the answers. Part of the problem comes from the overuse of the word "agile." I did a very short survey of phrases about software development that contained the word. In about 30 minutes I came up with a list that included: Agile development, Agile design, Agile modeling, Agile testing, Agile project management, Agile rollout planning, Agile decision making, Agile Scrum, Agile languages, Agile database, Agile programming, Agile assembly, Agile game development, Agile thinking, Agile usability, Agile IT... I might add to that list "Agile overload." Clearly we suffer from it.
So, regarding leadership, I would like to explore the practices and characteristics that fit best with the Agile characteristics as described in the Agile Manifesto.4 Of the four major tenets of the Manifesto, the value of individuals and interactions over process and tools -- is the most relevant to the following discussion.
We have different styles of leadership, just as we have different styles of software development. Another brief survey of the term "leadership" produced a list with the following words that describe leadership styles: bureaucratic, charismatic, autocratic, democratic, laissez-faire, people-oriented, task-oriented, transaction-oriented, servant-leadership, transformational, and environmental. Perhaps leadership, like Agile, has different meanings to different people, depending upon their frame of reference. How can we begin to make some sense of this?
Figure 1: Some well-known leaders
I began by identifying some well-known leaders in different areas. Figure 1 shows some of these leaders. Readers will recognize some of them, like Winston Churchill, John F. Kennedy, and Adolf Hitler. Others, like Lee Iacocca and Lou Gerstner, might be known only to a specific segment of the population.5
Next I thought of technology leaders -- that is, those people whom software developers look to as influential in the software development industry. Developers want to understand these people, emulate them, and listen to their ideas. Figure 2 shows my list of technology leaders.6 Not all of the members of this list come from a programming background. Some of them focus on running major corporations and could easily appear in Figure 1. I cite them as technology leaders because they have accomplished some things that developers admire.
Figure 2: Technology leaders
Next, let's look at the differences between the first and second group. These differences are not absolute and one can argue about them quite effectively over a cup of coffee, but I'm going to offer my viewpoint.
The leadership characteristics of the first group (Figure 1) could be described as:
- Focus on management and organization.
- Structure is important.
- Main area of concern is the "big picture."
- Strategy is more important than tactics.
- Leadership is by decree. Many of them were appointed to their position of leadership or elected to it.
- Reliance on conscripted followers. When you take a job or join a military organization, you agree to follow the leaders the organization puts in place. The choice is not yours.
The characteristics of the second group (Figure 2) could be described as:
- Knowledge as the primary currency.
- Innovation is both a goal and a means to the goal.
- Leadership by acclaim. Most of the members of the group achieved their leadership position because people consider them leaders and want to follow them.
- Willing followers.
- Each member of the group is an acknowledged expert in some area.
People like Bill Gates and Steve Jobs could easily exemplify both kinds of leadership. I placed them in the second group because of the place they hold in the minds of software developers for their ability to apply innovative vision to technology to build their companies. They learned to be good managers, but first they were leaders.
Successful leaders must be able to inspire their followers. A successful military leader does this by instilling the troops with the belief that they are battling for a worthy cause and the belief that they will achieve victory. This occurs in a framework of leadership by decree. Technology leaders inspire followers by making them believe they can become better if they adopt the leader's ideas and practices. I think this difference is key to understanding how to become a good technology leader.
The general of an army or the CEO of a corporation often has a much different set of core values and responsibilities from the soldier or the employee of the business, even though they are all engaged in a common cause. With technology, however, the technical leader's core values and the individual practitioner's core values are much more aligned. This leads me to believe that if you want to be a technical leader, you have to be a technical person first. If you want to achieve a leadership position in an Agile team, you need to align your values with those of the team, and not require team members to align themselves with your values, which might not mesh well with theirs. Figure 3 shows how different the core values between leader and follower can be when "leadership by decree" is in operation, and how similar the values tend to be when "leadership by acclaim" is in operation.
Figure 3. How well leader and follower values match.
One thing is very clear to me based on this thought exercise:
Management focuses on resource allocation, cost management, delegation, optimizing profits, and so on. Addressing these concerns is critical for any organization that wants to succeed.
Leadership is about people, especially technical leadership! Technical leaders have a connection with those they lead. A few great leaders can handle leadership and management, but in general good managers and good leaders form disjoint sets.
The September/October 2005 issue of the business education magazine BiZEd contains an article on leadership traits by Tricia Bisoux.7 One can find many such lists, but this article enumerates a representative set of traits that suits this discussion. I'll examine each of these below and see which are most applicable to working on Agile projects.
Self-awareness: Good leaders know themselves well. Specifically, leaders know their position in an organization or system, as well as their strengths and weaknesses. Leaders takes time regularly to reflect upon their lives and values. This trait fits well with Agile teams, since reflection is a core Agile principle.8 The Agile leader values reflection and encourages team members to take time to reflect and evaluate themselves for the purpose of improvement. By contrast, when you have a more defined, plan-driven process, reflection is not critical. While organizations that follow a plan-driven approach seek to improve, the improvement process is also quite rigidly planned. These organizations often have a process engineering or process improvement group they charge with that task.
Not all managers are comfortable letting the "inmates run the asylum." In traditional organizations, each individual has a specific role and does not vary from that role, and their managers are happy with that. Leaders of Agile teams are different. They are comfortable letting the team decide how to get the job done. These leaders are comfortable with who they are and can be themselves and act naturally when they work with the team.
One thing that seems to result from self-awareness is the ability to know when to take the lead and when not to lead. Several years ago at an IBM® Rational® User Conference, Susan Butcher, the famous dog sledding "musher," gave the featured talk. Having won the Iditarod dog sled race multiple times, she talked about a situation where the dogs kept refusing to take a specific trail and she finally gave up and let them have their way. The trail she wanted to take collapsed and she would have most likely fallen to her death, along with the dogs. Her words about the lesson learned have stayed with me: "Sometimes you have to lead, sometimes you have to let the dogs lead." She certainly had to be aware of herself to be able to give up control to the dogs.
If you are working on a team, are you comfortable enough to let someone else lead? If not, you might have trouble becoming a leader on an Agile team.
Personal conviction: Any leader must have personal conviction. Technical and Agile leaders are no different from other leaders in this area. A leader who lacks personal conviction is a fraud and it shows. Employees in relation to their leaders are like children in relation to adults. They can naturally spot insincerity.
Personal conviction doesn't mean that you're always right. Before you take a stand, you should believe that you're right, but you should also have enough confidence to allow others to convince you that there are better ways of doing things. If you don't have the personal conviction and believe in what you -- and the team -- are doing, the best thing you can do is get out of the way and let them move ahead without you.
Courage: Courage means "mental or moral strength to venture, persevere, and withstand danger, fear, or difficulty."9 Courage cannot exist without personal conviction. The leader must have personal beliefs and be confident enough to have beliefs questioned. Courage is another Agile principle, but it is often misinterpreted.
Practitioners often think that having courage means they can forge ahead with a plan, regardless of the consequences. Actually, courage means having the strength and integrity to find and take the right path; this decision ideally comes after you've explored alternatives and understand the consequences of your actions and are convinced that what you intend to do is appropriate for the organization, team, and other stakeholders. This knowledge often results from applying tact, intelligence, experience, and judgment to the situation. Great technical leaders are masters at displaying courage.
In plan-driven organizations the goal is to follow a plan at all costs. One of the worst things someone can do is "upset the apple cart" by deviating from the plan. This leads to false -- or at least overly optimistic -- assessments of project status. One organization I worked for was scheduled to deliver a product on a certain date. For months the managers held weekly meetings where everyone gave their team's status. Reporting that you were behind was viewed as a black mark on the manager. If you reported that you were behind, you were expected to drive your team to work overtime and do anything necessary to catch up. Each week, the managers declared that their teams were on track. The week before we were scheduled to deliver one manager said his team was behind and needed two more months to get their work done.
What happened? Certainly the team didn't slip two months in a week. The problem is twofold. First, the manager did not have the courage to speak the truth. Second, the values of the organization discouraged delivering bad news. If you are going to lead an Agile team, you need to have the courage to speak the truth and let your team members speak the truth as well. To put this simply, the organization must promote the values that allow an Agile team to exist.
Creativity: One of my favorite traits in the list is creativity. I am fascinated by it, because what we often think of as creativity does not really convey its essence. Creativity is not simply doing something new and different. It is not ingenuity. A key aspect of creativity is the ability to generate ideas, alternatives, and possibilities. The creative leader helps the team generate these alternatives and evaluate their worth.
Creativity produces value (think "create"-ivity). Thinking outside the box is great, but the results of such activity must produce value to the team and organization. Simply finding a new way of solving a problem is not being creative. Finding a new way of solving a problem that is more productive and useful than other ways is creative. The most creative people I've worked with have been those who are grounded in the basic technologies and theories that exist and find ways to combine them to solve new problems or solve existing problems better.
Most readers are probably familiar with the Dilbert comic strip. Who do you think the most creative character is? My vote goes to Wally; not as a leader, certainly, but as a purely creative character. He generates highly creative alternatives for avoiding work, but Wally is not a leader because his creativity only produces value for him and not for the good of the organization. A creative leader will always focus on producing value to the organization.
Creativity is not unique to Agility. Good leaders need to be creative in all situations.
Curiosity: Curiosity may kill the cat but it fuels technical leaders. Good development teams and those who lead them are filled with curiosity. Just implementing a solution that works is not good enough for them. They create great software systems by asking questions that begin with "what if?" They need to know how things work, why things are constructed in a certain way, and how it might be better. Only when they satisfy their curiosity are they satisfied that they've done the best job they can in a specific situation.
The leader must allow the curiosity to run its course. The real talent of the exceptional leader is knowing how to channel the curious team in such a way that they know when to recognize the point of diminishing return. Great developers want to produce exceptional software, but the very best ones know how to assess when the product is good enough. Teams that adhere to Agile principles build software in such a way that they can easily tell when the product is good enough for their customers.
Ability to inspire: Living in Massachusetts I've been able to observe a great leader inspire a team. Bill Belichick, the coach of the New England Patriots football team, produces winning football teams consistently. Belichick is not a flashy coach, nor one who seeks the limelight. He works hard at developing and executing game plans and preparing the team for each game. He inspires his team because he is a proven winning coach. He has the experience and record to back him up. He has a strong set of personal principles and beliefs. When appropriate, he exhibits compassion and empathy for his players.
Great technical leaders, whether Agile or more traditional, are like Bill Belichick. They achieve their leadership positions partly from their past successes. They have a winning record, and a strong set of core values that they live by. I've worked with people like this and they are the ones I most fondly remember when I reflect upon my career. The "cheerleaders" who gave pep talks without establishing their position as a leader I quickly forget.
Ability to listen: Anyone leading a group of people must be able to listen. Susan Butcher listened to the team of dogs she was leading and it saved their lives. Listening is a skill that can be learned, but you must want to listen. Once again the theme of being yourself comes through. If you pay lip service to the team by hearing them but not listening, you're in trouble.
Let me explain what I mean by hearing and not listening. "Hearing" means that when someone talks to you, you understand the words, but it doesn't mean you agree or intend to act upon their words, and you might not give the person feedback. In short, it's possible that you hear the words and pay no attention to the content. "Listening," on the other hand, requires understanding and actual communication with the other person. Imagine that someone offers a suggestion on how to change a process. If you listen to the idea, and you are a good listener, you need to reply with constructive feedback. The idea might be good and you want to encourage him to proceed with it. The idea might need some additional thought. If you think it's a poor idea, you need to let him know why, and, perhaps suggest ways of making it better. Good leaders, especially on Agile teams, do this. They engage the whole team and help the team own the project.
Since Agile teams value face-to-face communication so much, you need to develop the ability to listen. Demanding status reports from the person sitting next to you won't earn you any points on a team, especially an Agile one. Agile teams find the best ways to communicate with each other and continually improve upon current practices based on themselves as a team and on the project they're working on.
Innovation: Innovation drives change, and Agile teams embrace change. The phrase "embrace change" became a characteristic of eXtreme Programming teams. Such teams welcome change in requirements, technology, and any other aspect of a project at any point in the project's life cycle. If you're not going to allow innovation, you can't possibly embrace change. Innovation and creativity go together. They support one another. A great leader will inspire the team to be innovative and creative and focus on delivering value. If you want a measuring stick for how you're doing, this is one of the best you can find. Does the team create, innovate, and deliver value consistently?
Innovation permeates Agile teams. A synergy occurs when the leaders embody all, or most of, the characteristics discussed here. The leader does not reserve the ability to innovate to herself. The Agile leader encourages innovation in all team members. The Agile technical leader, like a great manager, succeeds through the efforts of the team, not through individual heroics.
Eager to experience: The opposite of change is stagnation. If you're not changing, you're stagnating. If you're stagnating, you're falling behind. A productive team continuously modifies its practices and seeks out new knowledge.
Experience is knowledge -- not just experience in terms of time. Experience is best measured in terms of variety. Broad experience leads to open-mindedness and the ability to accept different views and cultures. At my university we encourage students to travel abroad to one of our project centers for at least one of their project experiences. What they gain by studying and working in places like Thailand, Hungary, Morocco, and Namibia is priceless. They return to the campus changed. They have a new perspective on life and scholarship and how they can contribute to society.
Academics take sabbaticals every few years to gain experience. That experience can be in industry, another educational institution, or anywhere. They come back to their home institution refreshed, renewed, and recharged. I often wonder why more companies don't promote sabbaticals for their employees. I believe that the return on such an investment would be enormous.
As a leader of a team, what are you eager to experience? Do you let your team experience the things that ignite their passions? If not, maybe you should rethink your leadership style.
Reflection: This really brings us back to the beginning -- self-awareness. You gain self-awareness through reflection. There is a cycle to what we and our teams do. The cycle is not, however, just a circle. It's a spiral, and we can either spiral upward to new and better experiences and results or down to defeat. Reflection is perhaps the most important attribute for Agile teams and their leaders.
Agile teams regularly reflect upon their performance and change their practices. They do this at any point in the process. After each iteration the Agile team looks at how the iteration went and whether there are any problems that need fixing. They give their process a tune-up if needed. They don't wait until the end of the project to do a "post" mortem.
The traits above are not necessarily new, nor are they specific to leading Agile teams. If you find yourself on an Agile project, however, you need to evaluate your style and what you need to modify to become a leader on that project. Here's the most important thing to remember: it's not about Agile, it's about success! Agile is a tool. It's not a means to an end.
- Readers might want to investigate the APLN at http://apln.org, specifically the presentation, The Dancing Agile Elephant, by Sue McKinney, Vice President, Development Transformation, IBM Software Group. (http://apln.org/steve.ppt).
- See my March 2007 article for more on the meaning of Agile: http://www.ibm.com/developerworks/rational/library/mar07/pollice/index.html.
- See http://www.wordinfo.info/words/index/info/view_unit/1/?letter=B&spage=3 for the story.
- See http://www.agilemanifesto.org/.
- Others in the figure are General George Patton, Julius Caesar, and Attila the Hun.
- The list contains (clockwise from the top left): Bill Gates, Grady Booch, Kent Beck, Steve Jobs, Martin Fowler, James Gosling, Jon Bentley, and Bill Joy.
- The article can be found at http://www.aacsb.edu/publications/Archives/SepOct05/p40-45.pdf.
- See http://www.agilemanifesto.org/principles.html.
- Merriam-Webster online dictionary, http://www.merriam-webster.com/.
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community
Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science.