Life is good when a video combines an “avant-garde” cellist, references to metadata and information architecture, and an allusion to the iterative nature of technology (around 7:30 of the video).
I haven’t yet done a good job of describing the fail fast model with my thoughts on agile software development in this blog. Blogs feel more like streams-of-consciousness than articulated, structured documents. While I get my arms around how best to tell the fail fast story as I have experienced it through time, I thought it would be helpful to provide a bit more background on the topic by posting a copy of my Agile 2008 whitepaper, “The Big Projects Always Fail: Taking an Enterprise Agile.” You can now read it here; I would love to hear your thoughts and comments.
This morning, on the cold and wet streets of metro Detroit, I had the good fortune to attend an interesting mini-seminar on cloud computing. The hosts, Perficient, assembled some of their own folks as speakers and also invited two core cloud vendors, Salesforce.com and Google, to speak as well. I had a few observations.
First off, those of us who are traditional IT folks are going to be in for a lot of change in the next few years. Gmail and Google Docs will probably be used by nearly everyone instead of the “standard” Microsoft tools. They provide the core functionality you need as a user, they are available wherever you are on whatever computer you happen to be on (bring out the netbooks), and you can use them offline via Google Gears or even from your BlackBerry. If you decide you need these core apps in a corporate / enterprise environment, you can pay a mere $50 / year / user. What do you get? Freedom from MS licenses, hardware hassle, disaster recovery (mostly), and ediscovery (Gmail provides 25GB of storage for each user and archives for 10 years). These consumer tools are ready for the enterprise, and even the US’s new CIO thinks so.
Secondly, Salesforce.com is doing a really nice job with the force.com platform. Where I work, we adopted open-source and agile software development methodologies for our custom software efforts about three years ago. We also decided to pilot Salesforce.com for a big group of sales folks (about 250) who did not have a CRM solution of any kind at the time because we believe it provides world-class functionality that we could not easily or quickly build ourselves.
I also persuaded myself to embrace Salesforce.com in part because I believed that its speed-to-market capabilities would actually support our agile development process at least as well, if not better, than our standard J2EE technologies and tools (Apache, JBoss, JSF, Hibernate, Eclipse, SVN, Oracle). This has turned out to be the case in spades. Want to be agile? How about starting from ground zero and delivering your app to production at the end of your first one-week iteration? Force.com significantly reduces the infrastructure overhead of source-code control, development environments, Cruise Control scripts, etc., etc. Don’t get me wrong — I love that stuff and I and my teams know how to do it well. But, in the same way you can change your own oil but it is pretty cheap and convenient to have Uncle Ed do it for you, you can deploy much more quickly using a cloud platform — and still have a lot of fun in the process.
Kudos to the Perficient team for pointing out this agile relationship (though I have to say they didn’t hit it home strongly enough). And the Google and Salesforce.com teams also didn’t point out one important detail: if you are a Salesforce.com user, you get integrated Google Apps for free. Hello. And the Google folks didn’t do a very good job of demoing their own (powerful) tools. But through the presentations, you could see that the core content was enabling what I thought of as “the agile cloud.”
I guess it has been eight years since the Agile Manifesto was originally published. It certainly doesn’t seem that long ago, but, then again, even that recently, agile was still considered relatively avant garde. It was something that you would likely have to convince your teams and customers of rather than one of the mature methological choices available for software development. Thanks to a recent Chet Hendrickson post to the Michigan Agile Enthusiasts group, I just learned of a newer software craftsmanship manifesto. Check it out.