The Codist

Today there are many (too many) software development methodologies that all claim to provide a path to better software development. Many of them can trace themselves back to the original 2001 Agile Manifesto but there are examples that date back at least a decade before then.

The problem with all of these is that often they start off with some good ideas and then become rigid and formalized and complicated and often become not much better than whatever people were using before them. When I start seeing companies spring up to "help" you understand how to do them better or provide tools (usually expensive) to make them easier I start tuning out. It's such a growth industry you can't throw a rock without hitting someone who is more than willing to take your money and tell you how to write better software. Most of them probably know less about writing real software than your grandmother. I can remember enough presentations from companies who promised Nirvana where I wanted to run away and join a circus; most of the time they vanish into oblivion when they run out of suckers to sell to.

When I think of agile I think of a mountain goat. Amazing animals that never seem to lose their balance, bounce from rock to rock, and hardly notice whatever apparent peril they might appear to be in. I never think of a hippo on land who though they can run fast aren't very nimble at all and can't turn or run very far. Can you turn a hippo into a mountain goat? No, but feed a goat enough and they can bloat until they resemble the hippo (with tragic consequences on a mountainside).

agile (little a) means the ability to work quickly, adapt easily, deliver what is needed when it is needed and repeat as needed. But no matter what methodology you subscribe to or how much you want it not every project or organization can ever really be agile. Virtually all of the named methodologies promise that you can make anything agile if you just do this or follow that but I am convinced after 3 decades of doing this that sometimes it's just not possible.

The larger company I work for does try to follow a formal Agile process but it really doesn't succeed and I don't think it ever will. Our industry is too complicated, our core technology is too ancient yet too irreplaceable to ever be anything other than a hippo in sneakers. Many companies with long histories in industries such as banking, insurance and healthcare have so much invested in heavy old technology and software that no amount of modern methodology will ever make more than a modicum of improvement. But it doesn't keep people from spending money on those who would convince them otherwise.

Of course just because a large organization can't improve their hippo-ness doesn't mean that smaller groups inside can't rev up some nimble goat-ness. The small team I work with has lots of overlapping products and services which we deliver continuously and rapidly shift as the market changes directions. I would say we don't really do any formal anything process but remain very goatlike in how we manage things. Our group operates somewhat independently of the larger organization and we've learned over time how to take advantage of that independence to continuously increase our share of the company's business. I like to think most companies realize the advantage of finding ways to better their success by giving small in-house groups more ability to operate on their own. Think of it as instead of trying only to shrink the hippo, make yourself more nimble by breeding more goats.

From another industry I remember how GM tried to improve its business by creating the Saturn brand and company and letting it operate independently. For a while it worked great until too many in the parent company grew jealous and forced it to fail. Unfortunately a nimble goat can make a fat hippo look bad.

I look back on the opportunities I have had to participate, develop and deliver products and every single success came without any named formal software process at all. Virtually all of them were iterative in nature, continuously adaptive to change, built in small teams, with constant access to the customer or market representative and always featuring a great team willing to try something different. All the projects that were dismal failures or were cancelled had virtually none of those things. Not one of those successful projects involved paying anyone to tell us how to succeed even when we had never done anything like it before. Sometimes I think people who lead projects (or more likely those higher up the food chain) are so under-confident that only by paying huge money to some external entity or subscribing to some heavy formal process will guarantee success.

The old waterfall process (which seems to have been described originally as what not to do) still exists today because it gives upper management the illusion of control. I think the "Agile" type processes can do the same if applied to a hippo organization as a rigid system; you can say you are Agile and assume that things will go much smoother in the future, and if things don't seem to get better you can blame it on not being Agile enough.

But agility can never be formal, can never be rigid, can never be a detailed set of steps or processes or a magic formula. You can't create a goat by making a hippo take ballet. Being agile is always a loose process and only works in small teams so all you can do is find ways to split off bits and pieces from your hippo butt. Once you have a small team it's not what the process is called but finding flexible people willing to organize themselves into a process that succeeds. To paraphrase a great movie line "agile is what does agile".

So try to be a goat, realize the limitations of trying to create a svelte hippo with a cooly-named process, and always remember that the best agile should be spelled with a small 'a'.