And here we are at the grand conclusion of my long running and equally long winded series about the CA Product Development lifecycle. Fitting that this occurs on Super Bowl Sunday, the one day a year when people actually watch commercials on TV. I’m sure everyone will be eager to read this posting between plays tonight…

For those catching up, you can read parts 1-3 in this series in the Software category archive of this blog. We’ve covered a lot of ground over the last month or so, talking about SaaS, our various server environments, change requests, and short term “CRT” vs. “HotFix” releases. Today I will close this series out with a discussion on our Long Term Releases and thoughts for the future (hover cars!).

Long Term Releases

For those changes to the software that are more considerable in nature (e.g. require more than 2 weeks to develop), a separate “long term” development process is followed. A good example of this is the “Matrix Inventory” (not to be confused with The Matrix) feature we unveiled last October, allowing our customers to apply parent-child relationships to inventory items that allow product variations such as differing sizes and colors. (for example, different sizes of the same shoe).

Changes of this scope require more upfront planning to pull off, and this is where our long term release schedule kicks in. Here is the lifecycle from inception to delivery:

1. Statement of Work (SOW)
This is where all the “big ideas” enter the world. Our Product Managers (PMs) spend a lot of time talking to our customers, analyzing and predicting trends in the industry, and listening to our Sales, Service, and Engineering staff. From this, they pool all of that information into a prioritized list of what they’d like to see in the next version of the product. From this list, they write up SOWs outlining the business case of why we should build a particular feature: how does the feature work and what is it trying to achieve (from a big picture perspective).

The PM then works with a Development and QA Engineer to estimate how much work it would take to implement and test that feature, potentially decreasing or increasing the scope of the feature along the way to yield the most favorable cost/benefit ratio.

With this business case in hand, the PM and engineering teams are then in a position to select which projects from a list of candidate SOWs make the most sense to tackle in the next release. All others are postponed until a later release, where they will repeat the same analysis cycle again.

As an analogy, say you’re building a spec house. At the beginning you should have an idea of what you wanted to build (”I want a 2 story Colonial with 3 bedrooms, 3 bathrooms, and a fenced in back yard.”). You might talk to a builder to get a rough estimate of how expensive such a house would be, and you’d look at your finances to see if you could indeed afford such a project. If the house was too big for your budget, you’d reduce the size. If you have a budget surplus, maybe you’d add some extras like a home theater (to watch the Super Bowl perhaps).

2. Requirements
So now that we have a list of features for the next release, the next step is to take those broad details and nail down specifics. Here the Product Manager gets into the nitty gritty - “we need a page to do X, Y, and Z. When you click ‘X’, this happens. When you click Y, this happens instead.” This can often take several weeks to complete, and involves frequent feasibility discussions with the development and QA engineers (including revisions on the estimates, which often lead to further iteration on scope).

To continue the house analogy, this is where the owner would be working with the builder on the specific requirements of the spec house: “I want a fireplace in this room, the kitchen door should open to the back yard, the fixtures should all be brass, etc…okay maybe marble tile is too expensive, let’s go with ceramic instead.”

3. Designs and Test Plans
Once the requirements are nailed down, it’s now up to the engineers to build designs and test plans. The developers lock themselves in a conference room and whiteboard out how they’d build such a feature, transmitting their thoughts to design documents and flow diagrams that describe the details of the implementation. Generally this is done in a 2-phased approach, first a “High Level Design” (broad strokes), followed by a “Detailed Design” (nitty gritty details).

In parallel, the QA engineers are charting out how they’d validate a particular feature works based on the requirements delivered. These test plans outline all the cases that must be tried to ensure success of a feature.

In spec house terms: this would be where the architect drafts up the blueprints. “This wall must be 6 feet tall, buttressed against that support beam, and wired this way, etc.”. The test plan equivalent may be analogous to an inspector: “all electrical outlets must be X inches off the floor, and must have a ground fault in the bathroom, etc.”

4. Implementation
This one is easy: your plans are in place, it’s time to build this sucker. The teams have project plans outlining the tasks, and follow those tasks on a daily basis. If implementation takes longer then expected, scope is reduced along the way. If quicker then expected, scope is either added or the release date is pulled in (almost always the former).

