In my last post I talked a bit about agile software development and how ChannelAdvisor uses an agile framework called scrum. Contrary to what many assume, “scrum” is not an acronym for anything. It is actually named after the scrum formation in rugby where everyone on the field is swarming together, focused and intent on their common goal of getting the ball.

In the same way, an entire scrum development team is very focused and aggressively attacks their shared goal together. Only there is a significantly smaller chance of getting a concussion (unless of course someone brings donuts into the office and there aren’t enough to go around - then it can get ugly!).

Scrum - along with most flavors of agile development - operates on short iterations. Each of these development “sprints” are several weeks long and has a specific goal that the team rallies around. At the end of each sprint you have completed software you can ship!

Take our StoreAdvisor Premium offering as an example. We started that project months before its triumphant release in August, but broke the development up into small chunks of activity. Every two weeks we completed new functionality. Every 6 or 7 weeks we rolled those features out. We started out being able to simply import orders from the store, but in subsequent iterations we were able provide a rich integration with MarketplaceAdvisor Premium.

By releasing code often - even though the entire product was not complete - we were able to get valuable feedback from our users about what worked well and what did not. Since we received that feedback as we were developing the product, we were able to adjust what we were doing as we were working. That frequent customer interaction made StoreAdvisor Premium much more solid than it would have been otherwise. The end result is we were able to launch stores like ProtoGolf and immediately increase their conversion rates by 300%.

To enhance their collaboration and intensity, scrum teams tend to abandon their individual desks and move into a “war room.” I’ll sign off by giving you a peek into one of our high performing scrum team rooms.

Share This

No, we aren’t trying to compete with Nastia Liukin - we just aren’t that flexible. I’m talking about something a lot more exciting than spinning through the air: software development!

After experimenting with it for a good while, last year the product development team here at ChannelAdvisor jumped wholeheartedly into agile software development. Specifically, a flavor of agile called scrum. This is a relatively new way of producing software that has gained a lot of popularity in recent years. It has proven effective for us on a number of fronts:

• Software is Delivered Incrementally
  Instead of spending tons of time planning and implementing huge projects, we bite off smaller chunks of functionality and get it in our customers’ hands as soon as we can. We then iterate on what we originally release to add on additional features and functionality.
• Software is Delivered More Often
  Those of you who have been with us for a while might recall that we used to have releases every 3 – 6 months. These days we release software every 6 or 7 weeks.
• The Customer is Directly Involved
  By getting smaller pieces of functionality in front of our customers more often, we are able to get valuable feedback as we go. Gone is the risk spending six months developing something only to find out it is not what our clients need or want.
• Change is Expected and Embraced
  In this fast-moving ecommerce world, priorities can change quickly. Since we aren’t working on big, monolithic projects we are much better able to change direction when we need to (and so be agile!). For instance, we don’t have to completely shelve a major project we are in the middle of just to respond to a new eBay requirement – we can just include it as a new priority in our next iteration of the software.

We believe in agile so strongly that we opened a specialized Agile Development Center at our corporate headquarters here in North Carolina. We have a set of small, focused teams dedicated to delivering real value to our customers, often and with high quality.

Over the next couple of weeks I’ll post a few more notes about why and how we do agile development here at ChannelAdvisor. After that, I really need to get out from in front of this computer and start training for the next Summer Olympics - I think Nastia has a bit of a head start on me.

Share This

If you’re looking planning on attending the e-Consultancy ‘eCommerce Solutions Supplier Showcase‘ in central London this week, we look forward to seeing you there!

e-Consultancy has kindly invited us to present our Marketplaces, Paid Search and Comparison Shopping technology solutions to the audience and we will also be touching on the new Google Checkout payment solution for online retailers.

The event kicks off at 1:30pm on Thursday 10th May at 76 Portland Place, London. ChannelAdvisor’s slot is at 4:30 - 5:00pm, followed by drinks and networking. If you’d like to come along and meet some of the CA team, register here for your place.

Share This

Greetings all. Hopefully lots of you were able to join us at our Catalyst Conference last week. I know I enjoyed sharing a beer with many of you by the pool (wish it was a little warmer, but not exactly a rough life).

Anyway, today I wanted to spend a little time talking about a topic I brought up awhile ago: Monitoring. I don’t pretend to be an industry expert on monitoring, or even a ChannelAdvisor expert for that matter, but I do know enough to be dangerous. I also feel this is a pretty important topic for you to understand, as our use of monitoring really can have a material impact on your business (or more appropriately, a lack of good monitoring can have a materially negative impact on your business, something we take seriously).

What is Monitoring?

As I covered in a prior posting, our products operate as a Software as a Service solution. This means our software must be online and ready to service transactions 24 hours a day, 7 days a week. The ChannelAdvisor software accomplishes a wide range of tasks under this charter: from posting auctions to ebay, to bidding on keywords on Google, to sending data feeds to Shopping.Com, to serving up checkouts to your customers. All of this software runs on lots and lots of servers, well over 200 and growing steadily by my last count.

(more…)

Share This

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).

(more…)

Share This