In 1964, Supreme Court Justice Potter Stewart, issued the following opinion in Jacobellis v. Ohio, one of the early challenges of pornography to the First Amendment of the Constitution:
"I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that."
The 7,800,000 Google search results for "What is Agile?" not withstanding, based on my many conversations with Agile teams and their coaches and consultants, I believe that Justice Stewart's sentiment is as applicable to Agile as it is to pornography. You can try as hard as you'd like to define or test for Agile, until you see it, you can never truly know it.
In order to help us see Agile, I would like to introduce the concept of an Agile Moment, and with today's post, to begin sharing some of b2b2dot0's.
An Agile Moment is an observable event that delivers on the promise of Agile and can recount how it was directly informed by Agile techniques, tools and philosophies. Agile Moments are stories that simultaneously celebrate and educate. They celebrate the accomplishments of people and underscore the critical Agile related success factors that enabled them. Agile Moments educate by providing teachable moments.
Here is my most recent Agile Moment. I call it our "SAP Outage Response" and it will now become the archetype for the value of combining passion and initiative with "slack time" at b2b2dot0.
A few weeks ago, while only days away from finalizing our Q2 Release, our development team had a product idea that they wanted to fast track into the Release.
They wanted to automate the procedure by which we put up, and take down, our "Web-shop is Temporarily Closed" signage. In particular, to support those situations when our client's SAP system is unavailable to us...(as rare as that might be :-), it does happen.)
While we've always had the capability to monitor the availability of our client's SAP system, when SAP was brought down (either voluntarily or involuntarily), the process of responding to that outage and putting up the "Web-shop is Temporarily Closed" signage was a manual one. Consequently, it could take quite awhile before we verified the outage with our client and put the appropriate action plan into place. This lag time came at the expense of our client's customers who were allowed to continue to attempt to access the Web-shop...but were guaranteed to fail. The "Web-shop is Temporarily Closed" sign is a much friendlier way to handle the situation.
The most unusual thing about this request was that at this point in a release cycle, we're normally "ruthlessly" prioritizing features OUT of the release and here they were passionately arguing to put a brand new one in.
I have always found that it is easier to harness passion than it is to instill it.
As long as we could align the feature with customer value, guarantee that we could test it sufficiently and that it wouldn't come at the expense of any other promised feature, wouldn't that be the Agile Way? So off they went and designed, developed and tested a capability that would never allow SAP to be down for more than three minutes before we closed our client's Web-shop (and notified all appropriate parties) and never allow their Web-shop to remain closed more than three minutes after SAP came back online.
This was a win-win-win Agile Moment for b2b2dot0, our clients and their customers.
- b2b2dot0 refactored internal procedures to free up our precious resources from manually babysitting computers and improved on the delivery of our SLA's.
- Our clients can stay focused on managing their SAP system and we don't have to interrupt them when they are troubleshooting availability issues
- The amount of time their customers can't access their Web-shop when SAP is down is minimized and the message telling them that they can't is friendlier
How was this Agile Moment a teachable moment? I can think of several Agile takeaways:- Developers don't just execute on specifications, they can contribute great ideas...
- Having slack time available to capitalize on late breaking ideas is not a luxury but a necessity to the Agile team.
- Agility isn't always about delivering what the customer asks for. It can be about delivering what they need and don't know they can ask for.
- Dedicated and motivated teams, incremental development, automated regression testing, and certainly the Ruby on Rails environment, all contribute to rapid execution.
Delivering real value in real time to real customers. That is Agility that you can see.
Sam
