Announcing the APLN Atlanta Leadership Summit

"Leading the Agile Transition"
September 25th and 26th
Marriott Atlanta Perimeter Center
summit.aplnatlanta.org

We are proud to announce that the next APLN Leadership Summit is coming to Atlanta!

For the past few years, local APLN chapters have organized and hosted regional Leadership Summits. These events have been very well received and attract fantastic speakers and exceptional local thought leaders throughout the agile community.

This is your chance to attend an Agile conference specifically designed to address the needs of the Agile community in Atlanta and the Southeast. Our speakers will discuss topics ranging from Product and Portfolio management to Agile Architecture and Metrics. Each speaker will present two talks, one geared toward the practitioner that is looking for tools and techniques they can use on a daily basis, the other toward leaders considering, or leading, a switch to Agile.

The summit is geared toward new and seasoned Agile leaders at all levels: organizational leaders, product leaders, development leaders, and project leaders. This is your chance to spend a whole day with some of the leading experts in the area of Agile Leadership, to network with with other agile leaders, and to share your experiences and concerns with those who are in the same situation as yourself.

The Dallas and Seattle Summits were a huge success! Next up is Atlanta!

The APLN Leadership Summit format includes:

• Networking opportunities throughout the day
• Speakers addressing how to lead their organizations to become agile.
• "Think Tank" sessions on Agile Leadership with topics addressing advanced leadership tools, experiences, lessons learned, and issues yet to be resolved.
• Networking social at the end of the first day to review think tank solutions and suggestions.

The APLN Atlanta planning committee has lined up an all star group of speakers and local Agile leaders. The conference is limited to 120 participants so you need to act now. If you are in the area, or able to make a the trip, the Atlanta Summit will be well worth attending.

For more information (including speaker bios and abstracts) and information on how to register, please visit the APLN Summit home page: http://summit.aplnatlanta.org

Subscribe to this blog

APLN Seattle Leadership Summit

For the past few years, local APLN chapters have been hosting regional Leadership Summits. These events have been very well received and attract fantastic speakers and exceptional local thought leaders througout the agile community.

The summit targets both new and seasoned Agile leaders at all levels: organizational leaders, product leaders, and project leaders. This is your chance to spend a whole day with some of the leading experts in the area of Agile Leadership, to network with with other agile leaders and to share your experiences and concerns with those who are in the same situation as yourself.

The Dallas Summit was a huge success! Next up is Seattle.

The APLN Leadership Summit format includes:

• Networking opportunities throughout the day
• Speakers addressing how to lead their organizations to become agile.
• "Think Tank" sessions on Agile Leadership with topics addressing advanced leadership tools, experiences, lessons learned, and issues yet to be resolved, decided by the group.
• Networking social at the end of the first day to review think tank solutions and suggestions.

David Anderson is lining up an all star crew to host the event. So far he has lined up the following thought leaders:

• Brent Barton, CTO, Solutions IQ
• Jim Benson and Corey Ladas, Modus Cooperandi
• Bruce Eckfeldt, Managing Director, Principal, Cyrus Innovation
• Mike Griffiths, Founder, Leading Answers
• Lisa Haneberg, Author
• Mitch Lacey, Accentium Senior Project Leader
• David Anderson, Founder of Modus Cooperandi
• also... Luke Hohmann, Jeff Patton, and Arlen Bankston
  

If you are in the area, or able to make a the trip, this event will be well worth attending.

For more information and to register, please visit the APLN Summit home page: http://www.apln.org/summits.html

Subscribe to this blog

The Message or the Messenger?

Sometimes we need to separate the message from the messenger. Whether we are talking about religion and politics or project management, there is often a disconnect between the message of the organization and the practice of the people in the organization.

Somehow when people get involved, the purity of the message is subordinated to getting stuff done.

We certainly see this in the Agile community. As people try to implement the principles, values, and practices they are forced to make compromises that sometimes don't feel very Agile. People on the outside will often even claim that Agile doesn't work because their particular implementation of Agile did not work. Was that failure because of Agile or because of the myriad of compromises we made along the way?

In all fairness, I think traditional methods suffer from this same disconnect between the message and the messenger. I can't find anywhere in the PMBOK where it says you have to do all the planning up front, but in practice, that is what often happens. Likewise, there is nowhere in that document that says you should not respond to change or adapt your plan, but again, that is how traditional methods are often implemented.

