Be Agile

This post is part of a series based on a presentation I did to the London VMware User Group on February 25th, 2010 about the reality of Enterprise scale internal cloud platforms. To find other posts in the series, just look for the tag “Bringing the Cloud Down to Earth”.

Agility is another buzzword that goes hand in hand with Cloud, but what I’m referring to here is more aligned with Agile as a philosophy or methodology rather than the conventional interpretation (although of the course the 2 are closely linked). Agile is most often used for software projects, so you may initially think it’s a bit strange to use for something that is as much infrastructure as it is software but trust me, it works exceptionally well.

Developing the Unknown
And that’s the reason why. Cloud is such a shift from what the Enterprise is used to, you need to accept that you really have no idea what to deliver or how people will use what you deliver. Given that, the typical approach from Enterprise IT would be to spend 9 months of planning in complete isolation, and deliver something that is overcomplicated, has everything and the kitchen sink, and bloody expensive. And not what the customer wanted.

I’m by no means an Agile Ninja, but the philosophy of Agile is very close to my personal philosophy which is something of a bastardised mix of Taoism and Buddhism… which I guess is basically what Zen is. It’s about going with the flow, not trying to anticipate everything in advance and being flexible enough to deal with whatever comes your way. Mind like water.

OK, so Agile is a little more concrete than that, but not much. In a nutshell, rather than trying to anticipate every single thing that your users will want, or even taking every single piece of input from potential users and building it, you start with a simple piece of functionality, and add to it when you need to – not before. Developing the unknown is not about developing blind, without user requirements or input. It’s about questioning whether people actually know what they want. Yes i know that sounds like your typical “we know better than the users”, but it’s not like that. People will generally base requirements on their experience. But you are about to change that experience radically, and they don’t know it yet. It’s like Henry Ford said: “If I had asked people what they wanted, they would have said faster horses.”

Let me illustrate what I mean with an example. Think about your environment today, and the requirement for server rebuilds. The ability for an application owner to request a fresh OS install on their existing hardware is pretty much a given. And so when you canvas your Cloud customers to determine what features they would like, “Rebuild OS” invariably comes up. Since you’re operating under the mantra of automate everything, you spend a massive effort to deliver a one click rebuild capability. You build a UI with all these options allowing for users to choose what volumes / data they want to retain, whether they want to re-use the hostname, IP address etc, and then build a whole bunch of back end workflow to automate the whole damn lot. Sure it was a costly exercise, but you did it. Well done.

But why is it necessary to rebuild something today? Because it takes 2-4 months to get a new piece of hardware into an Enterprise datacenter perhaps? At significant cost? And whats the basic premise of the Cloud? Rapid provisioning, lean governance, pay for what you use. If the application owner can get a brand new inexpensive box in a short amount of time, copy over or restore whatever data they need into that, then just switch the old one off… is that going to be good enough for them? Do you really need rebuilds? So what about all that time, effort and money that went into your one click rebuild. Totally wasted.

To some extent this highlights the importance of analysis, but it also highlights one of the earlier principles of starting simple. You really have no idea how people are going to use this thing, so start with a minimum of functionality and add to it based on how you see it actually being used.

Release Early / Release Often
Naturally you cannot develop something in a Agile manner if you can’t rapidly introduce new features. This has zero to do with rushing stuff in, and everything to do with having test driven development and a solid QA process, which is exactly what Agile requires.

This again is something not often seen in the Enterprise – all too often a huge monolithic system goes in, it’s not what the users wanted, then it takes 6 months for even the tiniest change to be implemented. So right from the word go, you need ensure that you will not be stung by this if you are using existing tools. If there’s no way around it, then go and buy new tools that you can control. I’m serious. And again, this is something that is critically important to communicate to the users as well. When you drop your first live code, which is a nice, simple set of basic functionality, you will probably get a lot of “is that it?”. They will be used to the existing sluggish change management processes, and expect that what you just released will never change or at best change with iceberg-like speed. No – that is not how what you release is going to be. Ensure from day one that you can effect rapid, well tested change on every component of your stack. Otherwise don’t even start.



One Response to “Be Agile”

  1. Top 5 Planet V12n blog posts week 15 | VMvisor Says:

    […] Radnidge – Be AgileAgility is another buzzword that goes hand in hand with Cloud, but what I’m referring to here is […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: