L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Dave Nicolette raises concerns about organisations moving to agile development while appointing "traditionally-minded" managers. Risk #1 is that these managers turn the agile processes upside down by transforming them into a Staggered Iterative Waterfall as described by Kane Mar.
I deeply agree with the key statement of those articles : agility's main duty is improvement of interactions between individuals with the help of suitable processes. It is not about focusing on a well-polished process aimed at eliminating every possible waste in human activities. However, I do not subcribe to the RUP-bashing movement that seems to result from it.

It does not take a long time to realize that performing sequentially across consecutive iteration the analysis, design/coding and testing activities is a waste of opportunities. In the Staggered Iterative Waterfall pictured by Kane Mar, feedback that could happen inside an iteration takes three of them to arise.
Nevertheless, performing all the activities in the same iteration is not an easy job. For example, in an eXtreme Programming case :

• The iteration plan needs the user stories to be written and estimated before the iteration start (we have to know which stories fit into the iteration). As a consequence, the time spent by the customer to workout the story must be shortened to its minimum. Every minute spent writing a story without interacting with the developers is a loss of feedback.


• The customer tests must be run after (and also before) the iteration deliverable is built but before the iteration is over. This implies that customer tests are heavily automated and written as soon as coding starts. Failing to do so means that developers will not be able to produce value while the deliverable candidate is tested.

It is not an easy job but great teams can certainly achieve it to a certain extent.

The question is : can they fully achieve it ?
Obviously not.

In most projects, the best on-site customer (or group of on-site customers) cannot stay on the playground full time and simultaneously being fully aware the underlying customer activities. These on-site customers must be as close as possible to the development team but they have to stay in touch with their own businesses.
The problem is that you cannot put the whole world into a single room.
This is the reason why the stories describing the customer business need to be partly written off-site in an high level analysis activity. This is the reason why the the customer tests cannot be fully written while designing the system. The deliverable must be checked against some off-site exploratory testing activities involving other users.

The combination of those two activities with the software system development enhances the ability of the customer to think about her business process in a true iterative waterfall.
Maybe we can call that "Iterative Business Process Modeling". I'm far from being a BPM expert (just started reading stuff on that subject) but, intuitively, it looks like a good name.
The idea is that two processes, ran on each side, can reinforce each other. Feedback from the real user activity helps the developers to build the expected system while feedback from a delivered system helps real users to think about the way they work.

When going through the iterations, this process can be pictured as following.
The core system development activities are performed in each iteration with agile interactions between individuals at their peak.
 

Now let's have a look at the RUP-bashing thing.
The four phases of a RUP iteration look like a miniature waterfall: Inception, Elaboration, Construction, and Transition. [...] The reason RUP is used for iterative waterfall processes and not for agile processes is simply that it is unnecessary in a true agile process; its four phases become unproductive administrative overhead.

So the point is that RUP does not work for agile processes. I could just argue that "If you cannot run a RUP framework in an agile mode then you're not running a RUP framework" but I do not like this kind of extremism.
It looks like there's a big misundertanding regarding the RUP phases. Inception, Elaboration, Construction and Transition are not performed inside a single iteration. They are the phases of a release and each of these phases contains one iteration or more. Inside an iteration, you can do strict Waterfall, you can perform a V-shape or you can blend all the activities in the agile way. You could overlap the iterations but this is considered as a RUP Anti-pattern. It is advisable to do frequent reviews and have multi-skilled teams. Both of them are agile practices.
The RUP phases are the "macroscopic tempo". In a simplistic view of an agile instanciation of RUP, the inception phase is merely the first draft of user stories before development begins. The elaboration phase shows an important milestone : when it is over, the team considers that every "major" user story is implemented. The vision is established and the risk of a project failure is now lowered. The construction phase is about polishing the system until every customer need is implemented. The transition phase hands over the application to the users.

RUP is not inherently less agile than methodologies known for their agility. It is just a matter of usage. Its versatile nature support iterative waterfall processes including a bit of administrative tasks that inevitably happen in the real life with its natural time and space boudaries. Hence, one could even argue that RUP is more able to cope with human concerns than strict methodologies.