Sitting in the airport today, I’m frustrated. Not by another delayed flight, or lack of an outlet to charge my laptop. No, today I am frustrated by the application I’m using to write my blog entry. It probably doesn’t matter; there are a dozen other applications available, just a few clicks away. Surely that will alleviate my frustration. So I hit the app store and browse the commodity choices for blog writers. I check the user comments and revision history for the various apps. I almost never download an application that doesn’t show frequent updates, no matter how many downloads they’ve had. I’m looking for a vibrant tool, one that maybe doesn’t have all the bells and whistles, but is constantly being updated, changing…one that is alive!!
It just so happens that the application I’m already using is actually one that has frequent updates. I decide it’s ok to wait a couple of months for the next release. Why not? The roadmap looks promising. I sent the developer a quick note letting him know of my frustration with the current version and the features that would really make me happy.
It occurs to me that I personify a user and company that I typically deal with as a consultant. I want it all, I want it fast, and what I want will all change tomorrow.
Adapt or Die
The methodology by which we achieve this sort of agility already exists: we see it every day with the products we know and love – iPhones, iPads, automobiles, the application marketplace for Android, your laptop computer. You name it, it’s all around us. A growing number of companies embrace the methodology; in fact, according to a recent Forrester report, agile methodologies are now considered mainstream.
Where agility runs into trouble is in trying to balance the rapid changing demands of customers with operational stability. Agile projects rapid implementations may result in rapid change across a broad spectrum of users, some of whom are far away from that change and the factors driving those decisions. Increasing the number of system or process changes over a short timeframe taxes both operations teams, and an organizations overall ability to absorb change. Both factors need consideration in planning and implementing systems.
But, at some level, those factors only matter when the mechanism by which the decisions are being made are based on irrelevant, stale information, or information that isn’t acted on in a timely manner. Simply stated, if you’re releasing features users want in a timely fashion, change management issues are relegated to an effective communication channel. Those channels must be alive and vibrant; otherwise the rapid change will result in a clueless audience. If you’re delivering what users want, what they’re clamoring for, they might even demand access to the newest features. Now that is when you require a solid change management strategy.
What’s a Heartbeat?
When your community understands that a system will have rapid, predictable releases, a heartbeat, if you will, people come to expect and accept that another heartbeat is coming, and predictably so. With a change management strategy, communicating visibility into the features planned for upcoming releases, the entire lifecycle is alive and the feedback loop is working.
For anyone who would deny the simplicity of the approach or why it works, consider my 6 year old daughter. She loves to perform, and enjoys plays, dances, musicals and being a Master of Ceremony. But, if I ask her to put on a show with 5 acts, make each act different, include interaction with her audience, give her a set of rules about which words to use, what to do with her hands and critique her content endlessly, it’s a recipe for failure. However, if I simply ask her to choreograph a dance, it’s done. If I ask her to write an invitation, she’ll produce a masterpiece. She can handle any part of the 5 act epic, but overload her all at once; the assignment’s no longer clear: progress and quality suffer. The former exemplifies the concept of agility.
Living in Harmony
In mission critical systems at large, within slow-to-change companies, the catch-22 is the age-old dilemma of documenting what to do for a year or more, defending it through change management and communications, then looking back on the reasons the system failed. Too often, we look to find a change management strategy to correct those issues. But, if your business is expecting unpredictable change during your project timeframe, your problem may be much simpler. There’s a reason Six Sigma projects are 3-6 months in duration and not longer. Think about your company and imagine a series of 2-3 month deliverables that evolve the system, processes and improve operations efficiency to a higher level of excellence. Now you’re thinking Agile.
What do you know? The developer wrote me back already! My feature request was heard and will be in the next release! Now that is agility and managing change in harmony!