First of all my short answer... "AMEN!"

Now for the longer one...

So many of us want to say it, and so many of us think it, and have thought it for a long time...but Mike gets it!

We've all been slaves to 5-year strategy sessions, 1+ year project plans, and a variety of fancy terms for very uncomfortable bracelets and ankle jewelry that keep some IT organizations a mundane, uninventive part of the organization. Everyone is so obsessed with NEVER EVER making a mistake that we plan, plan, and plan some more, until we propel ourselves full-bore into an irrelevant outcome. Plans are followed, to the letter, while the business needs changed during the project lifecycle. Are these projects successful? Absolutely not. But they followed the plan! Sure, bring a basketball to a football game and you'll find yourself irrelevant quickly.

We are obsessed with time and money, and somehow lose track of RELEVANT results. A grand complication watch tells the time as well as a Timex, but neither give you more time to do anything. Quicken doesn't create money, and only tells you where it all went. We are obsessed with time and money because we believe we can control them, and subsequently control outcomes, which is a farce, but we all pat ourselves on the back when we do it "right." Agility gives an initiative an element of relevance, not simply a list of a deliverables, by a certain date, for a certain price. Make it cheaper, it could still be irrelevant. Make it faster, it could still be irrelevant. Spend too much money, it could be irrelevant. Spend way too much time, it could be irrelevant. Make it agile, and check its relevance often enough, your outcome will always be relevant.

In comes agility. Agility is your ability to maneuver quickly when someone yells "Iceberg!" instead of staying the course, because that's what we PLANNED to do when we set sail. I've measured project successes based on our team's ability to deliver to expectations, in terms of *what* and *when* but I also measured it by how many *changes* we were able to implement along the way, to measure our *agility* as a team.

Next comes the feedback loop. I couldn't agree more. Case in point, GM (General Motors). The pinnacle of agility - absolutely not. Did GM really ever ask the customer base what they wanted in any way? Obviously not in an effective manner, as they were pumping out something completely different than what was wanted or needed by the marketplace. This is not a place where you'd want to land yourself, by ignoring the feedback of your customer, or client, both internal and external.

Finally the "think big, start small, and deliver quickly." This is the time to do it, and there NEVER is a better time to be agile than when all the lumbering relics of the Industrial Age are chasing their tail, or worse, preparing some serious 5-year strategic plans to combat their inevitable extinction (at least in their own minds).

I also agree that time to market is absolutely key whether it's a product or service for the public market, or a technology implementation that enables business agility. I would say yes, *efficiently* get a product or service out quickly, and at a low cost, but if anything -- "plan for success." It it so much easier to ask for money and time when you've created demand, versus speculation. Oil companies and the Big Three counted on speculation, and so did a few banks, and I'm only talking a few months ago! I'd love to be a fly on the wall at some of the not-so-celebrity roasts of a few key decision makers, who came up with some hard-core long-term plans, and missed the boat.

During these recent times of uncertainty, isn't interesting to find that China, who lived for centuries by long-term planning, was agile enough to develop a low-cost battery chemistry and electric car technology, while GM lumbered and fell, as well as information technology to manage and track complex financial transactions, such as derivatives, while we still are picking up the pieces from the economic crisis of late. And they have four times the US population, so you can't say that you need to be small to be agile! This is not legend, but truth.

If you are a 5-year-planner type - ask yourself if when you drew up your strategic plans some five years ago, did you include the impact of social networking, socialized healthcare, increased financial market regulation, or perhaps the complete financial meltdown of our world economy?

Don't feel bad if you didn't. But hopefully, you are agile enough to maneuver and adapt, when you heard the resounding cry of "Iceberg!"

Your final question is really the crux of the matter - "Are you up to it?" In business it seems that people rarely want to be involved with your core effort here, which I think could be referred to as - 'Brilliance In Motion' - there is a love for seeing it on the playing field - witnessing it at a bit of a distance - but being engaged in it is judged as to edgy, perhaps to hair-raisingly exhilarating - as in Excellence is Exuberance!

Michael's AMEN says it all, already,
but I want to give you additional thanks to his long reply.

