To date, almost all methods (especially the “new methods”) that have garnered significant support have originated from the custom software development community. Be they inspired or guided by government organizations such as the CCTA (Central Computer and Telecommunications Agency, the British agency responsible for SSADM, the Structured Systems Analysis and Design Method) or be they guru-inspired by the likes of James Martin and his Information Engineering, they come almost exclusively from custom developers. IBM has tried, over many years, to produce methods that they could persuade their customers to use but with a shocking lack of success.
The latest and most widely respected method from such quarters is of course the Dynamic Systems Development Method (DSDM), which was conceived by major commercial organizations who develop their own internal software systems and has, since it started, collected a large crop of software houses with an eye to the main chance as supporters. DSDM is one of the crop I have called “new methods” and is well regarded among its adherents. By looking at the founders of DSDM and the very checkered history of development success that they share, however, we will discover that DSDM did not in fact have to produce spectacular results to show large improvements. Perhaps we should look elsewhere for methods that succeed.
One place we can look to is the producers of shrink-wrap software. Of the major producers, Microsoft provides a ready and sound source for examination because it publishes its methods for the benefit of its Solution partners. Microsoft refers to its method as a framework rather than as a method, and this choice of wording is instructive. “Framework” connotes flexibility and general approach rather than the rigidity and prescriptive nature of traditional methodologies, and the documentation regularly emphasizes the overhead associated with such prescriptive methods. Rather than dissect the Microsoft Solutions Framework (MSF), however, let’s look at some elements of the framework to get a feel for its similarities to and differences from existing methods, particularly the popular DSDM.
Like DSDM, MSF is very articulate regarding the flaws of methodologies. Also like DSDM, MSF uses the regular production of prototypes (especially user interface prototypes), but it does so for a different reason. Rather than use the prototype to confirm and extend the agreement about functionality, MSF uses prototypes to ensure usability of the eventual system. To cover the constant emergence of requirements, MSF advocates a consensual change-control process (although personally I consider this an oxymoron).
Although MSF wisely acknowledges the tension between requirements and functionality delivered, one has to question the severity of the disputes in this area that might arise in a shrink-wrap producer. After all, the customer didn’t ask for this software and isn’t explicitly paying for its development while it’s in progress. I do, however, approve of Microsoft’s description of the topic as the vision/scope dichotomy. To quote the documentation, “…Vision…articulates the ultimate goals…. Scope is the opposite of Vision: it defines the limits….” Still more enlightening is, “Further development may come in future versions.”
MSF is particularly interesting for the emphasis it places on what it calls the Team Model. It is, I believe, fairly unusual in paying such service to the valuable contribution that people make to software development. This acknowledgment of human ingenuity and skills is long overdue and possibly one of the keys to Microsoft’s success. Within the team model, MSF advocates small teams—another sound principle.
Two other points in MSF warrant mention: risk-driven scheduling, which advises developing the elements with most risk involved first, and component-based solution design. Together with the design for usability focus already mentioned and the emphasis given to team models, MSF comes out as a thoughtful, nonprescriptive approach to software development.
However, there have been times when Microsoft and other shrink-wrap software producers have experienced problems that affected delivery schedules and product functionality. It is likely that these companies experience some of the same problems as custom developers do: contradictions, a constant to-ing and fro-ing of likely functionality, and continually shifting delivery dates.
It’s also possible that frameworks didn’t scale up. Perhaps the size and complexity of the project undertaken, the time frames announced, and a more adversarial position result in some of the method not being heeded.