Friday, February 1, 2008

Agile Politics?

I admit it. I have become a political junkie over the past month. It was bound to happen I guess, living in Iowa home of the country's first caucus, and seeing first hand the excitement being generated by this election cycle's slate of candidates.

As a result of becoming a politics addict, I have taken to listening to the POTUS 08 channel on XM Radio during most of the day. It's a great channel because not only do you get to keep up on what all of the candidates are doing, but you get to hear the speeches that they and their surrogates are giving, and perhaps more relevant for application to projects and business in general, you get to hear about how the process of elections work, and from this you can glean some information that is very helpful in other pursuits.

This morning while driving into work, there was a segment focused on the strategy of elections, and the commentators were talking to a member of the Hillary Clinton campaign. Low and behold, the word "agile" came up in reference to the approach that campaign has been taking to last several weeks. You see with the way the early race has been structured, with Iowa on January 3, New Hampshire a few days after that, then South Carolina, and then Nevada (Michigan and Florida happened in there also, but didn't provide any delegates - yet). The person from the Clinton Campaign (I unfortunately can't remember her name) commented that they have actually been running a series of mini campaigns, dare I say iterations, between each election. Each state has different demographics and "electoral math" so require different emphasis and different strategies as far as where to focus and what to focus on. I have no doubt the core beliefs being addressed in these campaigns was the same, but the points of emphasis and the manner in which they were expressed were different to appeal to the relevant audience.

I like to describe agile leadership in terms of seven characteristics: Collaborate, Iterate, Serve The Team, Consider Context, Practice Excellence, Reflect and Adapt, and Deliver Value. The example I described above beautifully illustrates the use and interdependence of two of those characteristics: Iterate and Reflect and Adapt. The Clinton campaign made the choice to focus on the next primary or caucus (the sports metaphor of one game at a time) and determine their approach, their points of emphasis, and the places they were going to speak, based on the current status of the race, and things that have happened in the future. You also have seen how they have adjusted the context in which they shared their message between the different contests. After a third place showing in Iowa, they went on the attack in order to try and regain some momentum, which happened in New Hampshire, which they did. Seeing that work, they ratcheted up some more going into South Carolina, which drew some criticism, and so now you see the adjustment again going into Super Tuesday. Your thoughts about the message and the messenger aside, this is a very clear example of how looking at an endeavor as a series of smaller interim endeavors with the ability to reflect on what has come before and the current state of things in order to change your approach going forward can be very effective when you work in a dynamic and changing environment.

Reflection and adaptation make using an iterative approach that much more effective, because it provides information to help you adjust your approach. Without reflection and adaption, following an iterative approach just means you are technically insane - doing the same thing over and over again and hoping for different results. On the flip side, reflecting and trying to adopt when following a non iterative approach can be somewhat helpful, but it becomes difficult to decide when to pause and reflect, and often times even if you do identify things you could do differently, you may not have the opportunity to try those things out in order to aid the current effort.

I guess the key thing to take from all of this is that agility isn't so much a methodology as it is a way of thinking and approaching the work of teams. It may have been given a name by those in the software development community, but that doesn't mean it isn't applicable in a lot of other settings.

Saturday, January 19, 2008

Analysis Does Not Have to Mean Paralysis

Back in November in Iowa Biz there was a blog entry titled Please Make A Decision. The basic premise of the post was a call to action to actually make a decision and stop suffering from "analysis paralysis. On the surface, pretty good advice. But dig a little deeper, and that post is really encouraging people to follow their typical human distaste for uncertainty and make a decision without the benefit of the relevant information. So can there be a middle ground?

You bet. It is neatly summed up by the concept of Real Options, described neatly by my friend Chris Matts with these three simple points:

  • Options have value.
  • Options expire.
  • Never commit early unless you know why.

Said another way, it's okay to defer making a decision in order to gather as much relevant information as possible as long as you make the decision before the value you can derive from the various options starts to decrease or goes away all together. Often when people suffer from Analysis Paralysis, what they have really done is delayed making a decision past the expiration date of the option. It's about gathering the right amount of information to make the appropriate decision, but not spending so much time on information gathering that you loose the opportunity to gain value from the decision.

Tuesday, November 20, 2007

Good Blog Post on TDD for Databases

Gojko Adzic presented at XPDay 2007 about his experiences with Test Driven Development in a heavily database focused legacy application. He then posted his experience report on this blog post

I have always been a believer in experience being the best teacher, so am always happy to pass along interesting descriptions of people's experiences combining the somewhat disparate worlds of agile software development and database development.

