L'Agilitateur - In English - Commentaires

The Time Dilation of an Ideal Day - oaz

oaz — Thu, 23 Nov 2006 22:22:06 +0100

"We know that such estimates are not really accurate"
And, anyway, most of the time we are not able to provide more accurate ones !

The Time Dilation of an Ideal Day - Avangel

Avangel — Sun, 19 Nov 2006 12:31:56 +0100

I really like this way of estimating with story points from your own time estimates.

The scale you propose is really interesting, for the reasons you explained, and in my opinion because we naturally think with those ranges : about an hour or two, half a day, one day, half a week, a week, or more.

We know that such estimates are not really accurate, but the story points are tolerant to small variations, while providing a reliable basis for planning iterations. I think there is too many factors that we can't predict, that can alterate your estimates; so let's take a small uncertainty in estimates, that allows us to face such events without breaking drastically our plans.

To Fix or Not to Fix : That is the Question - Avangel

Avangel — Wed, 14 Jun 2006 12:08:16 +0200

I think such decision must be an agreement between customers and team, but with sufficient data to make the decision.

For example, team may says customers : "This bug is critical and may impact further functionnalities, but it will need quite a lot of time to fix". In such a cas, the product owner has the elements to take the decision.

Another case is "This bug makes this functionnality uncompleted, and it will cost an average time to fix". In this case, the product owner may consider this functionnality is not important and the bug may be fixed later.

I think like any blocking case in an Agile projet, the main idea is that the team gives its technical view, the product owner has its business view, and then he takes its decision. In this way, we consider both technical and business constraints.

To Fix or Not to Fix : That is the Question - Laurent B.

Laurent B. — Tue, 13 Jun 2006 14:22:59 +0200

Je me permet de proposer un lien en rapport à ce billet instructif:
http://www.codinghorror.com...

Every Process is an Iterative Waterfall - Oaz

Oaz — Wed, 24 May 2006 17:13:32 +0200

I share your views regarding the "one size fits all". I'm usually a proponent of agile solutions but I sometimes play the "devil's advocate" when I think the RUP or even a waterfall is more appropriate.

Every Process is an Iterative Waterfall - Dave Nicolette

Dave Nicolette — Wed, 24 May 2006 14:44:09 +0200

Thank you for recommending those references. I see your point now about multiple iterations within a single RUP phase, and it makes sense.

I think that we, as an industry, are well served by having a range of alternatives for running projects and for managing long-term product development efforts. I am not a believer in a "one size fits all" approach to software development.

I like the final sentence in your recent comment. Very well said!

Every Process is an Iterative Waterfall - Oaz

Oaz — Tue, 23 May 2006 23:30:41 +0200

"I cannot say that I have seen a RUP project function in that way."
Maybe they were not RUP projects ?
Just have a look, for instance at http://www.ddj.com/dept/arc... by Scott Ambler or http://www.objectmentor.com... by Grady Booch and Robert C. Martin.
"Their" RUP clearly split a release into phases and phases into iterations.

That being said, I totally agree with your conclusion that I had, indeed, misunderstood : it does not make sense to run an agile iteration with four distinct phases. All the activities performed in an iteration must be run in parallel. The serial nature of a development process, materialized by the RUP phases, only makes sense at the macroscopic level : from a set of blurred expectations to a complete product.

Every Process is an Iterative Waterfall - Dave Nicolette

Dave Nicolette — Tue, 23 May 2006 18:30:38 +0200

>However, I do not subcribe to the RUP-bashing movement that seems to result from it.

I am happy to know you feel this way. However, you may have misinterpreted some portions of my article.

The article includes an excerpt from a piece by Sinan Si Alhir, one of the foremost advocates of RUP, that clearly explains how RUP can be used in an agile way. His diagram illustrates how the four RUP phases can be executed in parallel during the same iteration, in contrast to your statement that they are "phases of a release, and each of these phases contains one iteration or more." I cannot say that I have seen a RUP project function in that way. By the same token, I cannot deny that your organization uses RUP in that way. It is in the nature of adaptive methods that people adapt them.

To be clear, it is in the context of Alhir's model of agile development with RUP that I say the need for four distinct phases simply evaporates, since team members in all disciplines are already collaborating directly. Given that level of collaboration, there is no communication gap that must be address by formal transitions between phases.

You may be relieved to know that I am a strong advocate of RUP in situations where it fits. I consider it the most mature and best proven methodology for lean development. Although RUP can, in theory, be used for "pure" agile development as well, in practice it is not used that way for the reason I mentioned; there is simply no need for the formality of four phases.

If you are running an entire iteration for inception, followed by one or more iterations for elaboration, etc., then you are following a waterfall process but using RUP terminology. I believe that if you are doing this for good reason and you understand what you are doing, then there is no problem. I suspect we are slipping into the trap of arguing about the semantics of words instead of focusing on the meaning behind the words.

Just as RUP works very well when it is applied to the right problems, agile development (especially XP) works very well when it is applied to problems that call for its unique strengths. In those situations, a team can achieve the goals you list in a single iteration. You correctly say it is not an easy job, but I think you would be very pleased at the results achieved by a mature agile team.