The Guild Launch Development Approach

I thought I would give you guys some more insight into our development process. Every company develops a bit differently, and personally I like to see some of the "inner workings" of things, so here it goes. Following is a description of our "Release" process which is one aspect of development. I'll get more into the "Coding" aspect of things in some other blog.

Guild Launch operates on an accelerated time schedules compared to a lot of software development companies and application developers. Due to this we have a somewhat unique way of managing releases and our approach to them. I could probably find a name like "Agile Software Development" or "Scrum" that would approximate our system, but after doing web development for more than 12 years (scary, I know) it's a bit closer to "Stephen's Method" than anything.

Goals

Our goals for development and as a company are:

1. Frequent feature additions
2. High Quality
3. High responsiveness to user feeback
4. Frequent feature enhancements
5. Ability to respond to the market

Flexibility

The key to our release process is flexibility and an adherence to making a plan and working the plan, but not being hancuffed by our own plan. We plan at a high level to do a release every 2-3 weeks. This lets us get an overall picture from a scheduling standpoint. However, we don't time box ourselves so much that we don't develop a key feature just because we only have 2 or 3 weeks, which is why our releases fluctuate in time. Also, you sometimes see a major feature come out a week after another release because we actually worked on it in the prior release and then finished it up afterwards.

Scope & "What's in a Release"

In every release I try to create a core feature set or "theme" by having the following in the release:

A. 1-2 New Feature
B. 1-2 Enhancement to an Existing Feature
C. 3-4 Bugs or "Rough Edges" fixed or polished. (Major bugs are almost always Hotfixed)

The rest of a release is planned around the scope of those "core features" and our timeline for this release. If we have some more time in the schedule and the core features are small we fill in with more enhancements, more polish and more new features. If core features are larger in scope then we fill in with less. The goal here is to ensure the application is always moving forward and to hit our "core feature" mark, but deliver more whenever we can.

Quality Assurance

When you're moving fast and running light you have to make sure you give time to quality assurance. One thing we've done to increase our quality is bring in a new Customer Service person, Mike. Mike has been heavily involved on the support side since he came on, but in the last few release Mike's role as lead customer support has also morphed into him being the guy who "Green Lights" our releases.

This means that Jun and I, who do the coding, don't also make the decision to release the build anymore, Mike does. He tests it, plans the testing, helps us test it, then says "Go or No Go" when he's done. When you're moving as fast as we do QA is critical, so we're constantly evolving our processes here. As Mike gets more involved quality only increases.

Post-Release

I always dedicate time post release for tweaks. The day of the release is dedicated to fixing any issues that creep up and any minor tweaks our customers bring up. This, in many ways is the toughest part of the job because we like to engage our customers, but don't like to say "No". In addition, we seem more responsive some times than we do at other times. This is primarily due to where we are in the release schedule. We have specific times where we can quickly absorb and incorporate user feedback and other times where that feedback has to be put on a list to be looked at for a later release.

After a release I categorize feedback into things we can do in a Hotfix release and things that need to be further analyzed. From there we make a patch release following on the heels of our actual release. This patch release isn't a mistake. It is intentional and planned. We would like that patch release to contain only tweaks, but it also usually contains some bug fixes.

The Whole Shebang

So, to sum it up:

1. I figure out what goes in a release.
2. As things "Get into the code" I do Sneak Peak announcements to get user feedback.
3. We continue developing and incorporate user feedback.
4. Mike tests the release.
5. Mike green lights the release (or we do more testing and devlopment)
6. We do the release.
7. We do a user feedback tweak release
8. I do a "Postmortem" and figure out how to improve the next release and the release process
9. We start planning and working on the next release

Mind you all of this is done in 2-3 weeks. It's fast paced and it's fun! The whole goal here is efficient, high quality releases that incorporate as much useful user feedback as is possible. We hope you enjoy the results!

-Stephen