New Year’s Resolution: More Agile Work and Life
It’s been an eventful year, to say the least. I published a book with my two co-authors. I started a blog about it and wrote 43 posts since February. I led IBM’s Smarter Planet search-first content strategy to better success than expected. Based on that success, I focused my job at IBM on one aspect of the ibm.com EIC role–search-first content strategy. And I’ve helped pave the way to implement that strategy company-wide in 2011.
In all the 2010 buzz, perhaps the most life changing event for me was an agile development training I attended at the IBM Learning Center. Agile is the popular name for a way to work that is iterative and incremental. The basic premise is to minimize the head scratching we do as we start trying to solve a problem and just get a working prototype together as fast as possible. Once you do that, there will be plenty of time to refine it iteratively through client feedback.
At first, the training seemed like just another corporate process improvement. I know what you’re thinking: You just can’t get enough training from efficiency experts, right? Even after I went home, I filed the training under Project Management–just one of a dozen or so facets of my work–and, to be honest, the least interesting to me.
On a personal note, I read Moby Dick to my son as part of our nightly story time. Those of you who have read it, however grudgingly in your American Lit classes, might wonder how I could read such a mammoth book to him in one year. In sooth, it was not the only novel we read this past year, but it did take much of the year to read it. The answer is, by committing 30 minutes a night. The book contains 135 chapters, most of which can be read in 30 minutes. So it took us around 150 days to read the densest American novel ever written.
When we finished the book, it struck me that we unwittingly used one of the keys of agile development to read it. Agile was created to address the central problem of software projects: 75 percent of them fail before they are ever done because they are just so large and complex. A variety of factors contribute to this failure: Budgets shift, talent turns over, priorities change. Most projects fail because they lose the backing of their sponsors. Sponsors don’t see enough benefit to them soon enough. So they cut their losses before the projects are ever finished.
Agile addresses this by breaking projects into little bits and showing working prototypes of each of those bits to sponsors. Sponsors (called product owners) can give feedback for each of the bits as they’re finished. When the product owner is happy with all the bits, you can tie them all together into one package, test the whole thing, and release the product. The method keeps the sponsors engaged and energized throughout, preventing its untimely death. There are all kinds of side benefits: Projects can withstand budget challenges, turnover and changing requirements. And the end result also tends to be more modular, which helps make components of a project reusable.
So how do you read the Great American Novel to your child in one year? A little at a time. Each chapter is its own story. We focused every night on that story. By the time we got all 135 chapters done, we could tie them all together into one novel, or epic, if you follow agile nomenclature.
The concept of reading a book as an agile project launched me into a muse about other aspects of my work and life that are, or could become, more agile. This blog, for example, is a kind of agile project. I have written 45,000 words in 1000-word chunks this past year, taking feedback from the product owners (you) as I go. My Facebook page, LinkedIn profile and Twitter feed break my work and life into even smaller bits and garner even more feedback from sponsors.
At one point in this muse, I began to see every activity as agile, such as stringing the lights on the Christmas tree. I found it was best to sort of throw them up there and adjust them later than to carefully place them each in its own spot and hope the string fills all the gaps when I’m done. I have often done it the long slow way and needed to completely redo the whole string after I realized I was only two-thirds of the way up the tree, or I had a bunch of excess lights. This year, I used the agile method and it worked flawlessly.
Before I knew about agile, we wrote a whole chapter (Chapter 9) of the book that uses agile premises as the the basis for web content development. The idea is to get a web page up quickly and iterate on the user feedback it garners, or as Mike Moran says, Do it Wrong Quickly. So the idea was familiar. But I never saw it as the basis for a way of life until recently. When I think of all the times I have failed, more often than not, it was because I became overwhelmed by the enormity of a project and I just gave up. I can only wonder what might have been had I taken a more agile approach to these projects. Or, perhaps better, I can resolve to adopt agile as a guiding principle in future work and life.
I look forward to making good on on this resolution in my 2011 projects. The primary one is building out the search-first content strategy at IBM one program and country at a time. To support that, I will create a bundle of video lectures as a companion to the book, to be released in the first quarter of 2011. I also look forward to speaking at Intelligent Content in February, and serving on a panel at SXSW in March, as well as many other planned activities. Of course, I will develop all of these products in an agile way, quickly getting drafts together, asking for user feedback and iteratively improving them.