Over the course of the last six months, time permitting, Hashrocket has been working on a product initiative codenamed "Launch Pad". Hashrocket does a lot of Web 2.0 apps, and most of them have a similar assortment of basic functionality and social networking features: user accounts, event notification, photo uploading, commenting, etc. Naturally, there is a desire to take our sum knowledge of building these types of features and codify it in the form of a base application and suite of plugins.
I'm describing the reuse proposition, one of our profession's holy grails, which ideally would bear fruit in terms of cost savings and shortened time-to-market for our clients. Not to mention that a productized Hashrocket Launch Pad is a product that I could sell at a profit, proven by folks such as Pivotal, with their social media platform, licensing for which starts at around 30k.
Initially, Launch Pad was an informal effort and we didn't have a good way to measure progress. Months ago, we went through a storycarding effort to identify the features desired and establish accountability for progress. The stories were entered into our story-tracking tool, Pivotal Tracker, and estimated.
Here's a illustrative snapshot as an example of the type of stories we ended up with:
If you're familiar with Tracker, you know that the green background on those stories means they were finished and delivered. Acting as stakeholder for the project, I went into our testbed deployment and verified that the features requested were present and met my expectations. So far, so good. After getting through most of the stories, we now have a version of our Launch Pad that exists in the form of a "baseapp". Not quite salable, but useful in the following way: we can clone it as a starting point for greenfield projects, to get that big initial boost in velocity.
Therein lies a problem. It's one thing to have a rich set of functionality in a baseapp when you haven't started a project yet. WIN! It's a whole 'nother thing to have a baseapp with desired functionality when you need to add that functionality to an existing project. FAIL!
The answer of course, is to factor the functionality into more-reusable forms, namely Rails plugins (or gems) that can be added piecemeal to either a barebones baseapp or an existing project. How do you track that work?
We recently had a storycarding session to try and figure out how to do that. The issue is that now we are not focusing on end-user functionality. The user role (in terms of acceptance) is the application developer that needs to use the plugins and gems that we ultimately end up with. Unfortunately, it took quite a bit of time to reach that somewhat obvious conclusion!
Round and round we went, trying to determine how to name the story, describe it and structure acceptance criteria. After much argument and fretting about implementation, we eventually we ended up with something like this:
Story: Adding Photos
In order to provide photo collections for my client,
As a developer,
I want to be able to add photos to a domain modelAcceptance:
- Installation instructions
- Declarative macro makes model act like a photo collection
- Generator-created: Photos controller that includes photo resource module
- Generator-created: Views (new, form partial, javascript, FancyUploads)
- Generator-created: migration
- API documentation
This is a very high-level story! One of my guys called it a "12-pointer" to denote how much it needed to be broken down in order to fit in with our typical process (limited to 1, 2 and 4 point stories).
The problem is that as the stakeholder, I don't want this story broken down! This is the level at which I want to do acceptance, for at least a couple of reasons: 1) I already went through a long acceptance process for many of these stories the first time they were implemented, in the language of the end-user. 2) In order to properly define acceptance criteria for this story, I would have to know exactly how it's going to be implemented, and that information is not available until they actually sit down to figure out how to do the extraction into gems and plugins. In fact, one of the reasons that the storycarding session was feeling so painful was exactly that we were spending so much time arguing about implementation -- out of place in a typical storycarding process where you leave implementation details for later.
That said, to do acceptance for an application developer story, I would need to go in and do things such as follow the API instructions to add the photo functionality to a testbed application. It was starting to feel like I was using our typical story-driven process in anger. It shouldn't be this hard to do something as conceptually simple as an extraction to plugins.
Somewhat frustrated, I ended the storycarding meeting and changed direction. Come in tomorrow and take one of the features from our existing testbed application. It has really good spec coverage, so spend the day extracting it to a plugin and make sure you don't break the testbed app's specs. The following morning we'll have a meeting to see how you did.
Where have you experienced limitations of a story-driven process and how did you deal with it?
