Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Shenbagaraman, is it really a defining characteristic of a turnkey project that it have a detailed plan? I suspect that if you check your definitions, you'll find that "turnkey" means that it can be sold to the customer as a completed product. So the customer is interested more in the final product you are delivering to him, and less in how you get there. Of all project types, this is perhaps the one that is least likely to involve the customer in its detailed planning.
I agree with Ashok - I don't think there is any reason you couldn't choose an agile delivery model for a turnkey product. You just might not get the customer involved as Product Owner, that's all, and would probably have to have one of your own staff perform that role. Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Francisco, we should talk about timeboxing. There is no need whatsoever, even if timeboxing, to deliver an incomplete product to the customer at the end of an early iteration if that would be of no value to him. Doing iterations that result in a "shippable" product doesn't mean there is any obligation to actually ship it, if it wouldn't provide any value to your customer.
Some customers would, it's true, only be interested in a single "final" delivery of the complete product. But that's not an argument against timeboxing itself or against iterations in your development plan. Having timeboxed iterations gives you more control of, and visibility into, your development as it proceeds, so it gives you a better chance of finding and correcting mistakes before the day of final delivery arrives.
Iterations are fundamental to agile methods. While it might on occasion be possible to deliver a product in a single iteration, it is normal, and indeed it is a defining characterictic of agile methods, that you have mulitple shorter iterations within a longer development effort. If you don't, you are giving up some of the biggest benefits of following the agile method. Saving Changes...
The question is very broad and cannot be explained in a few words. If you want to implement agile in your project and you don't know agile, please get trained in or hire an expert from the market. I sorry to put it this way. Saving Changes...
Francisco AbreuPortfolio Manager| Banco Central do BasilBrasilia, Df, Brazil
Alistair. My arguments:
Your own words: Iterations are fundamental in Agile.
Interactions MUST BE. Timebox not. Your arguments have not defended timeboxing, they talk about interactions.
I complete: Interactions are some part of project perceived by user. It hasn’t project team’s finality.
Example: One IT project predicts one screen with five buttons where each one has it own functionality. At the timebox’s final date only four functionalities are OK.
Do you deliver this interaction to your client without the fifth functionality or you negotiate new date to finish that scope.
In this situation, this interaction has no sense to me.
Resuming: We deliver SCOPE not TIME when we are in IT projects.
Saving Changes...
Francisco AbreuPortfolio Manager| Banco Central do BasilBrasilia, Df, Brazil
Ashok Gupta. My considerations:
If you are able to divide your project in five interactions with 4 weeks each one, you planned all work in detailed way.
Agile advocate you don’t need to plan all work to start your project.
This is my first doubt about pure agile adoption.
In your example, you don’t using Agile. You is using “five little cascade” . . . kkk…
If "you can start creating a backlog. . . rough estimate... ” you can’t tell each interaction will be 4 weeks each. Do you sign one contract in this scenario?
Other problem: At the final the ITR1, you need one more week to finish all work.
What do you do? You start the ITR2 with additional scope? You delay ITR1 to finish it? You start a negotiation requiring plus money to that new week?
If you start by backlog, you don’t full vision about all work to be done. The risk to over budget that 1.000 is very high. Who pays for that?
I haven’t all responses for these questions and I don’t see answers in Agile, too.
Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
You're right Francesco, I didn't explicitly address timeboxing. Nevertheless, most people believe that iterations should be timeboxed, and that to allow them to be variable lengths sacrifices some of their benefits.If you want to discuss specifically the arguments for and against timeboxed iterations, perhaps that would be better done in another thread.
To take your example of a user story with five buttons though: if it is a single user story, then it is not complete with only four buttons, and does not meet the definition of done, so you would not deliver it at all at the end of the iteration. You say delivering four out of five buttons makes no sense to you. Well it doesn't make sense to me either, if the five buttons are closely coupled in terms of functionality and business value, and must be delivered together to have value to the customer.
Better might be to break the one story up into up to 5 individual stories, one for each button, if it makes sense to do so. You would then be able to deliver 4 completed stories at the end of your iteration, while one remains undone, and will be scheduled for inclusion in a future iteration. This is normal backlog grooming and capacity management, and is the sort of adjustment that product owners make to iteration plans all the time. Saving Changes...
