Elaboration and Stuff of the Agile Pipeline

Our experience with agile is that it yields a considerable speed advantage to the market over the traditional waterfall and RUP framework approaches. While just an intuition, the 30% to 40% boosts reported in the press could be very close to the gain we are seeing in our Denver office. Stretching agile to offshore, we also see a boost over a traditional approach with the estimates being 20% or so. I should note that our first offshore relationship, roughly a year, with a large provider in India, we did not see any gain and instead discovered high attrition and agile were a deadly combination leaving us with low velocity/feature output. The situation with Moscow is quite different with agile being very compatible to the team.

Starting with a definition: The agile team “core” is those engineers that take a storycard, task it out, do design, implementation, unit testing, integration, and demonstration over two-week (our choice) iteration. In our model, the core depends on the product manager (PM) to identity and elaborate product features and on the software quality engineering (SQE) members to do feature acceptance/testing. This all sounds good but once a world class core is ramped up the pacing problems across the dev pipeline, feature to accepted code, become focus points. The PM can fail to “feed” the core with enough feature detail to keep them going and the SQE guys can fail to keep up with the feature outlay. Today, I’m focusing on the front-end, the elaboration process.

A simple model for the front-end looks like this:

So this looks fairly straightforward but raises the question of who does the elaboration. Start with the view that the PM is charged with elaboration. This is really only one possibly with the elaboration taking several different paths and the picture looking like:

Let me emphasize that “elaboration” means “written description of requirements” This shows 4 possibilities with the PM taking the elaboration load, a sharing in some way, the dev engineer doing it all, or a null path. The top bubble often becomes the second bubble with the engineer asking questions but, of course, the answer may not be written down. The null approach occurs in at least two ways: 1. the feature is so simple that even my youngest cat could implement it if he knew Java versus Modula or 2. The engineer is well grounded in the product, having maybe built much of it from the ground up, understands the usage market well, and can go directly to design from a brief feature description. Before the SQE manager beats me up, it is important to note that if the null path is taken, it might be necessary for the implementation to be explained to the quality team or they might be left wondering what the feature means when implemented. The same words apply to the tech pubs team that must write about each feature for the user documentation.

Our experience is that a development train payload, composed of many features, may spread features out across all four of the paths. The null path is the fastest path to functionality but honest scoring must account for the time taken for verbal walkthrough/explanation to the SQE team on finishing up the implementation. It seems that as a team grows with product creation and grows in its understanding of the market needs, meaning many releases without much team churn, the null path takes a larger percentage than in the early days. Velocity, feature production for core members, does go up with this being one of several contributing factors. Definitely the manifesto words “Written software over comprehensive documentation” come to mind.

Now, with this simple model, we can look at what happens when we go global with the team split across between Denver and Moscow. The PM is in Denver close to the market. The dev team is offshore. The challenge: Don’t bottleneck with elaboration.

The cautious approach is for the PM to elaborate everything. They are close to the domestic market and definitely should understand it. A high aggregate velocity, total feature product across all core members, means more than one PM might be needed not to slow things down or the PM might have to be several weeks in front of the current iteration cranking out requirements grist for the core to chew on. That sounds very much like waterfall-like agile. (The oxymoron light just went on.) One alternative is to have another PM in Moscow with who shares the elaboration and question answering from the team. We’ve done that and it works. We have also done a variation where the solution is a daily verbal exchange to elaborate features. It means lots of hours on Skype and it also is somewhat like the null approach in that somewhere the SQE team must catch up/understand the functionality behind a feature. There is also the approach where the developer takes the SQE team through the functionality, they take notes, develop an attack plan and hit the features with tests. This might also mean the SQE team has someone whose job is to interview the developer and render the functionality to written requirements. Some places see this as the role of a requirements engineer.

Just thinking about what works and could work better, the front end comes to mind and I have not even touched on the all the craziness that happens in prioritizing the requirements and keeping that priority dynamic as the train flies along through the many iterations.