Skip to Content

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:

  1. Developers don’t just execute on specifications, they can contribute  great ideas…
  2. Having slack time available to capitalize on late breaking ideas is  not a  luxury but a necessity to the Agile team.
  3. 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.
  4. 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

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply