Monday, January 16, 2012

Crystal Base Jumping

I've just returned from the Blue Skies Boogie, an annual skydiving event that happens every January in Mesquite, NV. For the non-skydivers out there, think of a "boogie" in the same terms as a really cool software conference, with gravity as the keynote speaker.

As is my wont, I spent some time pondering the metaphoric similarities between my chosen passions - in this case software development and skydiving. it reminded me of a topic I had intended on writing on a couple of years ago but never got around to doing until now.

Several months ago I picked up a book on BASE Jumping - the extreme sport of jumping off of anything that isn't actually flying around in the air and living to tell the tale. Since I'm already an avid skydiver, BASE jumping seemed a pretty natural next step in my nonstop quest to torture my poor worried mother half to death (at least that's how she puts it).

BASE (Building, Antenna, Span, Earth) jumping is to skydiving as skydiving is to climbing down a ladder. Sure, both will do the job of getting you down to the ground, but there's a world of difference in the ride.

A skydive is driven by a simple metric, altitude. At specific altitudes there are actions that must be taken in order to you to survive a skydive, let alone land unharmed. The penalty for failing to perform these actions quickly and decisively is as steep as it gets.

BASE jumping is no different in that it is ruled by the same altitude metric. It also requires actions that must be taken in order to survive. What makes the critical difference between the two is the time scale in which these actions must be performed. 

On a typical skydive you may have up to a minute of freefall time before you reach the altitude where you must deploy your parachute. For a BASE jump, 7 or 8 seconds is about the maximum amount of time you get. Not a whole lot of room for dilly-dallying, if you know what I mean.

I know, I know. I promised that this post would have something to do with software development. I promise we're getting there.

A few years ago a company I was working for was entertaining the leadership of an important medical society. We had previously been discussing the possibility of licensing of some of our medical content to them for an educational application under development for them by a third party. We were all under the impression that the purpose of the meeting was to close a content licensing deal, and were quite surprised to hear the representative from this society apologize to us because even after a year of development their educational application was not going to be delivered in time, thus eliminating the need for our content.

During a break in the conversation one of my peers said "What if we went ahead and built it for them? We seem to be pretty good at this web application stuff, right?". It was one of those perfect questions - the kind when you can just feel the world around you come into focus a little brighter and sharper than it was before.

The only catch was that the application had to be ready in time for a July launch, which at the time of this meeting was less than 3 months away. Now before you start thinking to yourself "This guy is a real glutton for punishment!", may I remind you to take a moment to review the name of this blog? Are you really shocked to hear that I've pointed said Agile Sadism at myself from time to time?

Anyway, it took us a little over a month to work out the contractual details of the project, leaving us with a grand total of 7 weeks left to build and deliver a working application.

OK, this is the clever bit where I tie our analogy into the story. Recall the relative metrics for skydives versus BASE jumps? If the previous team "cratered" their project after a year, how could we possibly think that we could nail our BASE jump after only 7 weeks?

Editor's note: The term "cratered" is a skydiving term used to indicate a landing where the skydiver failed to deploy a parachute. The management of this blog does not endorse this as an effective method of completing a skydive, even if you like to make a big entrance.

Successfully transitioning a methodology from a more "normal" delivery period isn't any more of an accident than successfully transitioning from skydiving to BASE jumping. Fortunately for us, Alistair Cockburn's Crystal provided a meticulously detailed plan for our Crystal Base Jump. Although we may be straining the limits of what text can be posted in a single blog entry, I think it is important enough to post it here in it's entirety for the sake of others facing similar extreme projects. 

Here it is:

Put smart, experienced people in a room and get out of their way.

That's it.

Actually, that's not it. Our success was predicated by the choice of the people that were in the room. Although my claim to intelligence and expertise is questionable, my primary teammate [Nate Jones] certainly knew what he was doing.

What was most interesting wasn't how we were working, it was the rate at which we'd adapt how we were working. Our "methodology" could literally change within the space of a few hours depending on the current circumstances of the project. It is my belief that what really made the difference for us beyond our ability to deliver software is that we shared a common domain language for our methodology, allowing us to shift process with minimal signaling - usually just naming a technique would do the trick.

I know, you read all the way down here, thinking that there'd be all sorts of information on how to do your own "Crystal Base Jump" imparted. I don't want to leave you completely empty handed, so I'll close with a quick discussion of some of the key techniques we used to help achieve success. 

Customer Negation - We all have deep familiarity with the term "The customer is always right". Well, this isn't the case in a Crystal Base Jump. It's not that they are wrong, it was simply because we couldn't afford to commit any time to cycling on customer feedback. At the outset of the effort we identified their "without which, not" features that had to be delivered, and spent some time understanding the amount of play we had with the implementation of those features. Once we had clarity on these features we literally went dark on the customer for the remainder of the development period. The next time they saw anything related to the application was a day or two before we went live with the application. This practice of "customer negation" was actually spelled out in the legal contract

Trim the Tail - I first heard about this technique from Jeff Patton, who I am sure will correct me if I am improperly identifying him as the originator of the technique. Traditionally coders have a tendency to consider a given feature or set of features as an "all or none" proposition - either they are delivered at a specific level of fidelity or they aren't considered "done". 

In Trim the Tail you look at feature implementation as more of a staged effort. Initial delivery of the feature would be at the ["Yugo"] level: it gets the job done, but ain't pretty. Subsequent work in the same feature area would enhance the feature(s) to the intended level of completion. In the case of our Crystal Base Jump project, not only did we have a number of user-centric features delivered in a minimal state, some elements of our technology stack were also Yugos at delivery time.

Walking Skeleton - If Trim the Tail is a tactical tool, Walking Skeleton is the strategic. Also learned from Jeff Patton, this practice focuses on the implementation of a minimalist set of working features across the breadth (all major functional areas of the application) and depth (all layers of the technology stack). 

Use of the Walking Skeleton technique gives you early visibility into the complexity of implementing the full feature set as well as early experience in how stable the technology stack is for the application. Walking Skeleton is a great insurance policy against schedule devouring features and late discovery of technology stack instability.

Customer Proxying - Customer Proxying comes into play in situations where for whatever reason the team does not have easy or frequent access to actual customers. In our case the lack of customer access was quite intentional, but it didn't mean that we didn't care about what was important to them. 

In our case team members had considerable experience with thinking in terms of customer Personas and were able to channel these personas as needed during the development process.

Incremental UI - Although this technique is in theory a natural extension of Trim the Tail / Walking Skeleton, it does bear mentioning because of the specific positive impact it had on our project. Introduced by Nate Jones, this technique is the most elegant incremental delivery of UI fidelity I've ever seen. 

It goes something like this.

1. Paper prototyping to confirm basic user story fulfillment
2. Clickable prototypes to confirm navigation and user story details
3. Incremental integration of application stack against clickable prototypes with low fidelity UI formatting
4. Pretty pixel UI formatting and UI finalization

The advantage of the technique was that from the very start we had a consistent walkthrough across the user interface that was the basis for easily demonstrating application development progress. This incremental delivery kept the UI and application stack development highly cohesive while allowing each to proceed more or less independently of each other.

To be sure, there were other techniques and tools we used in the course of our Crystal Base Jump, but these were the ones that stood out the most during the heat of battle. 

Final thoughts on Crystal Base Jumping. Don't do it. Seriously. Much like the real thing, you'll fail unless you have the right experience, skills, and team. Unlike the real thing, the price you'll pay for failure isn't death, but a failed project after such a Herculean effort is going to hurt. A lot.

Monday, January 2, 2012

Fixing New Years Resolutions with Agile

December 31st, 2011. 11:25PM MST: 

For what seemed to be the 17 millionth time I was asked about my New Year's resolutions for 2012. Before I could summon up the energy for yet another foaming-at-the-mouth diatribe against the futility of this custom I realized that my mouth-foaming was sounding suspiciously familiar.

It's an exceedingly rare occurrence when you actually listen to your own rant. Was it the champagne that had elevated my consciousness to this rarified state? Or perhaps it was the euphoria of observing all of the lovely ladies in attendance at this party that had perfected the art and science of the "little black dress"? Whatever it was, it was working.

Here's what I heard when I actually started paying attention to my little rant:

A) New Years resolutions almost always fail
B) Why only make these life-altering changes once a year?
C) Even if you do make progress towards a resolution it is considered a failure if total success isn't achieved.
D) Resolutions are a conspiracy perpetrated by the fitness and weight loss military-industrial complex, which channels the funds gained from the brainwashed "Resolutionist" masses into advertising for fast food and big screen TV's, which in turn subvert yet more of the masses into their nefarious vicious consumerism cycle.

