JISC Software Development Model (Proposed)

Recently it has become apparent to me that most JISC projects go through a specific kind of software development release cycle in comparison to the business software development model (naturally). Of course most are all using a ‘rapid agile prototyping’ development processes (right-rapid-rough as pioneered by Tom Kelley and the IDEO design company), which then lends it self to the current big Web 2.0 companies and their dev processes: Flickr, Netvibes, YouTube, etc. Very similar to Venture Capital funding. However, the trouble with this model is that JISC projects do not have teams of developers (nor teams of monies). My friends down at Google HQ tell me that optimal dev teams are usually 4-6 developers per team with one manager (and anywhere from 20 million to 50 million invested as a first go). And of course, that manager is under the gun to see the code produced get monetized as a product (yielding at least 300% profit). This in comparison to JISC’s typical tag line: “no harm in just learning”. Which is the right ethos, but methodologically the wrong process.

There needs to be a greater push by JISC to emphasise that a project should release a product to the wild -yes to the World Wild Web- not just .ac/.edu; and if that product fails we should recognise it needs to be cut down and dissected picking out the cause of death (i.e. evaluating the project but only for its failures). The emphasis in still on learning here, but learning in the sense of producing a manifestation that could hypothetically be “bought on eBay” (because it is valued). Now don’t get me wrong, I’m not saying we should be actually selling these things (FOSS all the way), but we should have a competitive nature in releasing something that is worth the communities time to actually implement themselves, e.g. others institutions willing to invest their own hard earned cash to utilise the code the project produces.

I have the sneaking suspicion (partially because I have done it myself) that most projects actually look to utilise the money for their own institution infrastructure; producing bits of code that are really only valuable to the specifics of their systems. Throughout being a project manager you are faced with decisions to spend the money on code that will support the community or code that will support your institution (and most times they are not one in the same!). My argument here is that JISC project should always be choosing the quick wins for the community (not quick wins for their institutions).

Currently with the size of budgets that JISC provide (one project manager and one developer) I see the following pattern emerge as a template for JISC software development that requires a definitive product release:

Given there is nothing “really” new about this model: it is just a shortened version of the “New Product Development” model and “Software Release Lifecycle” model. Most JISC projects iterate through an alpha (technology testing strawman) and beta (user testing) stage. However, after these stages JISC projects need to start coming up with the goods. They can’t be a Flickr where they iterate through a 2.2.1342b minor version releases before they are “gamma”. JISC project must produce small releasable products to the academic market. An analogy might be: Flickr releases protyped cars and JISC projects are releasing a dust-buster (dust busters can break down without hurting anyone, cars cannot)?

= Venture Capital Web 2.0 Real World Wild Web Projects

= JISC projects (if they are successful)

The diversion in my model comes with the “the Zenith cycle” as the third cycle in a three part agile development process (alpha -> beta -> zenith). Using a rapid prototyping model, the three step development cycle offers the opportunity by a development team to first test their proposed product ideas (alpha or pre-alpha) making sure it is technically feasible; the second cycle (beta) is the rewrite and scaling up of the alpha cycle to see if it will work in a real world environments, or debugging: often bringing in novice users of the system (and most likely throwing away the alpha code). And finally, is the zenith cycle where a definitive product must be launched and disseminated to a community for pick-up or monetisation. If the community picks up the product (independent use outside the projects own initiation) then it is a success and the three part cycle starts over at a level 1 (as opposed to level 0) whereby they look to enhance the technology for further use. If the product is rejected then the development team stays at level 0 in product initiation and may forgo the creation of the product all together (as in venture capital models).

Ok to surmise:

1. JISC projects should aim to release a product at the end of their funding
2. They should be able to reach a first release of the product in three cycles (alpha - beta - zenith), e.g. 18-24 months
3. If the product is not picked up by other institutions (independently) then the project should be declared a failure and report where it went wrong (still no foul in learning).

**I am interested in the U&I dev model JISC has been pushing, but we are not far enough down the road to comment on this yet.  We are looking into a agile project management tool called Mingle by Thoughtworks which looks to be free for Academic and OS projects!

~ by dfflanders on February 21, 2008.