MSF vs. XP

The purpose of this article is to discuss about the relationship of these two methodologies. A basic understanding of both of them is assumed, if it is not the case, please go to the bibliography to find a couple of articles describing them.

We are talking about MSF for Application Development, because XP is related with the software development.

I will present the basic principles of each method, and how is this principle applied, or how it isn’t, in the other one.

XP Principles

Extreme programming is based on 4 values, courage, simplicity, communication and feedback.

XP better fits for small teams, a high requirement change ratio and a short time to market.

It also defines 12 principles:

1. The Planning Game. XP establish a procedure for determine the scope for the next release. This scope is the result of combine the business priorities and the technical estimates. A single unit called story is used in both, prioritation and estimation. If the reality differs from the plan, update the plan.
   The basic principles about planning are the same in MSF. Prioritize the requirements with the business needs, and make a bottom-up estimation. MSF also says “planning while building”, which means that you will need to update regularly the schedule.
2. Small Releases. Ship a new incremental version in a small cycle. XP recommends cycles between 2 and 4 weeks.
   MSF talks about versioned releases. The main difference here is the typical duration of each iteration. XP enforces the idea of being small releases, while MSF doesn’t recommends a concrete duration, but a MSF iteration typically is a 3-4 months one. These different sizes drive to the different lifecycles. The MSF life-cycle is an iteration of waterfalls, and XP is closest to the iterative prototype lifecycle. Both have the risk of degenerate the lifecycle. Into a rigid waterfall in case of MSF, or into the anarchic code and fix, in case of XP.
3. Metaphor. A description of how the system works. It’s shared between the business and technical people, and is used as a communication mechanism. The metaphor is the replacement of a high level architecture of the system.
   This principle is possible the biggest difference between XP and MSF. MSF tends to be an architecture-centric method.[JLC1] MSF has the principle of Shared Project Vision, which covers the purposes of communication mechanism between the business and technical people, but it doesn’t replace the architecture of the system.
4. Simple Design. The system should be maintained as simple as possible. If an unnecessary complexity is found, it must be removed.
   That’s a common best practice on every design, and MSF doesn’t say anything against this practice. The Living Documents could be considered related with the practice. The goal of baseline documents as early as possible can’t be achieved if you don’t practice a simple design.
5. Testing. This practice can be split in two; unit tests written by the programmer, even before to write the code; and acceptance tests written by the customer which assures the program is behavior as the customer needs. Those tests must be passed every time a change is introduced in the system.
   MSF[JLC2] .
6. Refactoring. A code restructuration technique used for maintain the code as clean as possible. Helps in maintaining the code flexible to accept new changes. Refactoring also drives the reduction of the code complexity.
   MSF[JLC3]
7. Pair Programming. A very characteristic practice of XP. All the intellectual tasks are done by two people together at the same computer. Improves the quality of the code, the knowledge transfer, the team productivity and the communication.
   MSF[JLC4] has a more conservative recommendation here, Code Reviews. Anyway, pair programming can be applied in an MSF environment.
8. Collective Ownership. Nobody owns a concrete piece of the system in exclusive. This means that anyone can change any code at any time.
   MSF has a different distribution of responsibilities. This could be applied inside the Development Role, but not to the whole team. Collective Ownership is very risky if applied in big teams.
9. Continuous Integration. Every time a small task is completed, it is integrated and built into the system. The integration process must be done once a day at least.
   MSF suggests Daily Builds (aka smoke tests) in order to compile the complete code daily. Some functional tests can be done with the build, but a complete tests pass isn’t the goal in MSF. XP has a stronger position on the integration. The integration not only means compile the code, but also pass the unit tests and the acceptance tests.
10. 40 hour week. More than 40 hours of work in week isn’t permitted during two consecutive weeks. The team has to be fresh every day, for a productive day of work.
    That’s a common sense practice. MSF recommends schedule with 8 hours-days, make use of a buffer time and bottom-up estimates. These recommendations drive to a more accurate schedule, with a reasonable work-time.
11. On-site Customer. XP mandates to have a customer on-site, absolutely integrated in the team.
    MSF has the figure of a customer representative in the team, the product manager. MSF doesn’t discard that the product manager is the customer. Customer focused Mindset is one of the MSF basics.
12. Coding Standards. The programmers adopt a coding standard, with the objective of improve the communication via the code.
    This practice is also an industry best practice. Even not recommending it explicitly, MSF is clearly an advocate of the use of coding standards.

Planning Concepts[JLC5]

Planning while building. That’s one of the basics of the Agile methods, instead of trying to be a predictive process, the agile methods define a reactive process, prepare to change whenever is necessary. There is a nice analogy in “Extreme Programming Explained” with the driving of a car).

Cost of change Curve [JLC6] .

Project Tradeoffs. The variables in any project are resources (people and money), schedule (time), and features (the product and its quality). As the team develops a product, it will inevitably have to make tradeoffs among the project variables. The key to project success is finding the right balance among resources, schedule, and features. Those variables can be viewed as having a triangular relationship. After the team has established the triangle, any change to one of its variables (or sides of the triangle) requires a correction to at least one of the variables to maintain project balance, including, potentially, the same variable in which the change first occurre. [JLC7]
XP[JLC8] defines four variables instead of three. While MSF defines Resources (people and money), Schedule (time) and Features (product and quality), XP identifies Cost, Time, Quality and Scope. Basically, XP treats separately the functionality of the product and its quality. While it’s harder to manage more variables, XP suggest let the customer fix the cost, and the project team to fix the quality, so the project only can negotiate with two variables[JLC9] .

Proactive Risk Management. MSF strongly pushes for a proactive and constant risk management, XP doesn’t do that explicitly. But, without the formality of a group of tasks and artifacts defined for managing the risks of the project, this position of proactive risk management is present on the planning game.

Team comparative

[JLC10]

Conclusion

From my point of view, we can consider MSF as a kind of Agile Method[JLC11] , or at least we can apply MSF as if it was one of them.

MSF has big similarities with a method like XP, especially in the process model and in the spirit of the majority of principles. Both make focus on communication.

The major differences between the two methods are in the distribution of the responsibilities within the team, and in the radicalism of XP. Possibly MSF fits better for medium-size teams (10-50 people).

References

 [JLC1]Review that. Pros and cons.

 [JLC2]Kinds of tests recommended by MSF

 [JLC3]Talk about design?

 [JLC4]Code Reviews

 [JLC5]Title for that?

 [JLC6]Elaborate the concept. Boehm reference.

 [JLC7]From MSF WP

 [JLC8]Talk about Boehm’s curve of cost or leave it to Planning while building.

 [JLC9]If the end date is also fixed you only have to manage the scope.

 [JLC10]Roles, responsabilities…

 [JLC11]Lightweight method is better?