Understanding the Need for MSF

MSF was created as a response to customer demand. MCS used to receive calls from customers and partners asking such questions as How does Microsoft handle roles within a team? How does Microsoft structure projects? And so forth. Rather than continue fielding these questions, the MSF project was developed and the first version came out in 1991 to "codify" their process.

Important

The Microsoft Solutions Framework is not a process methodology per se. It is a framework to help you create and instantiate processes.

MSF is constantly evolving. For example, each of the product teams at Microsoft has their own way of managing and developing software. Some of the approaches are successful, some less so. The lessons learned are rolled in (and show up) in each subsequent release of MSF.

The goals around MSF have also changed and evolved. One of the challenges in the IT industry is to get a handle on the risk and complexities of software development. Cost and time overruns are all too common - the sad truth is that too many of us use guesswork as an estimating tool. One common scenario in the companies I've seen is when the marketing, sales, or business analyst team hands off projects to the development team. A pressure is generated to deliver on time, to "time box" the project. Unfortunately, often there is no appreciation of the complexity of what is promised in the sale. The complexity of business requirements is escalating, therefore so is complexity of the software. To be fair to the sales staff, they have no measure to go by in determining what's workable and what isn't within a time frame.

In this pressured environment, the developer is usually the scapegoat responsible for the burden of the project. (Although we all know that the entire team should be responsible.) Stress builds as the developer must spend many overtime hours and suffer through sleep deprivation to reach the deadline. The quality of the software dips, bugs creep in, schedules slip, and the developer is ultimately to blame. Does this sound familiar?

There is a huge effort under way to find ways of regulating software development projects. Everyone is looking for a magical formula. So, what is being done about it? One of the successful approaches is by developing and using so-called mature processes. You can use statistical methods, engineering principles, manufacturing and scientific approaches, and adapt them to software development. Hence, the focus and terminology makes a big change - you are no longer developing software. You are now engineering software!

One of the ways the industry can measure the maturity of a process is through the Capability Maturity Model Integration (CMMI) certification developed by the Carnegie Mellon Software Engineering Institute (SEI). Maturity isn't attained overnight; therefore, the focus is on a gradual evolution toward process improvement and maturity. What's interesting about CMMI is that it doesn't really endorse any specific process - it simply looks at and evaluates the results.

Heavy versus Light Processes

At this point, you might be thinking that all of this sounds rather heavyweight. So here we have a balancing act: On one side, we have a comprehensive systematic process but little in terms of agility. On the other hand, you can have lots of agility but very little in terms of predictability. The middle ground is to consider process as a tool to help us reach our goals. People are more important than process. (We are definitely not at a point where we can push a button and produce software - although code automation is something Microsoft is striving for in their vision for Software Factories.)

If you look at a process such as the Rational Unified Process (RUP), you'll come to realize that it is pretty darned complicated. The intent with RUP is to provide everything you could possibly need. Then it is up to you to whittle the process down, remove what isn't needed until you have something workable and manageable. The problem is that in reality, very few people have enough expertise to make the informed decisions of what to take out; therefore, many companies adopt the RUP process in its entirety with varying levels of success. MSF takes an opposite approach. It includes comparatively lean guidance and documentation. The intent is to provide a simple framework that you can then scale up as needed.

Some consider a process guidance document as a thick binder that sits on someone's desk. There is a disconnect between the process and the people using the process. Team System bridges the gap by incorporating process automation features and easy-to-get-to guidance anywhere from within the product. Mind you, not everything is automated, but it's relatively easy to adopt a process within your development project.

The previous version of the Microsoft Solutions Framework focused primarily on being a framework for developing processes. Version 4.0 introduces Agile concepts and patterns, security guidance, and, most importantly, a direct correlation between a process and results. Team System has many reports that provide a rich feedback mechanism to gauge if you are on the right track, or if you are veering badly.

As you are exploring different ways of managing software projects, you'll come to realize that there isn't a single process that will do the job. One of the common misconceptions about Team System is that you can and should develop a single template per company. A more realistic approach is to evaluate each software project as a different entity with different requirements. A company will end up with several processes (and templates) to fit each circumstance. MSF also does not necessarily need to be used in a development project. You can apply its principles to infrastructure and other nonsoftware related projects.