Software Development Methodology Profile – Spillman Technologies
Spillman Technologies was the first software company I worked for, from 1995 to 1998. When I worked for Spillman they produced a UNIX-terminal-based law enforcement database application for county sheriff offices and police departments. They had about 400 customers at the time. Spillman issued a major release of their software product once annually, and made money by selling support agreements to customers that included perpetual use of the latest version of the software as long as an active support agreement was in place.
Spillman had a feature gathering and prioritization technique that was pretty interesting and was quite popular with their customers, and still intrigues me to this day. This activity centered around their annual user's conference, which every customer was invited to attend. During the year (or more) leading up to the user's conference, Spillman's customer-facing departments, like sales and support, would gather feedback from customers and formalize them into proposals for new features.
The highlight activity of the user's conference was the lottery for new features for the upcoming release. Every customer was allotted a number of votes based on the size of their annual support contract. I don't know the real numbers, but as an example, you could say that each customer might get a vote for every $100 they spend annually on support. So during this lottery, each customer had the chance to review the proposed features and spend their votes on the feature or features they wanted most. They could spread their votes among a number of features they cared about, or spend their entire allotment on a single feature they needed the most.
Customers who did not attend could of course enter a proxy ballot to vote for the features they liked. At the end of this exercise, Spillman had an ordered list of the set of features their current customers most wanted to see in the next version of the product.
This list comprised a percentage of the upcoming release, not the total. Again, I never knew the exact numbers so these will just be hypotheticals, but you could suppose that the customer-voted features might comprise 40% of the total release. Certain other groups within the company would also have complete control over a certain portion of the upcoming release, e.g. product management might have 30%, support 20%, development 10%. Spillman didn't have a QA department at that time, but in a typical software company today you would probably adjust those percentages for QA.
Based on the percentages, Spillman would allocate a portion of the overall effort to each group. Going with our hypothetical example:
- Suppose there are 10 engineers on the product team, each working a 40-hour week. (Spillman was religious about 40 hour weeks and I hardly ever worked overtime.)
- Allocate 10 months for development work, and 2 months for integration, testing, porting, and release.
- Suppose your engineers are 50% efficient, alloting the other 50% for meetings, administrativa, training, vacations, business travel, and sustained engineering (i.e. bug fixing).
- We'll assume 10 months is 42 weeks, which is a little conservative. 42 weeks * 40 hours per week * 10 engineers * 50% efficiency = 8400 hours of work per release.
- 8400 hours breaks down as follows:
- Customer Features - 40% - 3360 hours
- Product Management - 30% - 2520 hours
- Support - 20% - 1680 hours
- Development - 10% - 840 hours
At this point, all of the candidate features from each bucket would be estimated and each bucket filled with the most important items. Once each allotment of hours was used up, the bucket was full and no more functionality would be accepted for that release.
This was a great way to make sure that each release contained at a minimum a sizeable percentage of new functionality that most of the customers cared about. Additionally, a group like Support would normally use their allotment to add features that were needed to address key customer pain points, usually issues not so large to receive the popular customer vote. Development always knew they had some time each release to do work they needed in order to minimize engineering debt (refactoring, for example, or perhaps writing automated unit tests, or advanced tools). Groups could barter with their allotments; for example, Support might need 1800 hours to implement all the functionality they need this release, so they borrow 120 hours from Development to get what they want, on the condition that they give Development 120 hours (or maybe more) next release to pay it back.
In my experience this worked really well for every party involved. Every group knew how to get the functionality they cared about most into the next version of the product. Customers were generally quite delighted with the product. And the development environment was very, very sane: Because of how the releases were organized, developers hardly ever worked any overtime. Each release was simply filled up with the most important features; once it was full, no more work went in. It worked great.