Monday, October 15, 2007

Creating Effective Teams Podcast on pm411.org

In September, I wrote an article in my ProjectConnections.com column titled Picking the Right Project Team. Ron Holohan with PM411.org liked the article enough to call me up and talk to me about it during his pm411.org podcast, which you can find here.

Sunday, September 30, 2007

Is Delivery Date the Only Thing

In the September 2007 Issue of the PM Network there is an article titled "The Need to Speed". According to th article a survey of project managers around the globe that indicates that there seems to be a problem with on time delivery of IT projects. When you look at the cold hard reality of things, this should not really come as surprise to anyone. Aside from the fact that the article never mentions how the deadlines were set and by whom, the article concerns me because of it's suggestions on ways to address projects coming in after deadline.

Even though the advice is listed as the opinions of the people who took a survey, the fact that these particular answers are being pointed out in the article, causes the information to take on a little more importance.

The statement in the article that really caught my attention, and confirmed my fears that traditional PM thought and training is focused on the wrong thing is this statement below:


"More than one - third of EMEA-based executives agreed with that assessment, but are particularly frustrated with changed made mid-stream, so they advocated ignoring changes to business requirements as a means of speeding up project delivery."

Huh??? Ignore changes to business requirements to get the project done on time? Ah yes, this is the focus on that magical iron triangle - scope, time, and cost. Here's the problem with that: you can deliver a project on time, under budget and with the agreed upon scope, and still entirely underwhelm your customer. I humbly suggest that we have been measuring project success using the wrong metrics. Scope, time, and cost are important, but the truly meaningful measure is really value produced by the project. It incorporates the sides of the iron triangle and goes a step further by measuring how the project improved the state of the organization be it through added revenue, reduced costs, or protection of existing revenue.

You see change happens. Business requirements will and should change throughout the course of a project. There are at least a couple of reasons for this.

  • First off, for any project that lasts any considerable amount of time (even as short as three months) it is very possible that business conditions change during the life of the project. If the environment in which the project is happening changes, the characteristics of the project necessary for it to provide value is likely to change as well.
  • Perhaps more frequently the "changes" that people see in requirements is really a result of better understanding of the requirements. This happens frequently when the team suffers from the desire to avoid uncertainty by identifying to the nth degree all requirements at the very beginning of the project. Changes occur because details were established before the team had the appropriate information to properly make those decisions. And often the people making those decisions are not aware of all the relevant details needed to make a decision.
So how do you get around this problem? Don't define requirements in great detail at the beginning of the project. Doing so creates a requirements inventory, and limits the options that are available for design.

And always keep in mind, if deliver something on time that completely misses the mark for what the customer wanted, is it really a success?

Sunday, September 2, 2007

Moving to Knowledge Bridge Musings

All of the blog entries posted before now on Sunday September 2 are actually copied over from my old blog on KentMcDonald.com. I decided to switch over to Blogger.com as my blogging mechanism, but I wanted to save my old entries. As I went through the old entries, I noticed a lot of them were announcing a new presentation. I decided not to replicate those, but I am posting all of my presentations on the Knowledge Bridge Partners Publications page.

Everything after this is new stuff. Enjoy.

A Challenge to some Friends

I recently challenged some friends to identify one book on MP3 to which I should listen. Assuming I can actually find the book in a format that I can use, I commited to listening to the book and letting them know my thoughts.

The results so far (I should note that some had trouble keeping their recommendations to one book):

  • Innovator’s Dilemma (Clayton Christensen)
  • Innovator’s Solution (Clayton Christensen)
  • Dealing With Darwin (Geoffrey Moore )
  • Inside the Tornado (Geoffrey Moore )
  • Living on the Fault Line (Geoffrey Moore )
  • Crossing the Chasm (Geoffrey Moore)
  • The Tipping Point (Malcolm Gladwell)
  • Blink (Malcolm Gladwell)
  • Great Boss Dead Boss (Ray Immelman)
  • Good to Great (Jim Collins)
  • The Seven Day Weekend (Riccardo Semler)
  • Orbiting the Giant Hairball (Gordon MacKenzie)
  • Wikinomics (Don Tapscott and Anthony D. Williams)
  • Freakonomics (Steven D. Levitt and Stephen J. Dubner)
  • The World is Flat (Thomas L. Friedman)
  • Team of Rivals (Doris Kearns Goodwin)
If you would like to add your thoughts, Contact Us.