Is that the message or the messenger? It is inarguable that traditional methods lean more toward predictive project control and Agile methods lean more toward adaptation. In practice though, should we hold PMI accountable for advocating rigid up-front project planning? If so, we need to hold Agile responsible for advocating no project control and ad-hoc coding practices. We need to separate the message from the messenger.

Here is my take… you can run a software project using traditional methods. You can even run a highly uncertain project using traditional methods. You could use rolling wave planning and progressive elaboration. You could do most of the design up front and create a nice big Gantt chart for your project stakeholders. As we begin to build and learn more about the product, just document your changes, assess the impact to the triple constraints, and get stakeholder sign-off.

Send the team off to update their design documentation, recode the application, and retest anything that was impacted. Clearly if the change was approved, you have the additional time and budget to do all the work necessary to accommodate the change. If you dig deep enough into the PMBOK, you will find that everything you need is right there. You could even make the case that if you are not adapting your project and managing change, you are not responsibly managing your project.

So if the traditional processes have everything we need to support a highly adaptive project, why do we want to do so much planning up front? Why do we become so resistant to change?

Cost and time to market.

Traditional project management processes are heavy and slow. They make our products more expensive and take longer to build. Most of us are not willing to invest in the full adaptive capability of these methodologies, therefore, we try to take shortcuts. We believe that if we do our planning up front, and work to eliminate change, we can keep these costs in check. The root of this problem isn't that PMI processes don't accommodate change, they don't give us an INEXPENSIVE way to accommodate change.

As companies, we need to decide if we really have a strong enough business driver to use these heavyweight methodologies. What does your company value more: process control or cost and time to market? If you NEED this much structure and control, and I am sure that some of you do, by all means, leverage the full capability of the PMI planning processes and adapt through change management.

If you need to get product to market quick and inexpensively, because you know if you don't, your competitors will, you need something else. Agile methods are that something else. Don't pay the price of methodology unless it is absolutely necessary. Ignorance of another way is no excuse.

Subscribe to this blog

We're Agile, Now What?

You’re a PM working with a team that has just gone agile. Here are a few tips to help you be successful managing agile projects:

Understand agile team dynamics

Agile is about creating an environment where team members are fully engaged and empowered to make decisions. A good agile team is transparent and apolitical. It is a fun and safe place to work. A big part of your job as an agile project manager is to create this environment for your project team. The more you can understand about what makes agile teams work, the better positioned you will be to help them be successful.

Champion the project vision

Sometimes the team is going to get in the weeds. Your job is to help them stay focused on the big picture. Own the project vision. Keep it front and center during planning meetings. Use the vision to make sure the team stays on course. Keeping everyone focused on the goals of the organization is a huge contribution to your team and the business.

Remove obstacles

Listen to your team. Understand what they are telling you. Become an enabler by helping the team deal with the problems that are slowing them down. Be proactive and help anticipate risks. Deal with issues before they become impediments. Create a network of informed company leaders that can help resolve issues when they get too big for the team to deal with locally.

Focus on team building

Create opportunities for the team to have a shared experience. Create an environment where people can develop strong relationships at work. Help develop a sense of shared purpose and camaraderie. Great teams work together and like each other. Great teams are sensitive to each other’s needs. Don't let this happen by accident, be intentional about it.

Build consensus through facilitation

You have created a high performance team focused on the business vision. Get out of the way an let them deliver. At this point you become a facilitator for the team. Learn techniques that help people come to consensus and resolve conflict in a healthy way. Recognize ways to help ensure everyone on the team is able to contribute. Help the team find common ground and get moving.

Develop talent through coaching

Become a teacher. Help set expectations for the team. Most importantly, put people in position to be successful and give them the tools to deliver. One of the best ways to do this is to develop your coaching skills. Learn positive ways to give feedback. Create non confrontational ways to guide and instruct. Build relationships and be open to feedback in return.

Encourage structure and discipline

Maintaining structure and discipline requires energy. One of your primary responsibilities is to help the team maintain focus and protect the process. Encourage participation in planning meetings, daily stand-ups, and retrospectives. Help your product owners find time to maintain the backlog. Encourage discipline around agile engineering practices. Help the team understand how all the practices work together.

