CA Development Lifecycle…Episode 2
Greetings! This is my second post in a series I recently started discussing the Software Development Lifecycle we use here at ChannelAdvisor. If you have not yet read my prior posting on this topic, you may want to do so now. It’s a fascinating tale of pirates, danger, monkeys, and death defying software development on the high seas!
Previously I covered the concept of Software as a Service and then delved into the different system “environments” we utilize to deploy our software. In this post I will describe the concept of a “Change Request” and how those are categorized, ticketed and tracked. In upcoming posts I’ll focus on how Change Requests are deployed (”Short Term” and “Long Term” releases), and will delve into our movement towards Agile Development.
Change Requests
Within the company, every time a defect is found in our software (ahem, never), every time someone mentions “wouldn’t it be cool if the product could do X” (ahem, always), and every time a service request is issued to the engineering group, a “Change Request” (CR) ticket is opened to record and track the request. We literally log hundreds and thousands of these requests against ourselves, no matter how large or small in scope.
With all of those tickets opened, the use of Change Management software is critical to providing us order from the chaos. Currently we use a product called Synergy Change from Telelogic. It’s a solid product and serves our needs sufficiently, but could definitely be a little cheaper (just in case someone from Telelogic is reading this heehee).
Among other things, the use of structured change management in our development processes has provided us with the following advantages:
- Any request, no matter how large or small, is recorded in a database and assigned a unique identifier to reference and track the request over time. This provides clear ownership and accountability for handling this ticket, and prevents ideas from getting lost in the ether of e-mail.
- Requests are categorized and assigned according to Product Area (Paid Search, Comparison Shopping, Pro, Merchant, etc.) and Component Area (Posting, Invoicing, Emails, Feed Generation, etc.). This allows the workload to easily scale across multiple product teams.
- Requests are ranked according to severity and priority, as determined by the Product Manager (aka Business Owner) overseeing the request queue for their specific product area. If an item is of sufficient high priority/urgency, it is queued up for review for a specific upcoming release. (more on this in a later post). Since there is only finite time and people to address all CRs, prioritization of issues is critical to keeping sanity in the work process. Product Managers work closely with your Account Managers to best prioritize the incoming requests across the needs of all of our customers.
- The work required to resolve a CR can be estimated by both a Product Development (implementing the change) and Quality Assurance Engineer (making sure it all works). The combination of those estimates is used to evaluate an overall “Level of Effort” needed for resolution of the request. Changes that have a lower Level of Effort and higher Priority/Urgency are more likely to be released sooner than those that have a High Level of Effort and low Priority/Urgency.
Change Management Workflow
All CRs in our system are categorized into 1 of 4 distinct buckets:
1. Defects - A feature in the system is not working as designed. This may be presentation related (UI showing the wrong thing), data related (item should be X, but really is Y), behavior related (when I click this button the system goes “thud”), etc. Defects are assigned a severity between 1 and 5, where 1 is a critical flaw that is preventing some or all users from conducting business, while 5 is a minor issue that can easily be worked around (typo on a page, etc.). The Product Manager has oversight to reassign defect severities based on extenuating business needs, but otherwise these are triaged and ranked by the appropriate Product Development Team Leader. Defects can be reported from a number of sources including our Quality Assurance team, our Customer Service representatives (on behalf of our customers), our Sales and Services teams, and our internal engineering teams.
2. Enhancements - A request for a new feature in the system. Enhancement requests are ranked by a High, Medium, Low priority, where High is defined as “will have a profound effect on the user’s experience with the product”, Medium is defined as “will affect the day to day use of the product”, and Low is defined as “will not have a day to day affect on the use of the product” (e.g. a minor “tweak” that will periodically be leveraged). Enhancements can be requested from within and without the company, but are ranked and prioritized by the Product Manager owning that specific product.
3. Work Order - A work order is a custom request for serviceable work needed on the system, typically initiated by a specific customer. Work orders typically don’t involve changes to the software, but rather updates to the underlying data that are not easily achievable in bulk through the user interface. Work orders can be time consuming to our engineering staff (when working on a work order, they are not working on improving the product), so they must be used judiciously, but in some cases it just makes sense for us to best service our customers by handling a special request through a custom work order. The Account Manager and Product Manager work together to rank which requests should be handled as work orders.
4. Architecture Issue - Architecture requests are typically opened only by engineers for engineers. They address infrastructure related aspects of the product. For example, if a particular page is loading slowly, an architecture request may be opened up to optimize the loading of that page. Architecture requests sometimes have quick fixes that can go out in a short term release (optimize an existing function), and sometimes require major rewrites and new systems to support - a good example of this being our switch to a full text indexing engine for our ECommerce Stores in the last release, which is much much faster than the database-driven searching we had before.
With Synergy Change, each of the above categorizations can proceed down a different “workflow” for implementation. The workflow controls who needs to be involved at which point in the software development lifecycle. For example, a defect will involve prioritization by a developer, estimates from both developers and QA engineers, resolution by a developer, testing by a QA engineer, and deployment by a release engineer. A work order, however, would only involve prioritization by a Product Manager and resolution by a Developer or Systems Engineer, no validation by a QA Engineer or deployment by a Release Engineer. The Change Management process shepherds the appropriate changes along the workflow every step of the way, keeping clear ownership and understanding around the entire process.
To be continued…
So now we’ve covered SaaS, our software environments, and how we classify requested software changes through Change Requests. In the next post I’ll get into how we deploy changes in a rapid “short term” development process. Later still I’ll delve into our “long term” process, and our forays into Agile Development. Like a typical Hollywood franchise, I will likely need to break my “trilogy” into 4 or more sequels, I’m figuring it out as I go ;-).
Stay tuned…