Plan Driven vs Value Driven Development

Рет қаралды 22,081

6 жыл бұрын

As part of the Scrum Tapas video series, Professional Scrum Trainer Punit Doshi discusses the difference between having your entire schedule driven by plans that are create at the beginning of a project vs defining the plans on a Sprint by Sprint basis to help ensure that you are always focused on the delivery of value by learning and adapting as you go.

Пікірлер: 15

@baymax142 4 жыл бұрын

Best explanation so far. Love how you just simply broke it down and clarify everything

@routetochange575 2 жыл бұрын

Straight to the point. Very valuable!

@EnricoPezzini 6 жыл бұрын

Simply explanation, so good to see something I can share with my boss hoping he sees the same things I saw

@himanshunayak459 3 жыл бұрын

simple and easy to understand, thanks.

@HUPetra 4 жыл бұрын

Thank you for the explanation!

@abhijitv 6 жыл бұрын

Awesome Video ! thanks

@omerhatim4326 Жыл бұрын

Great Thanks

@AbhishekTakate 2 жыл бұрын

Thanks

@rohitkanade146 2 жыл бұрын

what is the example of value driven module

@punitdoshi2855 2 жыл бұрын

Scrum framework is a good example for Value driven delivery.

@rohitkanade146 2 жыл бұрын

v-model comes under which model?

@punitdoshi2855 2 жыл бұрын

Value driven model will come under Agile approach to delivery. Scrum is a solid framework that enables value delivery. Hope this helps :-)

@rohitkanade5420 2 жыл бұрын

So, V model is also come under value driven model right?

@Aksamsons Жыл бұрын

@@rohitkanade5420 No V-Model (v=verification model) is similar to Waterfall not Agile, it is sequential as I understand it, with the feedback loop at the end of delivery. Therefore it would come under the plan driven model.

@FrankRiedijk_NL Жыл бұрын

Hmmmm….. I tend to disagree with your arguments. The essential difference in your description of the left model and the right model is not “plan vs iterations”, it’s that the customer is apparantly aware of the flexibility of requirements in the right model, where the customer seems to expect everything fixed in the left model. In the left model you would have the customer invest all effort into requirements refinement “at once” or at least “before the creation-efforts”, where the customer would be available for decisions during the creation-efforts in the right model; during iterations/sprints. There is no other reason why the left model could not also deliver intermediate business results as part of the plan. I still run into situations where a customer wants to know the full price of a system-creation or replacement up front. When you argue that requirements are “to be discovered” they will not understand and demand a (nearly) fixed price (particularly when you replace a system the customer would argue that all requirements are known, or at least 90%). So I think that rather than blaming a “project plan” or “project management” of being the right way forward, I think the responsible team or manager should consider the level of customer understanding and build an approach based on that. I would argue that in both cases that would be a “planned approach”. Just my 10 cents.