Help the team commit

Agile is about delivering on time… every time. On time delivery requires commitment. It requires the commitment of the team to deliver the sprint and the commitment of the product owners to adjust as we learn more about the evolving solution. As an agile project manager you can help create a sense of shared ownership and a culture of collaboration and cooperation amongst all the team members.

Get help when you need it

Having a good support system is essential . Find people on the same road to share the journey with you. Seek out people that have travelled the road before you. Join user groups and share your ideas. Join organizations and find ways to contribute. You will learn much along the way. Never hesitate to ask for advice.

Be patient and stay the course

You are going to have challenges and you are going to make mistakes. There is a learning curve and some old habits will die hard. Hold yourself accountable and learn from your mistakes. Most importantly, don't give up.

Being an agile project manager is about being a great leader. It is about accepting input from reality and responding to it. It is about looking out for the best interest of the team. Seeking out what is not being said. Helping to bridge gaps in understanding. Exposing what is hidden.

There is no success for anyone unless we are all successful. By working for the success of the team, you are working for your own success. You cannot have one without the other.

Here is a link to my post on Agile Chronicles: http://blog.versionone.net/blog/2008/03/were-agile-now.html

 Subscribe to this blog

Restrooms, Canoes, and Agile Metaphors

I came back to my desk yesterday and it was gone. Yep... just empty floorspace where my desk used to be. As you might imagine, VersionOne has a pretty mobile floorplan. Wireless internet and lots of power everywhere. The environment is pretty conducive to moving furniture around so people that need to work together can easily relocate.

After finding my desk missing, I went looking for it. I walked around upstairs, no desk. I walked around downstairs, no desk. I looked outside and then started exploring conference rooms... no desk. Hmmmmmmm. Where might my desk have gone? Well, it seems the dev team decided to play a little trick on me. They moved my desk into the ladies restroom. Nice.

To add insult to injury, they took pictures and posted them to the company blog. Check out http://www.agilechronicles.com/ for pictures and commentary. I have to admit that it was pretty funny having full power and internet access, all my books and even my lamp all crammed into a bathroom. Imagine the productivity gains not having to step away when nature calls. The possibilities could be endless.

It was a nice reminder that work does not have to be serious all the time and you have to be able to laugh at yourself. Now I have to figure out how to get 'em back! Paybacks can be hell.

On another not-so-serious note... I got a canoe a few weeks back. I really like my canoe. Even better, I like that I got a really, really good deal on a used one I found from a seller nearby my house. I had the opportunity to take my kids out a couple of times last weekend and we managed not to flip it over in the lake. We have some family coming up from Florida this weekend and I think we'll take it out again. Hopefully we'll have similar luck.

Activities like canoeing are great agile metaphors. It is all about heading out in a particular direction, course correcting along the way, paying attention to your environment, and adapting as you go. You have to communicate with your partner to get the canoe going in the right direction and to establish a stable velocity. You need to collectively maintain balance so you don't tip over. Sounds like a good blog for another day.

Life is good! Thanks for listening :-)

 Subscribe to this blog

The Agile Elevator Speech

Okay… so you find yourself in the elevator with your CEO. She asks about the agile project your team is piloting. She wants to know what this agile stuff is all about. You have 30 seconds... go!

You begin by stating that agile is basically three things: a set of engineering best practices that allow for rapid delivery of high-quality software, a project management process that encourages frequent inspection and adaptation, and a leadership philosophy that encourages team work and accountability.

You go on to say that success in today's economy requires us to respond quickly to changing market conditions. Agile processes allow our teams to meet the changing demands of their customers while creating environments where top developers want to work.

Your CEO is intrigued and invites you to walk to her next meeting. She wants to know more. Mission accomplished.

 Subscribe to this blog

Strategy as Simple Rules

"Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior. " - Dee Hock, Founder and Former CEO of VISA International

My wife and I help run a small private school in our spare time. That pretty much means that we don't have much spare time left for anything else. Creating this school has been a great learning experience and can be very rewarding. It can also be very difficult at times balancing the competing needs of all our school families. It has taught us many lessons about what you can accomplish if you put your mind to something, are willing to work hard, and are willing to adapt.

