I am first and foremost an agile guy. I try to be as agile as possible at my assignments, and I coach and teach agile ways. But I know that there still are several companies that use RUP, and this is written for them.
As I argued in my previous blog post, you can do RUP and be agile. In this blog post, I will give you my top 3 RUP anti-patterns that I have experienced at various projects, and often enough the solution to them is to work in a more iterative way as the creators of RUP intended (more agile if you like). If you want to know what you can do about them, read on. If you can top them, please share your experiences with me 🙂
I was hired as a software architect back in -98 in a RUP project. That project was very well staffed with an experienced process mentor, and a very experienced system analyst (requirements specifier). But we struggled anyway to explain to the project what RUP meant with that “only the most critical Use Cases should be outlined at the end of Inception”. How the heck do we know which ones are most critical? So we added more iterations to the Inception-phase in order to have more time to be really sure that we had found all Use Cases. But we were never really sure, and Inception just got longer and longer.
The bronze medal goes to – Anti-pattern #3: The inception phase just drags on and on as the Project tries to find every possible requirement. Aka “analysis-paralysis”.
This leads of course to a more waterfallish implementation of RUP. So the more agile way would be to think of the work with finding the initial Use Cases in the same way as you do when you create the initial Product Backlog in a Scrum-project. When you have had a couple of meetings with the stakeholders you just stop for a while and let the team look at what you got and start a discussion about what the Use-Cases and Actors actually mean and do. After a while (a couple of round-trips of talking to the stakeholders and letting the team discuss) some of the Use-Cases will have been mentioned more than others. Those are potentially critical.
Now, to attack the problem from another angle, what does a “critical Use-Case” mean? Think of it this way. In the next phase, Elaboration, you are supposed to establish an architecture. To do that you need to start building software, preferably by implementing some requirements. In order to get a feeling for your architecture, you need to build something that goes through your architecture’s logical layers and exposes your quality attributes. A walking skeleton as some call it nowadays. So one or more Use-Cases that does that are most likely “critical”.
A third way of looking at it: starting to build something as soon as possible addresses your technical risks. But do not forget the business value to your stakeholders. So a truly critical Use-Case has high technical risk and high business value. If you don’t have that, technical risk is more important than business value (in the beginning mind you!). So choose from those Use-Cases that have the highest technical risk and as high business value as possible.
One way of categorize the Use-Cases is to map them out in a diagram, where you have technical risk on one axis, and business value on the other. Now that you have found one or maybe a couple of critical Use-Cases, just stop the Inception-phase. Yes, just stop. Finish up the iteration you are in by establishing the other artifacts, then stop. You must get in to Elaboration phase, i.e start building software as soon as possible!
Just last year, I held a presentation about RUP for a team at a large firm here in Stockholm, Sweden. RUP was the process they were supposed to follow, but they were a bit lost as they had different views on what to do. The Project Manager (a consultant) popped in and out during the day. At one point we discussed how many iterations there should be in each phase. The Project Manager then appeared in the room again and stated that “We already know this. I have written it in the Project Plan. We are going to have one iteration in Inception, one in Elaboration, three in Construction and one in Transition”. Oh my!
The runner up is – Anti-pattern #2: The Project Manager (or the Project Manager and his closest team) creates the plan for the whole project, number of iterations and everything, on beforehand.
This anti-pattern easily leads to several other anti-patterns: command and control (Project Manager makes a gantt-chart and starts handing out activities), not getting team buy-in (as the Project Manager makes all planning by himself) and fixed time and scope. But most importantly, it is just plain wrong. And that goes for all kind of projects, regardless of development process. Back in 1981 Barry Boehm drew what later became known as the “Cone of Uncertainty”, which tries to explain how little we know in the beginning of a project. Surely, we have learnt since then?
So, now time for the winner! I am not sure this is the worst anti-pattern, but it is the one that I have seen the most, by far.
The winner is – Anti-pattern #1: “Oh, I do not know what all of these artifacts are, I’d better do them all…”
Yes, here it is again. And I am convinced it is this anti-pattern that has given RUP the bad reputation of being a heavy-weight development process. And no, it is not true. You do not have to do all artifacts, or use all roles described in RUP. You are supposed to pick and choose the parts you need for your project/system being developed. It says so in RUP, it says so in the books describing RUP, and still, it is seldom done.
Companies being large enough to have an organizational unit called “Process Development” or “Process Support” or something similar, normally falls into the trap of trying to make some kind of standard template for small, medium and large projects. Three templates that stipulate the roles and/or artifacts that should be used and developed. Well this is slightly better, but still not good. Every project must do the picking and choosing by itself, because of the simple fact that there are not two projects alike.
Yes, of course, if there is a company policy, or even laws regulating that certain artifacts must be produced, your project have to do it. But I am sure that there are other artifacts that can be overlooked. And make sure that you revise these decisions during the project.
That’s it. These are my top three RUP anti-patterns. If you think you have worse, tell me!
In the next blog post in this series on RUP, I will try to explain how to be more agile with RUP, maybe as a step towards moving to agile altogether.
I encourage you to comment to this blog post if you have any questions concerning RUP and/or agile and how to combine them, or to email me, and I will answer to the best of my knowledge.
5 responses on “(My) top 3 RUP anti-patterns”
Great post, only one build: is the thing to really worry about: having a culture of blindly following the rules (ie do what we always do, create all the docs, 1x iteration per phase, etc) rather than deliberately thinking about what really adds value and focussing on doing only those things ?
Hi John! I guess your suggestion is more like a root cause analysis on the others. I reckon, leaving root causes out, one of the top anti-patterns must be ‘Declaring that you have completed Elaboration without having written any software, but with a huge pile of Use Case Descriptions and UML’.
Pete, Good point!
Agree. I fell for this one once on a project that was passed to me some months after it started. Very painful all round. It nearly cost me my job.
The consequence was that while the schedule said we should have been churning out code, we were in fact still working out how it would all fit together. PM was very frustrated, rightly so.