Simple Messaging

There is great power in a simple message.

There is value in being able to articulate one way of doing something. When we are just learning, there has to be one way of doing things that will work for many of the situations we are most likely to encounter. That one way needs to be simple enough that the beginner can understand what to do, how to do it, and be assured some degree of success.

The trick is that the context has to be basic enough that the rules will work most of the time.

If we don't continue to develop our skills, to go past the simple messages, we will never become effective in more complex problem domains. Our world is full of folks that have never progressed past the simple messages we learned when we were beginners. We must recognize the limitations of the early messages and develop strategies for dealing with a more complex world.

As we gain experience and move toward mastery, prescriptions fall away and the messages become meaningless.

 Subscribe to this blog

Subscribe to Leading Agile

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

Subscribe to Leading Agile

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

Subscribe to Leading Agile

Planning for Value

"Reduce your plans to writing. The moment you complete this, you will have definitely given concrete form to the intangible desire" - Napoleon Hill

"Plans are of little importance, but planning is essential" - Winston Churchill

"No battle plan survives contact with the enemy" - Colin Powell

One of the most significant contributions of the Agile community has been the realization that creating software is an uncertain business. Unfortunately, this realization has led some of us to the conclusion that the act of creating software cannot be planned. There is a big part of me that can empathize with this point of view. What's the point of creating a plan if we know the business objectives are going to change, requirements are going to change, and even technologies are going to change? I have worked in many traditional projects where change management was the single biggest part of my job. Why not just get going and see where we end up?

The challenge is that business planning doesn't work that way. Product owners are asked to create their business cases months in advance of the upcoming fiscal year. Once funding is approved those guys are on the hook for the revenue. This is a big part of our reluctance to let go of the big up front planning processes. As businesses, we want some sort of assurance that we can deliver on our revenue targets. To these companies, funding a project with only the promise we'll get the most important features first is not very reassuring. We must KNOW that those features are going to deliver the EXPECTED value. Our jobs depend on it.

When the context we operate in is uncertain, we have to plan for that uncertainty. To do this, let's look at the following three planning alternatives:

Make sure the project will yield an acceptable return with less than 100% of the desired features.

Sure… I want a crystal ball too. Problem is we don't have one. If we have a firm date, a firm cost, and a fixed set of features; odds are we are going to fail. If time and cost are king, we have to be flexible on features. We need to know up front that we can go to market with less and still produce acceptable value to the company.

Commit to high level features so team has room to negotiate through the life of the project.

In most corporations, there are at least a few other teams that must know ahead of time what you are going to deliver and when. Marketing comes first to mind, so does sales. For those guys to be successful, they need to know what is going to be delivered much earlier than most of us are willing to commit. Committing to high-level features gives us enough specificity to communicate about the product while allowing the team to fine tune the implementation of those features as the product progresses.

Manage the project's value stream rather than changes to features or tasks.

We know that project requirements are going to change along the way. They should. As we build the product we are going to learn more about what we need and how best to build it. Those changes still need to be managed. The company decided to invest so many dollars to yield a particular return. Do we know how any given change will impact the value of the product? Let's start looking at how our changes impact the metrics we really care about... value.

Let's not be afraid to plan in the name of agility. Let's just be smart about what we are planning and leave ourselves room within the plan to be successful. At the end of the day, it is the value that we deliver to the organization that matters, not how well we followed the plan.

Here is a link back to my post on Agile Chronicles:
http://blog.versionone.net/blog/2008/02/planning-for-va.html

 Subscribe to this blog

Subscribe to Leading Agile

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. Subscribe to Leading Agile

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 Subscribe to Leading Agile

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 Subscribe to Leading Agile

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 Subscribe to Leading Agile

I Want Control

As an Agile Project Leader, I feel like I have lost control.

In my last post "The Road to Agility", my original premise was that in order to be trusted, we have to be trustworthy. To earn the trust of our organizations, teams have to consistently deliver. To deliver regularly, we have to have structure and control.

I wimped out. I substituted the word discipline for control because I was concerned I would lose my audience. I was afraid people would react to the word control and stop listening.

I lost control, now I want it back.

As an Agile Project Leader, why should I be scared to use the word control? As a community, are we scared to be in control of our projects? I sure hope not.

But wait... we want collaboration, not control.... right? Control suggests authority. It suggests top down management. It suggests all those outdated project strategies we have seen fail time and time again.

Maybe when we talk about control, we just need to be specific about what we are controlling. Are we controlling people or are we controlling processes? Are we trying to control using predictive methods or recognizing the need for empiricism. These things matter when we talk about being in control.

As I write this, I am on a plane to Denmark. I sure hope my pilot is in control of this aircraft. Does that mean he knows every pocket of turbulence or mechanical issue we might encounter? Of course not. I do expect him to know where he is, to measure frequently to make sure we are on track, and adjust if we are not. I have to trust he will know we are off course long before we find ourselves out of fuel and having to land short of our destination.

Control on an agile project is all about visibility, inspection, and adaptation. You need to know what you have delivered and what is left to do. You need to know where you are at all times in relation to your goal. When you adjust, you need to be able to understand and communicate the impact to where we thought we were going.

Just like the pilot relies on a skilled support team to help him stay in control of the aircraft, the agile leader needs to collaborate with the team to maintain control of the project. It is not either collaboration or control, we must have both.

Don't be afraid to be in control of your projects. Your teams and your business owners will thank you for it. Subscribe to Leading Agile