When we started this school, the founding members decided that we value small class sizes and affordable tuition. This philosophy has proven to be a key differentiator for our school and has allowed us to more than double in size over the past year and a half. That said, a business strategy that calls for fewer customers and less revenue can be a little risky. As you might imagine, we have to run a pretty tight ship to keep our little school afloat.

Regardless of the challenges we have faced over the past several years, we have always come back to the idea that we must have small class sizes and affordable tuition. When we are tempted to add more students and ease the financial pressure, we think back to why we founded this school and what makes is special. When considering a tuition increase to provide more services, we think about our promise to keep tuition affordable.

These simple rules have formed the basis of what has become a pretty complex strategy. The rules give guidance to the kinds of teachers we can hire, how we moderate our service offerings, our organizational structure, and our recruiting. The rules form the basis for both our short term and long term growth plans and ultimately shape our vision for the future.

In short, the rules provide a framework to guide our more complex day-to-day decision making.

Even though our school is a non-profit, some days looking more like a ministry than a business, we exhibit all the characteristics of a small startup. We are learning our market, we are learning our customers, we are learning our employees, and as leadership, we are learning each other. It is impossible to predict everything that we will encounter along the way, so by necessity, we have to be open to change… willing to adapt.

Our growth this year has been very challenging. It has stretched some of us to our limits with regard to what we are willing to personally sacrifice to make this school work. People are unpredictable and our school is full of them. It is very tempting to want to put rules in place to manage that unpredictability. We have struggled to stay focused on keeping things simple, to engage people in a way that is empowering and affirming and makes them want to be a part of our school.

We are learning, we are trying to adapt, and to that end, we are extending our simple rules strategy.

Right now we are working to identify our key roles and our key processes. We are looking for a few simple rules to guide how each one operates. Just like we have a few simple rules that influence how we manage our business, we are looking to identify a few simple rules to give direction to our staff and volunteers as they manage their day to day activities. The idea is that as we grow, we want to empower more people to be in charge of more parts of our school.

As leaders, we create opportunity and provide direction. The simple rules will give our team guidance on how to operate in alignment with that direction. Just think what we can accomplish if we are able to tap into the power and creativity of our entire school family; to allow our teachers and volunteers to make decisions, to adapt to their immediate surroundings, all the while staying in alignment with the direction we have set before them.

I think that is pretty powerful stuff and I am excited about what we will certainly be able to accomplish.

More on our school at: http://www.hopespringscs.org

 Subscribe to this blog

At Peace with Paper

I am an admitted Blackberry addict and I love new gadgets. That said, there is just something organic, something spiritual about scribbling on a piece of paper. I just can't seem to shake my attraction to paper planning. I love jotting down ideas and circling key concepts. Being able to draw a line between two related concepts is powerful. Using different colors to show transitions and to communicate emphasis richly expresses what words do not. There is a place in my soul that won't be satisfied with a little electronic checkmark next to a finished task. I need to write.

But as much as I love my planner, it does have its limitations. If I want to share my ideas with anybody, I have to either photocopy them or rewrite them electronically later on. No one else is able to see my calendar so coordinating schedules becomes a pretty labor intensive task. I am never totally sure if my wife has me booked someplace and I just forgot to write it down. I have yet to figure out a way to make it receive email and it won't automatically remind me of anything. Did I mention that I am totally screwed if I leave it on the roof of my car?

I've been fighting this internal battle for the better part of 20 years. I would go through periods of time where I did nothing but paper planning but inevitably the limitations we just discussed would pull me back to using something electronic. When I would decide to go paperless that part of my soul in search of free form expression would pull me back to handwritten notes. After all this time, I've come to the realization that neither approach is going to give me everything I need in a planning tool, so for now, I am going to use both.

I think there is a lesson here that we can apply in our agile projects. It doesn't have to be one or the other when it comes to planning. If we are all in the same room collaborating, exploring new ideas, and everyone is able to see and touch the same information; paper and whiteboards are the way to go. When the job requires us to manage large amounts of data, to coordinate over distance, or an ability to look at data from many different angles; software can do that much more effectively than paper.

It is really just a matter of blending the two approaches in a way that allows us to be most effective as a team and deliver the most value to our customers.

Here is a link back to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/at-peace-with-p.html

 Subscribe to this blog

