Rational Unified Process

http://www-306.ibm.com/software/awdtools/rup/
We had two presentations from RUP representatives. The first was a one hour session, the second a more detailed two hour presentation. Both times, I was more confused after the presentation than before. I also spoke to a number of friends that had worked with RUP and had positive things to say about the process.
The scope of RUP is extremely broad. It covers pretty much everything in the entire SDLC. This is both it’s strength and weakness. I was recently at a conference and attended a session by Phillipe Krutchen, one of the leading authorities on RUP. His view was that the main problem that arose when people tried using RUP is that they tried to use all of it. This is was the same advice that I got from my friends that had used RUP. It is large and sophisticated, the key is to use only the aspects of the process that you need for your project. This makes a lot of sense given that projects often vary and the same approach doesn’t always work.

However, given the context of our team, there were a number of issues with RUP. It is large, complex and sophisticated, our team was not, we had some people that were still learning about the SDLC and trying to introduce something as RUP would be extremely difficult and require lots of training

even though RUP is comprehensive, we would have to review it in depth to then decide which elements we would apply to our projects, trial and refine over timethe cost associated with the tools that were required to use RUP (eg. rational rose, requisite pro…etc) was high.

Overall, to implement RUP, or a scaled down version of RUP would have been a complex, difficult, time consuming and expensive process that had a high risk of failure.

Process Mentor

http://www.processmentor.com

We also got a presentation from a Process Mentor representative. The process itself was more compact than RUP and therefore easier to get one’s head around. In essence it was a website with a series of steps, forms and templates that could be used to run a project. We felt more comfortable with Process Mentor than RUP because is less overwhelming but it still wasn’t quite right. There wasn’t anything that stood out as a major issue as happened with RUP, but nor did it feel like the right approach.
 

In House Methodologies

As a part of the team, there were a number of experienced developers that had worked with “home grown” processes from previous jobs at a range of companies including heavyweights such as IBM GSA. We had each of these developers talk about their experiences, what worked, what they liked, what they’d use again. There were a number of techniques that sounded useful but the overall feeling was we weren’t going to be able to “borrow” one of these in house methodologies.