Here the builders are out at the site, pouring the concrete, framing the structure, doing the drywall, etc. If they find a sinkhole, you may decide you just don’t have the time or money for that home theatre. If they’re ahead of schedule and under budget (ha, I’m having trouble typing that with a straight face), maybe you might decide to add a hot tub in the back yard.

5. Validation and Deployment
The features are built and unit tested, now it’s time for the QA team to shake the beams and make sure everything is working as originally intended in the requirements. This is done in the QA and Staging environments as discussed in the first post. Inevitably problems will be found and corrected. Once the new code looks rock solid, it’s deployed to our production environment where you, our handsome, happy, and healthy customers can then use for the immediate benefit of your business.

To close out our analogy, this is where the inspectors make sure the house is built to code and the owner performs a walk-through to verify they are indeed getting what they requested. Any flaws that are found are written down and corrected - repaint that wall, reattach that fixture, etc. Once all looks good, the house is sold, the happy family moves in, and the new neighbors drop off cookie platters.

Agile Methodologies
The process discussed above is a tried and true example of what they call a waterfall software development methodology. Waterfall is well proven and scales effectively with an increasing organization size, but also suffers from it’s own limitations, especially in the SaaS world.

Perhaps the biggest limitation is the innate inflexibility to change that such a process incurs on a development project. By design, each new stage can not be entered until the prior stage is completed. This has the advantage of ensuring all teams and parties are on the same page for the progression of the project, but has the disadvantage of not being receptive to late changes that are a common fact of the “real world”. For example, you maye find out half way through implementation that the customer you were originally designing a specific feature for changed their business model, and the feature as originally designed may no longer be of as much importance to them. In the house example, maybe half way through construction a better lot comes available on the market at half the price.

At ChannelAdvisor, we have always worked hard to remain flexible to the winds of change around us - it’s much more important to deliver the “right” solution, then to blindly stick to a project plant that was assembled months ago when the world was a different place. With that said, the “Waterfall” approach above makes such late changes difficult to absorb, often requiring super-human efforts on the part of the engineering and PM teams to accommodate late in the game.

This is where the Agile movement comes in, or specifically the Scrum methodology in our case. Scrum is IMO a great methodology (and an integral part of the sport of Rugby), and much more relevant to modern software companies living in the SaaS internet age. It takes some adjustment to get used to how Scrum works, and I don’t pretend to be an expert (I’ll let you read the wikipedia link above to get more insight yourself), but my interpretation of Scrum is this: The world changes fast, and because “big” projects take so long to implement, they run a huge risk of becoming obsolete by the time they are actually delivered. (how many years did it take Windows Vista to come out? And look at how Google changed the world since Windows XP…).

So, why bother? Instead, break that big project into small chunks, and iterate heavily on each chunk. Write a little code, show it to your customer, get feedback, change it, and repeat. Do this over and over and over until you get it right. You may find that what you thought was important at the beginning of the project was no longer so important by the end - as people play with things their feedback drives how the feature evolves. They key is constant iteration - don’t get upset about constant improvements, embrace it!

This makes tremendous sense when you think about it, but does radically change 20+ years of proven software development practice. Here at CA, though, we’ve embraced the benefits this provides, and are moving more and more into the Scrum world every day. The advantages this provides our customers are immense: Scrum greatly increases the probability that what is delivered to our customers is in fact what they really need (and not what we think they need), and what is “needed” is delivered sooner then what is simply “nice to have”.

If your business is waiting on a core feature (say support for a new credit card type), wouldn’t you rather get that feature in your hands sooner, even if it meant the extra bells and whistles for that feature (say a pretty graph showing where people are using that credit card) comes out later? Obviouslly it’d be nice to have both and you have to make sure what is delivered works well and meets all of your immediate needs, but assuming that is the case, if the core feature comes out months before the “nice to have” add-ons, isn’t that better than waiting months for everything to come out together in one pretty bow? We think so and hope you’ll agree.

Scrum is already utilized by of our SearchAdvisor product development team, and will be rolled out to all of our other product teams later this year.

In Conclusion
And here we are at the end of this long journey. I hope everyone found this series useful and educational. Since this blog is sort of my weekend hobby right now, I may take a little bit off before my next post, but don’t fret, I will be back with more long-winded articles in the future. (until you tire of me, or they take me off the air).

Happy SuperBowling.

Share This