Advice or Approbation?

"We ask for advice, but we mean approbation" - C.C. Colton, English Cleric (1780 - 1832)

I came across this quote over the weekend and it caught my attention. I would love to say it caught my attention because of it's profound meaning and depth of insight. In reality, it caught my attention because I did not know the meaning of the word approbation.

Well come to find out, the word approbation means approval. So said another way, the author is telling us that when we ask for advice, we are not really seeking advice, we are really just looking to have our own perspective validated. That proved an interesting and insightful observation after all... but is it true?

Colton's observation led me to think back to a book I read in college called The Structure of Scientific Revolutions by Thomas Kuhn. Kuhn was writing back in the 60's and popularized the terms paradigm and paradigm shift that are now so prevalent in today's business literature.

Kuhn postulated that paradigm shifts happen in three phases: pre-paradigm, normal science, and revolutionary science. A shift to revolutionary scientific thought usually takes place after a period of crisis. Prior to such a crisis, people look for ways to fit the observed data into the existing models. When anomalies in the data force us to reconsider the foundations on which our scientific worldview is formed, we have the beginnings of a paradigm shift.

It seems that most folks are not out looking for new ways of doing things. People are generally just looking for evidence that validates their current point of view. They are so comfortable with the old ways they will go to great lengths to ignore anything that challenges their current perspective. If people blind themselves to the data, where does that leave us as leaders of change?

Kuhn offers a not-so-encouraging quote for us to ponder:

"A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it." - Max Planck, German Physicist (1858 - 1947)

What is it going to take for us to revolutionize the software industry? What can we do to create a sense of crisis? How can we demonstrate that old solutions won't solve our current dilemma? How do we effect the wide scale change necessary to revitalize our industry?

One company, one team, one leader at a time?

For more on Kuhn and The Structure of Scientific Revolutions, check out the following Wikipedia article:
http://en.wikipedia.org/wiki/The_Structure_of_Scientific_Revolutions

And here is a link back to my orginal post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/advice-or-appro.html

 Subscribe to this blog

Peace, Love, and Agility?

I am fascinated right now by the question of what comes first… agile thinking or agile doing? Does the agile mindset have to precede implementing agile mechanics? Could we lead an agile transition by implementing the structure of agile and coach people into thinking agile while we do it?

Last night I happened to be listening to an audio version of CS Lewis’ “Mere Christianity”. I was in a section of the book where Lewis was talking about the idea of Christian love. He was making the point that God expects us to ACT with love towards others even if we do not FEEL love towards others. The act of treating people with love would engender the feeling.

As you might imagine, that got my attention. Here I am driving home contemplating the relationship between religion and agile leadership.

Don't feel bad, my wife thinks I am strange too.

Peace, love, and agility? What's this guy talking about? I guess I better hurry up and make my point. Let me do that by sharing a couple of examples...

As a married person, I may not always feel love toward my wife. There might be times when I don’t even like her, but… I am always expected to treat her with love. If I consciously act in a loving way, it will create space for the feeling to be sustained.

I happen to be a Catholic. Over the past few years I have worked quite a bit with the teens in my Church. Teens tend to have issue with all the “rules” in Catholicism. They just don’t get why we have all the rules. If the message of the Bible is love, isn't that all that matters?

My typical answer goes something like this… yes, the message is love. That is all that matters. The challenge is that as human beings, we don’t always understand what love really means. I often use the example of two teens that use “love” as a justification to have premarital sex. The rules of the Church around sex help us to understand what a right understanding of love really is.

Are the rules around sex the main point of their existence? No. Do they help us along the way to understanding what it means to love and to love consistently with how God loves? I think yes. The rules, the mechanics if you will, bring us closer to the truth. They are a means to an end, not the end itself.

So our question remains… can the rules of agile help us develop agility where it does not exist? Can we be asked to behave in an agile way regardless of how agile we might feel at any given moment? Can structure create better agilists? If acting with love can engender loving feelings, can acting with agility engender agile thinking?

I think so. I would be interested to know what you think.

The Road Less Traveled By

"Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference" - Robert Frost (1874 - 1963)

As leaders, what prevents us from letting go and empowering our organizations?

