Agile and Stage Gate Development

I've long been a proponent of small teams of individuals working together in a fast-paced development environment, reminiscent of "xp" (or extreme programming), and I came across another great article from Lost Garden, Rockets, Cars and Gardens: Visualizing waterfall, agile and stage gate, which described a succinct and clear development platform and management methodology that I already embrace and didn't have any name for and simply believed to be "agile best practices."

It's called Stage Gate and consists of cross-breeding portfolio models and iterative development. I worked at Lockheed Martin Missiles & Fire Control over in Grand Prairie for about 7 months in an internship, and they believe strongly in following the waterfall method for their projects, although they were at that time also researching agile practices and methods. I subequently worked at L-3 Communications Link Simulation & Training for roughly 10 months in 2 separate terms, first as an intern, then as a Software Engineer I, and their ethic was more of an iterative development approach with constant integration of the coding platform, so it was a bit closer to achieving that agile best practice method for such a large company.

Both of these work experiences enriched my belief in the iterative system, especially since in between the two, I worked at a small company called FoodTronix. FoodTronix is a great company, but during my tenure there, the company was expanding faster than it could handle and hadn't looked into these techniques, falling into that haphazard pattern of developing whichever feature was being demanded most by the customers without a rigorous testing process or any thought into documentation, alongside being severely understaffed. These problems are typically considered huge, but the company was able to handle the fires primarily because they were in a constant dialogue with their customers. FoodTronix is a Restaurant Point of Sale system. I've seen better and worse. What sticks out with this company is their customer service and their adaptation to changing and evolving customer needs - they always handled their customers with care and immediately helped them address their issues and resolve their problems, putting out patch after patch until the biggest fires were extinguished acrossed the board for all of their customers.

To summarize, I learned from these experiences that an iterative development model worked very well for me as in individual and for large companies, along with agile and xp practices such as continuous integration, adaptation early and late into development. I had also seen that I worked better across multiple projects with a selection process of picking which ones to proceed with through a series of comparisons, which I can now call kill gates, in which I examined each project, its pros and cons, its required estimated time left, its original purpose and its final, intended result.

I hadn't heard of portfolio models until I read the post, but it seems like a very logical solution - that of spreading and managing risk via multiple projects in parallel. Now, I don't work on multiple products at a time, but I love the breakdown of how even an individual product can be compartmentalized into several isolated projects with focused teams on a susbet of features or some sort of a divisional area. Of course you have to have overall management, but the Cabal method described by Valve in the Gamasutra article he referenced seems to impart to me a singular philosophy of involving everyone in a project from each of the individual areas in a face-to-face meeting of brainstorming, understanding the individual areas a bit better, and learning how to work with each other better, overall.

I think I'm going to put together a post, eventually, that summarizes my exact philosophy and posit if it can be beneficial to others to follow along and see what intuitive changes they make to the process. As an independent consultant and a typical nine-to-fiver in a small team at a mid-sized company, I find that I don't have to necessarily adopt separate methodologies of work in order to fully harness and focus my energies. In fact, having this one, tight philosophy of adaptation and managing your time across multiple projects with constant customer interaction allows me to state that the focal point is in organization, management and preparation of the overall product in conjunction with the rest of your team and your vested customers, whether you're a project manager, a software developer, a customer, or an external party relying on a completed component for your own development or use and aren't originally invested in the product.

Yes, you have to get the work done, and you have to test, and you have to ensure that everything is consistent, visually, functionally, etc. - but the focus isn't on making sure you're meeting some deadline and writing x amount of source lines of code, or writing tons of documentation or trying to "design" and "architect" the perfect end-all solution, but rather that you're achieving the customers' current and immediate needs with a look ahead (but not a project) to the future, and that you, your team, and the customer all understand that as customer needs evolve, the product evolves, the project schedules evolve (be it a delay or a cut in time), the team evolves, and the business relationship evolves.

Either way, some of the great resources I've come across that I prefer to read and take a look at whenever I have some spare time include:
Free To Play,
Lost Garden,
Agile Game Development,
Extreme Programming,
Gamasutra.

Also, if you're ever bored, check out 8-Bit Theatre, CAD the Series, and Pandora.