Archive for RUP

how – not – to make a process work for you

Anti patternGary Pollice (“I’m the one with the head”) publised an interesting article on anti-patterns for process adoption in the Rational Edge.

At Getronics in the Netherlands we’re in the middle of adopting our process. We first documented our RUP-based “Getronics Development Process” using IBM Rational Method Composer. We documented some additions and our Getronics best practices and were appraised at CMMI level 2 last December. Now we’re rolling out the process and are facing two views on the way to go ahead.

One group wants to keep moving and go for CMMI level 3 right on. An other group wants to first take all our energy to get level 2 rolled out first, before moving on.

Reading the article from Gary, I would say we’re hitting the “Take all the medicine at once” anti-pattern if we try to move on to level 3 right away. In short, the antipattern says process changes take time, so it is better not to do everything all at once, but to do small process improvements at a time. For our situation, that would mean it is wise to roll out level 2 first!

BookMore anti-patterns can be found in Organizational Patterns of Agile Software Development. Gary Pollice did a review of the book, another review is at slashdot.org.

Leave a Comment

Some additions to a complete list …

Miguel Carrasco published The Complete List of Software Development Frameworks, Process’s, Methods, or Philosophies.

As with all complete lists, being complete is hard.

Some commonly used alternatives are the Enterprise Unified Process and the Microsoft Solution Framework.

Leave a Comment

RUP related

To catch up with newer posts, here are some subjects that were on my to do list, all having to do with RUP:

Project Management with the IBM Rational Unified Process РLessons from the Trenches by R. Dennis Gibbs.  Should be especially interesting if you are involved in managing an outsourced project with RUP.

Extending RUP with the Portfolio Management Discipline by Scott W. Ambler, John Nalbone, and Michael Vizdos (the guys from EUP).

Integrating the Rational Unified Process with Managing Successful Programmes, by Russel Norlund.

Leave a Comment

Data Warehouse Project Management

Hari Mailvaganam developed a Data Warehouse Project Management methodology that ties in with the Rational Unified Process (RUP). This is especially useful if the data warehousing project is part of a greater development effort which follows RUP.

In this post he lists the activities performed in the RUP phases.

Leave a Comment

The full feedback effects

I often discuss the benefits of iterative development with collegues and students.

A key benefit (THE key benefit for me) is that you can incorporate your lessons learned from one iteration right into your next iteration, thus continuously improving your process . That is, if you truly plan your evaluation and kick-off sessions at the beginning and the end of your iteration.

If evaluation leads to the discovery that in your project, you spend lots of time on bugfixing due to inadequate requirements documents, you might want to change your requirements process (and suggestions for making it better may come right out of the evaluation) and use your better process (and spend less time bugfixing) in the next iterations. When you evaluate the use of the improved process next iteration, you get the full feedback effects into your project: project members actually see that problems are tackled, solutions are discussed and improvement is measured.

I thought about this when I read a post from Roger Cauvin. Cauvin disagreed with Scott Sehlhorst who stated:

There is nothing that prevents a waterfall project from reviewing
estimates throughout the course of the project.

Cauvin replied:

With waterfall, you certainly can review and adjust estimates halfway through
the process, but you will not be able to incorporate the full feedback
effects.

I agree with Cauvin on this one. If you discover during the evaluation that the estimates given by your team are bad, you can evaluate why that is so, and change the estimation process immediately. Team members can thus improve their estimation skills in the course of the project, whereas in a waterfall process, the can improve their estimation skills in the next project!

Leave a Comment