In my earlier post "The Road to Agility" I encouraged teams to begin their Agile journey by proving themselves trustworthy. The idea was that we cannot expect leaders to empower a team when that team has not proven itself ready to be trusted.

Well what about our leaders? These folks need to have some skin in the game as well, right? What might be a good first step for a leader that wants to build an empowered, self-directed team? I suggest that as leaders, the first step is to challenge our motivations and learn to control our ego.

As leaders we are ultimately accountable for the performance of our organizations. As such, a poor performing team is a reflection of our ability to do our job. It is our duty to make sure the team is performing well because we will be held accountable. To take it one step further, a poor performing team will make us look bad.

How we see ourselves as people can make a big differences in how we choose to respond. How well we keep our egos in check can make all the difference.

If we allow our self-worth to be tied to the performance of our team, we will be inclined to get performance at all costs. With a team that is struggling, the leader is likely to create a rules based system that measures performance based on process rather than results. Any bump in the road is an attack, any deviation from plan a threat to us personally. When the team does well, the leader is likely to take the credit and share little of the glory.

The team becomes a vehicle for validating us as individuals.

Separating our self-worth from team performance allows us the freedom to operate as a mentor and coach. We seek out opportunities for the team to develop and gain new experiences. We create structures that allow them to be successful. We look for ways to recognize members for their contribution. We desire to serve rather than be served, support rather than command, and empower rather than control.

We as individuals become the vehicle for validating the team.

As leaders, we are always going to be accountable for the performance of our teams. How we respond to that challenge will make all the difference in our ability to embrace Agility. Challenge your motives and ask yourself what you desire as a leader. Ironically, the less you can make it about your success, and more about the success of the team, the more successful you will be in the end.

What you bring as a person, what road you choose, will make all the difference.

Link to orginal post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/the-road-less-t.html

An Afterthought

I've got a question for you... Do the same rules for leading volunteers apply when leading employees?

We pay people to come to work but can we buy their enthusiasm and creativity? What about their passion and excitement? Maybe we need to consider applying the same or similar leadership principles in our businesses that we've discussed for our volunteer organizations? Do we need to modify our list for business and employees? Let me know your thoughts and what's working for you.

Here's a link to my original post on Leading Volunteers:
http://www.leadingagile.com/2008/02/leading-volunteers.html

Leading Volunteers

Are you a part of a volunteer organization? Lots of us are. You might be a member of a Church, some sort of professional organization, or even your local outdoor club.

I am involved with several. I am the Treasurer of APLN, the President of a small private school my wife and I helped start a few years ago, an adult leader with The Boy Scouts of America, and an active member of my Church. It seems that all these groups have one thing in common; they need more people to help. Said another way, it seems that the same few people are doing almost all the work. Sound familiar?

Being a leader in many of the organizations I support, I have begun to see a pattern. When we feel like we are doing more than our share of the work, we tend to get upset with the people who aren't. We are so passionate about what we are doing it is beyond us why everyone else is not driven to that same level of performance.

I'm not making excuses for anyone but people are just spread too thin. Between our jobs, our families, getting the kids to their various activities, and trying to find some time to relax; there is just not enough time in the day to be consistently involved. As leaders, this is our reality. So then, what can we do to increase the number of people willing to chip in and do their part? What could make the work of our group so important that people would make time in their busy schedules to volunteer?

I've become pretty convinced that telling our volunteers to step up or leave won't work. Most of them will probably just leave. Likewise, mandating some set number of hours they have to work probably won't do it either. Those folks will probably leave too. We want people that are passionate about our organizations. We want the people that want to do their part. Do we really need a bunch of guilty people dragging around out of some perceived sense of obligation? I don't think so.

I suggest that we begin by letting go of our negative feelings and start taking responsibility. You just can't lead effectively running around hacked off at your membership. Chances are you missed some things along the way that could have helped people get more involved. Let's take a few minutes, figure out what those things are, and let's get busy doing them. No more whining, got it?

So here goes Mike's list of nine things you better be doing if you want to effectively lead a group of volunteers.

1. Have a Compelling Vision
Let's create a vision that really gets people excited, inspires them, and shows them what is possible. A well crafted vision communicates where we are trying to go, what mountain we are trying to climb. Involve your volunteers in creating the vision. Give them some say in what you'll do as an organization to make the vision a reality.

