At our company we have these meetings, where people from the same competence in a region come together to talk about all kinds of stuff, from business related to more fun related stuff. Because I went to the Dutch Developer Days 2005 with Edwin Waegemakers, we were asked to do a little presentation. We decided to give three small presentations, one about Team System, one about integration strategy and one about Agile Development. I would do first and last.
I've written about the Agile presentation at DevDays before and planned to use it in my own presentation, but a little less on the archetypes and a little more my personal experience. The plan was to bring it lightly and at the same time trigger our RUP 'specialists' as an Agile hooligan, and I can say it worked pretty well. I placed Agile strongly against RUP, although in practice this of course isn't the case. Or at least not as hard as I had put it.
Agile vs. RUPFor a lot of developers documentation can be a drag to write. I have a personal experience on a project I joined, where they over-used RUP. Normally you get a pile of documentation of about 2" high. On the project, I got a pile of about 10" high. If I wanted to read that through, before actually doing something useful. The project had just started, and there wasn't anything in it like functional specs. Just project guidelines and rules and technical visions, etc, etc, etc. So I used that in the presentation, with the Agile tenet to produce working software over extensive documentation. I highlighted extensive, as some people got the idea Agile has no documentation at all. That triggered some reactions!
Fun thing was, that our director just had seen a presentation last week, where RUP was presented as thé answer to all problems in projects, sort of speak. This week I presented it as if RUP was about just documentation, and Agile development would really work. His conclusion was that now he knows he's getting old, as he had never seen (technological) advancements update so fast. Last week RUP was everything, now it's already outdated and replaced. ;-)
Project swingOf course Agile isn't a replacement for RUP and you cannot appoint one as a clear winner. I don't think that's necessary either. I think RUP is great, but you have to have experienced people doing RUP projects as you don't want to overload everyone with documentation, but also have to carefully look at what the customer wants. RUP also uses iterations, but for some reason I have the feeling Agile development can better understand and react to what the customers needs, not what he thinks he wants. That comes to show in this funny picture of a swing. It's funny to see how everyone within a project has (or can have) a different view on the swing. I think it's hard to get the same swing in every picture. But my believe is, it's much harder to retrieve from a customer to what he really wants and needs. To get the same picture in how a customer explains it and what a customer really needed, you need good iterations and a lot of communication. For some reason, I have the feeling communication in RUP is more through documents where as in Agile it's face to face communcation between the customer and the entire team. And I think that's an important difference.
Of course everything should still be managed, also documentation. ;-)I'm particullary interested in how to manage the customer and/or final deadline. Once the customer gets the hang of changing and adding functionality, how can we manage them and the project so that we can deliver what we promised up front, and still meet some final deadline. Where is the line, between making agreements with a customer, and kind of just see what happens?
For those who want to know more about Agile Development :
hiho,
The branded Rational Unified Process provides a ton of artifacts that a team can use when developing software. And there is little talk on collaboration or even how people are expected to work together. The early version of SPEM (the Software Process Engineering Metamodel from the Object Management Group) used to describe the process leads one to think of a situation where "I do task X alone and create artifact A, you then pick up artifact A and do task Y alone which produces artifact B, then someone else...".
That is not how it has to go, but the content provided by that version of the Unified Process can lead people to think of it that way.
A group of people have been authoring an open source version of the Unified Process that takes an agile perspective. It has the end-to-end process structure recognizable from the Unified Process. It treats it as lightweight as possible. It includes guidance on various collaborative and other humanistic perspectives of developing a system. It includes roles for the sake of defining required skills, but does not have a strict perspective on roles or top-down tasking (i.e. promotes self-organizing teams). It folds in various agile techniques such as TDD, Refactoring, Continuous Integration, and even applies a Scrum-like technique for project planning.
You can download it at http://www.eclipse.org/epf/ of view the 0.9 version of it published at http://www.numbersix.com/openup/.
------- b
The following is very well said by the Author. I totally agree with that.
"For some reason, I have the feeling communication in RUP is more through documents where as in Agile it's face to face communcation between the customer and the entire team. And I think that's an important difference"