A while back I wrote a post about Valve’s Cabal process. I said I would look into it, so I did, by emailing Ken Birdwell of Valve and asking his opinion of the process. I asked him what he thought of the Cabal process in relation to the Agile process. I also asked how the Cabal process had scaled as Valve grew and what he thought about the Cabal process now. Here is his reply, pretty much cut and pasted as he sent it to me, minus the salutation parts:

I’m not directly familiar with any of the “Agile” processes, so I can’t really comment. Just now reading about them, most seem to post-date the development of our Cabal process, though my initial impression is that there’s probably a great deal of similarities.

Some differences to stress is that 2/3 of our development resources have nothing to do with writing software yet are critical to the success of the product, and our testing/iteration cycle takes up the majority of our development time, far more than is typical in traditional software development (there’s no automated unit-test for “fun”). The internal architecture – the non-gameplay specific portions of our software – follows fairly traditional development practices, but that accounts for less than about 20% of our development costs.

As to scaling, after many initial failures in the early stages of transitioning from HL1 development to the much larger HL2 development, we found that our cabal teams did not scale past 6 people, and have a very real maximum of about 8 people in any one cabal. To solve this issue, we created multiple overlapping cabal groups, along with a temporary “overwatch” cabal that would be formed at the 1/3 and 2/3 points in the project to evaluate each cabal groups and identify areas of missing communication.

I’ll be the first one to admit that our system isn’t the fastest system, nor the most efficient, but with 2/3 of our developers being non engineers, I think it does allow us to achieve a level of overall quality that isn’t really addressed by most development practices. Our method also has a severe limiting factor in that it requires an abnormally high level of autonomy in all of the participants, something that definitely limits our ability to quickly grow into a larger company. (The group that did Portal was the rare exception in that they had independently developed a process similar enough to our Cabal process that integration into Valve was relatively easy.)

Very interesting to say the least.  I think Ken’s reply, which I thank him for, points out some areas that the Cabal process is likely better in than the agile process.  Cabal seems well suited to very autonomous teams.  The idea of a large amount of freedom greatly appeals to me, although I don’t know how much most business would allow for that.

The other part that struck me was the point of how many non-engineers are included in the Cabal process.  It has been my experience with Agile (admittedly limited experience) that at times communication with non-engineers does not happen effectively and everyone suffers for it.  Now, I understand that in theory the “customer” in Agile is supposed to take care of this, but that just doesn’t always happen.  I can’t help but wonder what it would be like to have more non-engineers more deeply embedded in the Agile process.  It might slow things down somewhat, as Ken points out, but the gain in communication might be worth it in the long run.

Again, thanks to Ken for the reply.  Other ideas/thoughts on Valve’s Cabal process and/or on the Agile process?