I'll give this to a few of my client's CIOs and CEOs to show them where they're heading when they don't change the way they run their business.

Thanks
Olaf

A few words commenting Michael S. Bogovich’s comment.

Michael, I can’t agree more with you regarding long-term planning in a dynamic world. I spend half of my life in Soviet Union. Tell me about 5-year plan!

However, one thing we need to keep in mind: it’s iron-hard long-term plans that Agile doesn’t value much, but agile values planning highly. In fact, agile planning is much more stringent than traditional one. It requires much higher discipline from everyone involved.

After the big picture is more or less clear as a result of initial light-weight planning, agile planning focuses on a piece of work at hand. We progress the plan as the project progresses. The team is involved into permanent, ongoing planning, but we plan something that we know we can achieve: the next month, the next week, the next day. This is the difference!

Now about time and money. We did not touch on this matter in the post, but I agree with you, we need to talk way more about these infamous “on time and in budget” metrics that are so-o detrimental for the business and serve no-one but been counters.

Which brings me to another point we didn’t touch. Corporate politics. As one of the recent articles mentioned, “traditional” methods are so popular because they are safe for those who can’t deliver. Indeed, “Look at our plans and how we followed them. We applied best practices! The papers we produced prove that we did everything right. The problem might be elsewhere…”

Why people still use useless practices? You think they don’t know better? You think you need to educate them? Relax. They know pretty well that agility brings transparency with it. Transparency, which will expose their uselessness. It will remove their CYA cushion. And you want to convince them? It’s not going to happen. They will do everything to stop you, starting with very popular “We tried baseball, and it didn’t work” approach (http://www.xprogramming.com/xpmag/jatBaseball.htm).

This is, I think, is the biggest road block that Agile – and anyone who wants to bring value – faces these days.

Regards,
Eugene Nizker,
Evident Point Software

Greatly enjoyed the article. The discussion of uncertainty and SD's dissimilarity to construction/manufacturing ties to one of my favorite books, The Laws of Software Development. Good points, well-written -- I have bookmarked and will re-read later, and share with others.

Having said that -- there are some points that I think need to be called out. I don't think that you necessarily mean to imply the following, but for what it's worth, I want to list them for the benefit of myself and others reading.

Nothing Fixed in Stone: the article casts a certain post-modern ambiance that says that everything is uncertain, even Agile itself. I think this is absolutely correct in terms of business needs and functionality. There are things, though, that ARE fixed in stone in any software development effort. To use old-fashioned requirements language, these are specifically business rules and constraints. If we have a rule that sales tax is 5%, and the system charges 6% and on the wrong items, it fails. If the system uses too much network bandwidth, it fails. And etc and etc.

As I said, I'm sure you are nodding your head in frustration and muttering, "But of course." The problem is that in our rush to be Agile, we may also be stupid, and without SOMETHING to help us not be stupid, such things may happen. And they can't always be specified by the Product Owner, or seen in the demo.

Some early Agile writings talked about "less programmers, but more experienced." I wonder if part of the reason for that was to be sure the team doesn't do anything stupid, based on the innate knowledge of the senior members of the team.

No Best Practices: You note that "best practices for a fee" is a common selling point from high-end consulting companies, and that the idea that what worked for Company A will automatically improve Company B is just silly. And of course, you're right.

What you don't call out specifically is that there ARE best practices in certain areas, mainly technology, and we ignore them at our peril. People are incredibly agile, projects need to be agile, businesses need to be agile ... but computers are almost 100% non-agile. We can't apply theories about methodology to these bits of silicon with fixed instructions in the CPU.

Examples -- coding queries a certain way to minimize network traffic and database churn. There are best practices for these, and they are best practices in almost every instance. They should be taught, and followed -- and if there are exceptions those should be taught too.

Again, I wonder about the role of senior programmers in this. There is a reason that peer code review is one of the most quality-increasing things you can do in a software organization.

::

Okay, those are my two big points. I'm sure you've thought of both of them, and if you'd had more space you would have made them yourselves. I just wanted to throw them on the table for discussion.

Thanks for reading.