OK. I made that last one up. I really have to find a way to turn the channel when one of the cable stations plays a "Conspiracy Theory" movie marathon late at night

Anyway, if you look at the first three points, they seem awfully familiar to anyone that has been on big software projects, don't they? Let's take a closer look:

1) New Year's resolutions almost always fail = Big (as in budget and/or time to delivery) software projects almost always fail
2) Why only make these life-altering changes once a year = Why limit releases to once a year or so?
3) Progress towards a resolution is forgotten if the full resolution isn't achieved = New features/improvements implemented early sit unused until the whole release is delivered

The epiphany for me isn't some new insight into the software business (I'm sure some of the repeat visitors here would be shocked if I ever come up with some new insight into the software business).

No, the epiphany is in how we deal with our New Year's resolutions. Forget this dysfunctional "all or nothing" tradition we keep torturing ourselves with. Let's take a hint from the software business and do our New Years resolutions the Agile way.

Since we're talking about a team size of one, we can really strip Agile down to bare metal:

1) Iterate/deliver frequently
2) Reflect and adjust

Let's test this out. Say that under the old repressive regime of "Yearly Resolutions" I'd set a big goal for myself - such as learning how to become an Ultimate Pickup Artist (UPA).   Although there is a strong romantic appeal to throwing myself into such a noble goal with abandon, what I'm really interested in is results. After all, what if I'm really not cut out to be an ultra-babe magnet?