2. Provide Opportunities to get Involved
Opportunities must be right there and readily available. We must make it simple and clear what needs to be done and what they can do to help. People don't always want to figure those things out for themselves, they want to be led. They want to know what to do and how their contribution supports the overall mission of the group.

3. Give People Simple Guidance
Folks only need a few rules to help them along the way. Guide rails if you will to instill the internal confidence that they are headed down the right path. They need to know they are doing the right things and that your organization will stand behind their efforts.

4. Get Out of the Way
Nothing kills initiative like being told how to do something. Once you have given your team their objectives, leave it up to them how the work gets done. You'll have to accept that some work won't be done exactly like you would have done it. As long as it furthers the goal, let it go.

5. Follow-Up
This communicates to the team that their contribution is important. Review deliverables and help your team to adjust if something does not get done. Agree on the impact of the missed objective and what each of you will do to help recover.

6. Accountability for Results
You have given your volunteers important work. They have accepted their mission and taken your guidance to heart. Outside of moral, ethical, or legal issues; you are holding the team accountable for what was delivered, never how they got there. Holding people accountable for results taps into their creativity and energizes their passion. Now we are really getting somewhere!

7. Make It Okay to Make Mistakes
People will feel more comfortable taking initiative because it is safe. They won't feel like they have to be perfect in order to contribute. People taking initiative is key in a healthy volunteer organization.

8. Give Praise.
People want encouragement, they need it, they thrive on it. Many people never ever hear they are doing a good job. If your organization is the one that tells them, just think what a powerful motivator that could become. As leaders, it is easy to take our volunteers for granted because we are working so hard ourselves. They need it, so make it happen.

9. Have Fun
People don't want to work with a bunch of grumps. Enough said.

At the end of the day, we all want empowered, motivated, and self-directed volunteers that are working toward our common goals. If that doesn't sound like the people in your organization, take responsibility. Look first at how you are leading your organization and if you are doing everything you can to create opportunity and empower your team.

We get so caught up in the work of our organizations, we often don't take time to really lead them. Giving people a means to serve and the guidance to serve well is a powerful contribution. It is probably the most powerful contribution you can make to the long term health of your organization.

If you have something to add, please leave a comment. Feel free to disagree with the nine items I chose. These just seemed to me to be the most essential. I look forward to your feedback.

Good luck, lead well.

Link to orginal post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/leading-volunte.html

The Road to Agility

"Freedom consists not in doing what we like, but in having the right to do what we ought" - Pope John Paul II

"The more you tighten your grip Tarkin, the more star systems will slip through your fingers" - Princess Leia, Star Wars

Moving towards a more agile management approach is hard. Agile is hard because it requires a tremendous amount of trust. Trust can only be developed over time and must be earned. Managers must trust their employees to work in the best interests of the business. Teams must trust their management to create a safe environment where they can be successful. We must both be looking out for each other's best interests.

Unfortunately, many organizations are not high trust environments. Controlling management hierarchies, office politics, and disempowering policies have created a culture where people expect to be told what to do instead of using their own judgment and initiative. People are not encouraged to offer their best thinking and are rewarded for playing by the rules. This slows down delivery and damages the overall effectiveness of the organization.

Businesses always demand more for less in a competitive market. This creates pressure for more productivity while at the same time productivity is being eroded. To get better results, management introduces more rules and more governance. Employees closely follow the rules because that is what is expected. This cycle continues until the management overhead becomes an impediment to completing any of the real work and no decisions can be made without management's explicit consent.

Current thinking in the project management community is reflective of this flawed paradigm. In an attempt to get better project performance, we plan more, create more documents, deliver more frequent status reports, and try to hold people accountable for tasks on a plan. We slowly begin to hold ourselves accountable for the process and lose focus on delivering real value to our customers.

This process focus becomes so overwhelming that we find ourselves with either a suffocating bureaucracy or too little real day-to-day management of the project.

Agile seeks to solve many of these problems but methodologies are not transformed overnight and cultures take time to adjust. We cannot ask managers to abandon traditional management techniques without giving them alternate means to make sure their projects are delivering value to the organization. We cannot expect team members to self-organize and be empowered when they've seen so few first-hand examples where this has been rewarded.

