Thursday, June 05, 2008

How Does Choice of Methodology Influence Strategy and Tactics?

Once More Unto the Breach, Dear Friends
As Helmuth von Moltke (the Elder) said, “No battle plan survives contact with the enemy.” In the case of software development, the “enemy” is reality. What we think we need to do to satisfy customers and how we think we need to implement it generally changes as we implement and as we get customer feedback.

Similarly, Dwight D. Eisenhower said, “In preparing for battle I have always found that plans are useless, but planning is indispensable”. Planning (short and long, tactical and strategic) is still important in the Agile world. The difference is that Agile is specifically designed to take advantage of the fact that planning, design, and development have a learning component and to accommodate and embrace the resulting need to change plans on a regular basis. As you discover new information during an iteration, you can easily adjust your plans to take what you have learned into account in future iterations.

Too Busy to Plan
Short iterations and other Agile practices such as “You Aren’t Going to Need It” (YAGNI), may seem to indicate that Agile is tactical in nature. However, I would say that it is when looked at through a Waterfall lens. For instance, with Waterfall the planning horizon and iteration length (the full start to finish time) are the same. So if you look at Agile with this perspective you might think that the longest that Agile folks look ahead is 30 days. You might then conclude from this that Agile can only be used tactically. But in fact there is no connection between the planning horizon and the iteration length.

Many teams use very short iterations; two weeks or one week. What happens within an iteration is whatever has been planned for that iteration. Different Agile methodologies use different approaches for planning iterations. In any case, you can plan as far out as you would like. As an Agile product owner I can tell you that some of my products have plans going out multiple years.

Sometimes there is work that can’t be fit into a single iteration (whatever iteration length you have chosen). In that case, you can use multiple overlapping iterations. For instance, a one-week iteration for most stuff and an overlapping one month iteration for the exceptions. Over time though, teams generally get better at avoiding the need for exceptions.

Wherever You Go, There You Are

In my experience, whether the software development of a company is done tactically or strategically is connected to the planning culture of an organization, not the methodology. If an organization thinks and plans strategically, that will be reflected in their software development whether they are using Agile or Waterfall.

I’ve seen plenty of companies that use Waterfall but think tactically, packing mostly tactical features into a large release. Feature creep is a good example of how tactical thinking is fairly common in Waterfall projects. While of course it is true that “that shouldn’t happen” the facts on the ground are that it does.

I’ve also seen plenty of Agile projects that were strategic in nature. For instance, an Agile company that thinks strategically will have a strategic plan which they carry out using multiple iterations. As they discover that they need to do something tactical in the middle of their strategy, or they need to change their tactics in support of their strategy, it is simple to do with short iterations. They just change their plans for future iterations. As soon as their current iteration is done, they begin the next iteration which has now changed to take into account the new information.

It may well be that folks that think and plan strategically are less inclined to look deeply at Agile because it appears on the surface to be tactical in nature. I know that was true in my own case. I believe that people and organizations that think strategically will bring that thinking with them into the Agile world. Having crossed over I can report that I have been able to very happily and successfully bring strategic thinking with me to the other side.

Read more about Agile in "Zero to Agile in 90 Days or Less" .

[Note: this post was inspired by Jordan Bortz’ post, Agile and Waterfall are Two Sides of the Same Coin where he states that ‘ “Waterfall” is basically a Strategic method of attaining goals, and “Agile” is basically a Tactical method for achieving goals.’ ]

4 comments:

Anonymous said...

Well your post keeps getting refactored :)

Well to the extent that you believe you should bring strategic planning along with your tactical implementations, you should be agreeing with my post, where I posit that such an approach (a combo) would prove best.

This is in line with the agilemodeling.com (Scott Ambler) approach.

However the Ambler approach is often panned in orthodox agile circles.

Cheers,
Jordan

Damon Poole said...

Hi Jordan,

Yes, I do refactor my posts on a regular basis. I only wish that it was possible to turn on versioning so that folks could see old versions if they wanted to.

I do agree that you should bring your planning culture with you to Agile. I think we probably agree on more points than we disagree. Notice that the post now says "inspired by" rather than "disagree with."

I'm not into Agile as a movement, religion or philosophy. My interest is "how to bring Agile to the mainstream in a practical manner" and for that to happen, it will take lots of work, including the end of "orthodoxy."

Cheers,

Damon

Anonymous said...

Heh well good luck on the end of "orthodoxy" notion :)

The best way to get past the orthodoxy IMHO is to jettison the neologisms like "Agile".

It's just Tactics... To the extent that Agile is advocating a Tactical bent, why not get rid of the name "Agile" altogether along with the dogma?

Then we can get past the rhetoric and focus on the 5,000 year old history of the notion....

That was the genesis of my post :)

Cheers!
Jordan

Damon Poole said...

Hi Jordan,

I think we'll have to agree to disagree.

As I mentioned before, it took many months of actively constructing the counter-argument as an anti-Agilist before one day I said "oh!"

There are really only three possibilities:

a) I have an ulterior motive for believing in Agile. Many Agilists are accused of this. But really, aren't we all looking to prosper by doing what we are good at and believe in?

b) I need to have my head examined. This is a common feeling amongst my friends, but they put up with me because I have Lego Star Wars on the Wii.

c) There might be something there that is not readily apparent, even to bright open-minded people, caused in part by the dogma, zealotry, arrogance and "Agile is perfect" attitude of some of the advocates.

Cheers!

Damon