With an Agile approach to my New Year's resolution of becoming an UPA, I now have an extensive toolbox of techniques and practices to bring to bear. One of the first I'd reach for is a little gem called "fail fast". 

In this case, fail fast means two things. First, can I bear uttering inane pickup lines with a straight and sincere facial expression? Second, do I have what it takes to endure the wrath of women offended by lewd suggestions in pursuit of the small percentage that are either over-medicated or have otherwise taken leave of their senses to the point where they'd be smitten with a tawdry pickup line?

Right there is more than enough work for a first iteration. Assuming monthly iterations, the theme for January would be to "fail fast" and my work product would be to practice my pickup line delivery and insensitivity to criticism and/or physical assault. Heck, with a bit of careful planning I may even be able to work towards both goals at the same time.

By the end of January I'd have ample data to reflect on whether I'm socially and morally corrupt enough to be a truly stellar UPA. 

If it seems I have what it takes, I'd be ready to take my next incremental steps in February towards my goal.

 If not, I'll take comfort in the fact that I didn't waste a lot of time and energy in finding out that contrary to appearances, I do have some vestige of a conscience lurking somewhere and can instead focus on pursuing a more appropriate personal resolution, such as honing my gender sensitivity skills.

In conclusion, although you may not agree with my choice of resolutions, you can't argue with success. If you really want to make those New Year's resolutions permanent, you gotta go Agile!

Editor's note: No actual females were harmed during the manufacturing of this blog entry. Our brave volunteer test reader (Ghennipher Weeks) did suffer some emotional trauma in the line of duty, but with just a few short months of intensive therapy, she should be just fine.