December 2005 - Posts
...then is it?
Yesterday I attended a meeting from our company's shiny new Software Development Methodologies Competence Center. A large part of the evening was reserved for MSF Agile. Microsof's Rossen Blagoev gave us an overview on the subject and told us some interesting things. He started by telling us some facts about the framework. One of the facts was that MSF has been around since 1993 and that other agile methodologies came up starting somewhere in the year 2000. He didn't actually say it, but it sounded like he was telling us that Microsoft invented the agile methodolgy. There are probably some people who want to comment on that ;-)
But is MSF Agile really agile? I'm not a real expert on the matter, but during the presentation I got the feeling that there is something missing. Rossen explained that MSF Agile fully complies to the Agile Manifesto and therefore really is Agile. Even Kent Beck was consulted for this by Microsoft and he could not disagree. The thing that is bottering me is that MSF Agile is a stripped down version of MSF 3.0 and tweaked to comply to the rules. Other agile methodologies on the other hand where created to solve problems that the existing methodologies could not solve. I think that this is a significant difference.
Furthermore the first "rule" of the manifesto is "Individuals and interactions over processes and tools". I think that MSF Agile doesn't really comply to the tools part. MSF Agile is thightly integrated with Microsoft's Team System and my guess is that they will make it even thigther in the future. As Rossen said, he hopes that like SAP and ASAP, Oracle and CDM, MSF Agile and VSTS will also be mentioned in one breath.
Does this make MSF Agile a bad methodology? Certainly not! MSF Agile is a lightweight proces that will make a perfect fit for a lot of projects. One of out teams is actualy working with it on a project and they appeared quite satisfied with it, especially with the Team System support for the process.
During his presentation Rossen made a good point by saying that Agile is all about trust. The problem is, that many large organizations are not. MSF Agile helps with this by specifying more formal things as an architecture and formal reports.
These days it looks like that you have to be Agile to be a good developer. Agile is the magic word and everybody wants to "do it". The reason for this can be found in the failure of traditional methods, but I think also because of the fact that you can send a Big Design to a low cost country.
But altough many developers want to be Agile, a lot of (project) managers still think that putting two developers behind one computers will double the cost of their project. So developers are looking for ways to implement some agility in their projects and TDD and refactoring appear to be the #1 victims in this process. But because of the fact that they're "doing" agile in a mostly traditional environment these implementations are not quite what the founding fathers of the agile ways had in mind. They are becoming somewhat the victims of their own success and this is causing them to panic.
Yesterday I was reading a post by Paul Gielens, who was having a discussion with Frans Bouma about refactoring and the cost of it. These guys where talking about some real life scenario's in which most of us have to work these days. The discussion got picked up by the XP-group on Yahoo and was brought there by (INETA speaker) Sam Gentile. Looking down from his tower Sam saw that it was necessary to slam down the .NET community who were trying to drag and drop a faulty implementation of refactoring into their projects. After this Sam also complains about his hard life in a world with .NET. At the end, Sam makes a sort of excuse to Paul and Frans, but in my opinion the harm has already been done.
I do think that agile methodologies will help us to build better software in the end (although I have never seen a real life agile project). If the agile and XP communities want their methodologies picked up in the right way, they will have to do better than just telling us that we're all wrong. Rather than that, help us with ways to implement it gradually and gentile (sorry about that ;-) into our environments. Doing it all at once will not work/happen for 95% of the projects.
In one of my previous posts I wrote about the Essential Unified Process. This process framework, that is being developed by Ivar Jacobson for Microsoft, will be challenging RUP on one of it's big problems: the size of RUP. When using RUP you should always take a subset of it, suitable for your project. But because there is so much in RUP, people often use more than necessary making it less effective.
To solve this, IBM has developed the Rational Method Composer. The RMC will replace RUP as a product, but RUP will still be the process framework. The RMC comes with a set of out-of-the-box processes or delivery processes. There are processes for small, medium and large projects, COTS, systems engineering, service oriented architectures and maintenance. This will make RUP much more accessible than before and back in competition with MSF or EUP. To support this the are plug-ins for multiple development environments, including .NET.
The sad thing is, that there will probably less competition than before. IBM has donated about 15% of the RUP to the Eclipse Foundation to stimulate a vivid involvement of the (Java) open source community. This part of RUP will be called the Eclipse Process Framework. And although the EPF is meant to be cross platform (both Java and .NET) it will probably be not. It's most likely that the majority of Java developers will be using RMC/EPF and .NET developers MSF/EUP.
While there is nothing wrong with MSF, I think the Java developers might be better of in the long run. Microsoft will most likely thighten the relationship between process and tools and can freely do so, because it controls both of them. This again will give them more control and reduce competition. I like the new Team System and Team Foundation Server very much, but I do not think that this is a good thing. More than 15 companies will contribute to the Eclipse Process Framework giving it a broad basis for future development.
Read more on:
http://www-128.ibm.com/developerworks/rational/library/nov05/kroll/index.html
http://www.javaworld.com/javaworld/jw-10-2005/jw-1017-idgns-eclipse.html