Agile in the beginning: the Microsoft Solutions Framework circa 1993

I recently presented MSF v4.0 (alpha) at TechReady 2, Microsoft's internal technical training event in Seattle. This is the first time I've shared a stage with Bill - but not at the same time ;o)

Microsoft has a long history with the Microsoft Solutions Framework (MSF) , which started back in 1993 -- that's a 12 year heritage! There aren't many frameworks that can claim to have added value to the development process for over a decade. I've been involved with MSF since 1998.

There have been some comments on the newsgroups that Microsoft invented MSF in recent times to badge its version of Agile which is present in Visual Studio Team System (VSTS). In fact, the original MSF from 1993 contains many Agile-sounding principles.

My friend Clementino Mendonca located the original MSF v1.0 guidance and highlighted some statements it makes, for example about design documents -- or the lack of them. If you read Agile authors you will hear refreshing statements like "Produce no document unless it's need is immediate and significant" . Elsewhere you can read pieces on Agile that ask questions like, "Why do people document?"  which suggest that teams should produce "barely enough" design documentation.

Back in 1993, MSF v1.0 was saying something very similar:

Why No Design Document?
The customer is rarely the intended recipient of a design document. There are generally two uses for design documents:

• For purposes of management and communication between Development team members.
• To aid in maintenance and enhancement after release.

For purposes of management and communication between Development team members, the need for formal design documents is established by the Development Manager with his/her development team. At Microsoft, design documents are developed when they are needed and, when memos, meeting notes, and interface specs are sufficient, time is not spent writing formal design documents. "When they are needed" might be:

• Starting a new product.
• When team members are new to the company or to each other.
• When the design issues are complex.
• When there are too many developers on the project to ensure adequate communication otherwise.

Realistically, many corporate development projects have all of these characteristics, and a Development Manager should consider carefully a decision not to build design documents at some level.

For purposes of maintenance and enhancement after release, the best answer is to have self-documenting code and to generate any supplemental documentation automatically from the code itself. Of course, interface and call diagrams are often indispensable. A development manager should consider allocating time late in the development cycle if up-front design documentation is not critical.

extract from Microsoft Solutions Framework v1.0 - Solutions Development Discipline, 1993

So it seems that "agile thinking" isn't new: it's a bunch of good ideas, expressed in MSF and elsewhere. It would be interesting to trace the origins of the daily build and other good dev team practices. Who did it first?

This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm

Comments

• Anonymous
  January 20, 2006
  I wonder if either you are joking or this is a troll? You think Agile is about minimal documentation?
• Anonymous
  January 21, 2006
  The comment has been removed