We need a roadmap for helping teams incrementally adopt Agile. We need a framework for building trust in an organization. This framework must start with changes people can easily get their heads around and implement without losing focus on our desired end result. The agile community has focused on where we want to go but not enough on how we plan to get there. Trust is not sufficient until we prove ourselves trustworthy.

It may sound paradoxical but the path to agility begins with structure and discipline. Our goal is to create an environment of total transparency and accountability using techniques people can begin doing immediately. Making and meeting commitments is where it all begins. Establishing a routine pattern of delivery is key. Regardless of what methodology we are using now, regardless of our current project plans, let's begin the journey by focusing on making and meeting commitments.

Link to original post on Agile Chronicles:
http://blog.versionone.net/blog/2008/01/the-road-to-agi.html

Covey's 4 Disciplines of Execution as an Agile Framework

Stephen Covey, in his bestselling book "The 8th Habit: From Effectiveness to Greatness", outlines four disciplines, that when consistently applied, result in high performing organizations. The Agile movement is based upon a value system and specific core practices, that when consistently applied, result in high performing software development organizations.

Establish Wildly Important Goals: A team can only focus on 1-3 things at a time and be successful. The more goals we add to the list, the lower our chances of delivering any of them. Make sure you are focusing on what is really important.

Agile teams partner with the business to establish a goal for each iteration. The goal is established to deliver the highest value to the business and mitigate the most risk. Every member of the team is collectively responsible for delivering on the goal of the iteration.

Translate Strategy to Tactics: So you know what your goals are, now what are you going to do about them? For an organization to be truly effective, leadership must help the team translate the lofty goals into meaningful action.

Once the goal has been established, Agile team members volunteer for specific work that will contribute to the meeting the team's goal. These work items are immediately decomposed into tasks and the team members self select these tasks. This becomes the detailed work plan for the iteration.

Create a Compelling Scoreboard: High performing teams play to win. If someone is going to win, you have to keep score. A scoreboard that clearly demonstrates team progress toward its goal generates excitement and enthusiasm. A scoreboard motivates.

Each iteration ends with an increment of the product that can be reviewed by the business. Delivery of working software is one lead indicator the team is making progress. Other lead indicators are the number of story points (or possibly ideal engineering hours) the team was able to get accomplished during the iteration. Agile teams often create burn down charts to show the rate of progress against their ultimate goal of delivering a complete system. Because these measures are based on real software delivered to the business, they are accurate indicators of the overall health of the project.

Hold Each Other Accountable: Accountability is the key. As individuals, we have to understand that there are others that are counting on us to deliver. There must be some consequence for failing to deliver. Shared accountability drives performance.

Agile teams are accountable. Accountability begins with the iteration planning meeting. This is where the team recaps what was accomplished in the previous iteration and plans what it will do in the upcoming iteration. The team must demonstrate its progress and show what it will do to meet the overall objectives of the business. The team members are also accountable to each other during the daily standup meetings and retrospectives. Most importantly, Agile teams are accountable for delivering a complete working solution that meets the needs of the business.

Agile is framework around establishing a culture of empowerment, lifting the individual, and tapping into the vast reservoir of human potential and creativity. Agile is a foundational set of principles, coupled with a ever evolving toolkit of specific practices, for focusing the team on what is most important to the business, working with the business to decide what tasks will deliver on that goal, establishing measures for key lead indicators such that the team always understands its progress, and encouraging a culture of trust and accountability that will ultimately drive performance.

Does the Agile Project Leader Exist?

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 servant-leader is a servant first. It begins with the natural feeling that one wants to serve. Then conscious choice brings one to aspire to lead. The best test is: do those served grow as persons; do they, while being served, become healthier, wiser, freer, more autonomous, more likely to become themselves servants - Robert K. Greenleaf
  
  
• The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it. - Theodore Roosevelt
  
  
• Management is doing things right; leadership is doing the right things. - Peter F. Drucker
  
  
• Leadership is the art of getting someone else to do something you want done because he wants to do it. - Dwight D. Eisenhower
  
  
• Don't tell people how to do things, tell them what to do and let them surprise you with their results. - George S. Patton
  
  
• Leadership is communicating to people their worth and potential so clearly that they come to see it in themselves - Stephen R. Covey

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.

Agile Manifesto

• 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.