Copyright

All the information available on this website is subject of copyright laws and regulations. Still, it can be used for non-commercial purposes with the previous approval of the owner, specifying the source.


Monday, 22 October 2007

CMMI PP + PMC vs. Planning in XP

A first mention is that there are some types of software projects for which a traditional approach to project management is more valuable than a hybrid between XP and traditional. For example, projects that:
·
Involve mission critical or safety critical systems, where formal methods must be employed for safety or insurance reasons
·
Are large projects which may overwhelm informal communication mechanisms
·
Have complex products which continue beyond the project scope to require frequent and significant alterations, where a recorded knowledge base, or documentation set, becomes a fundamental necessity to support the maintenance.


Now, if you take Agile/XP Methodologies to a certain level of formalism, it can map, or at least it can go along with what they call traditional approaches, like CMMI, but it won’t be pure SCRUM, for example.

Talking about SCRUM, it is based on some statements that should be true, if one really wants to benefit from this method:

- the teams are quite small (5 to 8 people)

- the customer is almost part of the development team (this means, excepting the fact that the customer has to be willing to spend his time with this team, a lot of logistics and legal difficulties – access for the customer in the local network of the supplier, NDAs signed, legal contracts, etc, etc; what do you do when you have several customers for the same product?)

- under no circumstances you will change the delivery date of the current sprint – meaning: you keep the committed date and, in the worst case, you cut off some of the features (and what is the benefit of this when your team creates only a small part of a system, part that has to be integrated with another 10 parts; and one of the other parts is just not working without the feature you won’t deliver this sprint; and the integration of the system + system tests take a couple of days; and all this for a system that will not work … but the commitment has been kept)

One thing to remember is that “SCRUM of SCRUMs” is for the moment just a philosophy. No company has implemented yet more than 2 levels of SCRUM. Or, when you have a company with hundreds or thousands of employees, in any kind of matrix organization, it is pretty difficult to resume the entire flow in only two hierarchical levels of SCRUM.

Anyway, in my opinion the problem is not in finding the way to make a correlation between the typical work products in CMMI and the items that XP methodologies are using. You probably won’t use the physical cards, but you can use an e-workspace that allows cards creation, collection and control. You might even get more benefit from something like this than from the pure cards. And this is just an example. (The estimations using story points seem to me ones of the most accurate. )

So, the only problem is in being able to satisfy the initial input requests of the extreme programming.

Once this happening, I don’t think that there are too many CMMI sub practices that you cannot implement when being agile or extreme, but, depending on the complexity of the organization and of the projects one might find out at a moment in time that the simplicity that agile practices suppose is not so simple anymore :)