Found this video very informative, Related to using the boards and signs go to 44:41 (Mins:Secs) Related to Sprint Planning and Story points go to 01:02:52 (Hrs:Mins:Secs) Related to Best Practice and common traps go to 01:12:49 (Hrs:Mins:Secs)
Thank you so much for the wonderful video! Really nicely compiled and structured. Very to the point, and at the same time comprehensive while keeping it short enough! This is the sign of a highly experienced person that has developed useful insights and has done good amount of thinking on these topics.
Incredibly helpful. So well done. I passed this morning and you helped me get there. This video was just what I needed to wrap my head around the Agile approach. Thank you!
Found it very informative. I am just now stepping into this discipline and found this video of much value in helping to increase my understanding of the concepts. I am more prepared now to start moving into targeted study.
Very well covered...a lot of preparation must have gone into compilation of the entire course material with all its contents...appreciate and thank-you very much...looking forward for more videos on project management in general and agile related in particular...wishing the very best..
Het gebeurt niet veel dat ik een video kan uitkijken, maar deze lecture was echt interessant. Super werk! Was enorm hulpvol. Groetjes vanuit België :-)
Great video. I have few questions 1. Who should bear the cost of re-working of items 2 or more times when they has been originally been fixed. It is fixed, UAT is done and the user find out it was fixed incorrectly and the scrum team goes to fix again and sometimes , UAT finds it was done incorrectly again . This was not due to requirements understanding but just repetitive errors by the scrum team. Who should bear this cost? Client or Software developer? 2. Just want to find out, where is the place of detailed demo of the sprint product? not sure it was mentioned. Thanks.
This was a healthy amount of information. There was much gained. I was concerned that this was affording the overall lesson to a Scrum Master rather than a Product Manager. I do want to offer critique that it didn't look at colocated team practices, how to better estimate backlog release. Other than this, I enjoyed your presentation and the videos were helpful too. Thank you.
As an introduction to lots of new concepts, this is really well structured. I was a bit surprised to see your use of old world reports as this may signal to leadership that nothing has really changed and they can expect their weekly RAG status report as normal - that doesn't feel very transformational
You are correct. There is no need for daily standup. The point was to get people used to communicating and helping each other. Standing up was to make the meeting painful to go longer than 15 minutes. You can communicate other ways without any meetings.
Estimating using hours is not a recommended Scrum Practice. If you want to know how long your product is going to take to ship, use Velocity Based Planning. Estimate all the MVF's (Minimum Viable Features) in your backlog using story points (you can use Affinity Estimation for a large backlog). Then pull a certain number of these features into the first sprint, others into the second sprint, and so on until you've completed three sprints. This will give you an average number of story points you can complete per sprint. You can use this to estimate how long it will take you to deliver the MVF's on your backlog
The Introduction to Scrum video is very poor. It is a poor representation of Scrum when it describes the roles, the release backlog, user stories, project being behind schedule, etc. I suggest finding a better video for future Intro to Agile sessions.
You start off with a wrong or misinformed premise about the scope versus budget and schedule. Scope always drives the budget and schedule. The bigger a building you want to build the more money and time it will take, basic commonsense. If your budget/schedule does not permit it you build a smaller one. Waterfall or Agile has no control over the scope versus budget/schedule relationship. Secondly you are wrong about the notion that Waterfall is a carved in stone approach where you entirely complete one phase before moving to the next, there being no need to revisit the earlier phases. That is now how it works in real world. In waterfall there is emphasis on putting 'MORE' thought upfront (measure twice cut once, who would disagree with that one?) which means gather as many requirements as possible (not 100%, never possible) and do as much design upfront as possible to lend flexibility and robustness so that future new/changed requirements can be easily incorporated without having to tear down and build allover again. The initial design is followed by coding for the set of requirements which have been finalized while others are still being worked on. Testing starts as soon a small set of testable modules are coded. When additional requirements are finalized the earlier code/design is revisited and remedied but the impact is much lower because enough 'UPFRONT THOUGHT' has been put in for a flexible design. The Coding, Testing, Requirements tasks do overlap. In real world this is how Waterfall works, anyone who thinks otherwise has really not worked in large projects. The Agile methodology works for small simple projects where quality is secondary to quick delivery and the value of 'sound design' is under appreciated or the requirement changes down the road do not have much impact on the earlier pieces. Examples would be simple websites, apps for watches, Chat bots etc. that can be built the agile way because they lack complexity. Try building a complex software like stock trading systems or airline reservation system using Agile, it will be a fool's errand, there is no substitute for lot of upfront requirements freezing and sound design. I have seen complex projects start off as Agile and ultimately turn into more of a waterfall approach as the folly was realized of not putting enough upfront thought into requirements and design. There is no such thing is pure Waterfall or pure Agile, "Commonsense and Experience" is the most important project management requirement. Agile is over hyped.
You're wrong on your first point: the point is instead of thinking what you want and then seeing how your resources will do it, you look at your resources and decide what you can reasonably expect. You kind of state that in your comment as well confusingly. In your second point, if that isn't how it works in real world why not come up with a concept that reflects that - the agile concept for example. So I would say you're wrong again there. For your third paragraph: te point is planning is based on assumption whereas real life is based on the truth. You can plan for three years and then realise your first assumption is wrong and it was all a waste of time. Better to find out. In a situation where there's a box turned upside down - is it better to suppose what could be under there until eventually every possibility is considered or just turn it over. This whole concept is to avoid waste: both of time and resources. Often what works best isn't what you thought, and sometimes what you think is your USP no one is interested in. The best way is to 'test' not to 'plan'. If you test you know. If you plan you think and are really not much further along than where you started. I would recommend you read a book called lean start-up. Be comfortable with iteration to perfection over planning to get it right first time - the latter rarely happens. If you don't think complex things can be built agile and through iteration > planning check out the story of dyson's vacuum.
I agree and greatly appreciate with your views on Waterfall (which is commonly abused these days in many ways) and the relativity between budget and scope. But I do not agree with your views on Agile. Not at all!! I have been developing enterprise level websites (some pretty critical as well) and apps using agile for years now. And they worked out great this way. If you talk about products, Agile is better suited for enterprise level products as well. I believe you might have misunderstood the concept of Agility in software development. It almost always begins with developing a less complex prototype and eventually develops into extremely complex product/application through multiple sprints. Not saying that upfront thoughts are not put/required in agile process.These are rather a continuous process in Agile.
@@justarandomguy8989 It is plainly wrong to plan upfront and then to assume that this plan can be executed. This is rigid thinking. Planning means thinking upfront and foreseeing. We all know that planning is based upon assumptions, intellectual work is hard to estimate, situation may change, estimations are imprecise, etc.. So, one plans upfront, then the plan is used for execution. As the execution progresses, the plan is reviewed. If there is a discrepancy between plan and execution, either the execution and amount of resources are adapted to the plan, or the plan is adapted. Yes! The plan can and should be adapted when necessary. It's a living thing... also in Waterfall!!
Poor, poor, poor, there is no value comparing waterfall with agile, a real professional will focus on the body of knowledge, waterfall will suit some projects, agile definitely in a development assignment. What about rolling wave ? Why do 40% of agile projects fail? The Agile manifesto was not new or original, another content free agile propaganda video.
The sad thing is that Waterfall is badly understood and badly applied by rigid minds and agilists. For example, there is no standard of Waterfall saying that one phase has to be completed before starting another or that no analysis or programming activities may occur during a design phase. A methodology, by nature, only suggests and does never impose possibilities. It's just a template that has to be adapted to the project. The decision and responsibility for the execution remain in the hands of the team.
@@axelvanhooren6325 Hi, agreed, assess the need before the solution. I have seen a number of Agile evangelists have dissenters fired then shoehorn in Agile "delivery" regardless of need.
This is the best breakdown of Agile vs. Waterfall and more that I have found. Kudos!
This is one of hte best videos I ever saw. I would like to give a standing ovation, if I were present physically
Excellent Video. Very crisp and clear. Hats off.
Found this video very informative,
Related to using the boards and signs go to 44:41 (Mins:Secs)
Related to Sprint Planning and Story points go to 01:02:52 (Hrs:Mins:Secs)
Related to Best Practice and common traps go to 01:12:49 (Hrs:Mins:Secs)
Awesome presentation! I cracked my job interview because of this video and the information will be useful in my work too. Thank you for uploading.
Best video on scrum and agile concepts!
Well done Mr DuPont, I enjoyed your session. Thank you
I love how the topics are structured. I just learned about Kanban here - and ooh that in progress limit is ingenious. Makes sense!
Thank you so much for the wonderful video! Really nicely compiled and structured. Very to the point, and at the same time comprehensive while keeping it short enough! This is the sign of a highly experienced person that has developed useful insights and has done good amount of thinking on these topics.
Very knowledgeable...thanks for the presentation. Great job
Incredibly helpful. So well done. I passed this morning and you helped me get there. This video was just what I needed to wrap my head around the Agile approach. Thank you!
Found it very informative. I am just now stepping into this discipline and found this video of much value in helping to increase my understanding of the concepts. I am more prepared now to start moving into targeted study.
Very well covered...a lot of preparation must have gone into compilation of the entire course material with all its contents...appreciate and thank-you very much...looking forward for more videos on project management in general and agile related in particular...wishing the very best..
Het gebeurt niet veel dat ik een video kan uitkijken, maar deze lecture was echt interessant. Super werk! Was enorm hulpvol. Groetjes vanuit België :-)
Great video. I have few questions
1. Who should bear the cost of re-working of items 2 or more times when they has been originally been fixed. It is fixed, UAT is done and the user find out it was fixed incorrectly and the scrum team goes to fix again and sometimes , UAT finds it was done incorrectly again .
This was not due to requirements understanding but just repetitive errors by the scrum team. Who should bear this cost? Client or Software developer?
2. Just want to find out, where is the place of detailed demo of the sprint product? not sure it was mentioned.
Thanks.
It was very valuable presentation .Thanks
Glad you liked it
This was a healthy amount of information. There was much gained. I was concerned that this was affording the overall lesson to a Scrum Master rather than a Product Manager. I do want to offer critique that it didn't look at colocated team practices, how to better estimate backlog release. Other than this, I enjoyed your presentation and the videos were helpful too. Thank you.
Very basic information on Agile ,scrum and kanban .. Videos are excellent on implementation.
Hi.
Is the printout of the material available?
Very informative presentation
Even though I can go along with the "rc max" comment I think this is a very well structured and overall compelling presentation. Good job Martin
Thank u for great presentation can u please share the slides ??
We found this challenging to implement now that my team are all working from home.
Any recomendations or tips for us please. Thanks.
I like the best practice section. the slice titled Common traps with Spring Planning is very useful.
A good detailed explanation...I am going to share with our team.
Thanks a lot very informative and concise.
Great presentation! How can I get the presentation? On powerpoint or else?
Great job. Thank you so much
Glad it was helpful!
As an introduction to lots of new concepts, this is really well structured. I was a bit surprised to see your use of old world reports as this may signal to leadership that nothing has really changed and they can expect their weekly RAG status report as normal - that doesn't feel very transformational
Thanks great Job Mr Martin DUPONT
thank you so much for this video. very on point. Would like to watch more of your videos if there be more
Excellent video. Thank you
Marteen. Thank you so much for this Excellent video. You are ready for government work. We need to make America great again. The intelligent way. 🙏
I watched only the scrum part.
Very nice!
But 15 minutes scrum daily for 8 people as in 17:55 is kind of impossible
You are correct. There is no need for daily standup. The point was to get people used to communicating and helping each other. Standing up was to make the meeting painful to go longer than 15 minutes. You can communicate other ways without any meetings.
Mr. Mark Wahlberg did a great presentation here 👍👍
Great lecture!
Nice presentation
penjelasan yg tersusun rapi dan jelas serta disertai dengan contoh
Estimating using hours is not a recommended Scrum Practice. If you want to know how long your product is going to take to ship, use Velocity Based Planning. Estimate all the MVF's (Minimum Viable Features) in your backlog using story points (you can use Affinity Estimation for a large backlog). Then pull a certain number of these features into the first sprint, others into the second sprint, and so on until you've completed three sprints. This will give you an average number of story points you can complete per sprint. You can use this to estimate how long it will take you to deliver the MVF's on your backlog
The 1000 thumbs up are the blocker which impedes me to give u another one.
👍👍👍👍👍👍👍👍no.1
The Introduction to Scrum video is very poor. It is a poor representation of Scrum when it describes the roles, the release backlog, user stories, project being behind schedule, etc. I suggest finding a better video for future Intro to Agile sessions.
Great video!
I wish San Fran looked like that intro vid lololol
Messed up. Nothing clear.
mark wahlberg knows his shit
Just beat me to it!
@@deckydee ok
You start off with a wrong or misinformed premise about the scope versus budget and schedule. Scope always drives the budget and schedule. The bigger a building you want to build the more money and time it will take, basic commonsense. If your budget/schedule does not permit it you build a smaller one. Waterfall or Agile has no control over the scope versus budget/schedule relationship.
Secondly you are wrong about the notion that Waterfall is a carved in stone approach where you entirely complete one phase before moving to the next, there being no need to revisit the earlier phases. That is now how it works in real world.
In waterfall there is emphasis on putting 'MORE' thought upfront (measure twice cut once, who would disagree with that one?) which means gather as many requirements as possible (not 100%, never possible) and do as much design upfront as possible to lend flexibility and robustness so that future new/changed requirements can be easily incorporated without having to tear down and build allover again.
The initial design is followed by coding for the set of requirements which have been finalized while others are still being worked on. Testing starts as soon a small set of testable modules are coded. When additional requirements are finalized the earlier code/design is revisited and remedied but the impact is much lower because enough 'UPFRONT THOUGHT' has been put in for a flexible design. The Coding, Testing, Requirements tasks do overlap. In real world this is how Waterfall works, anyone who thinks otherwise has really not worked in large projects.
The Agile methodology works for small simple projects where quality is secondary to quick delivery and the value of 'sound design' is under appreciated or the requirement changes down the road do not have much impact on the earlier pieces. Examples would be simple websites, apps for watches, Chat bots etc. that can be built the agile way because they lack complexity. Try building a complex software like stock trading systems or airline reservation system using Agile, it will be a fool's errand, there is no substitute for lot of upfront requirements freezing and sound design. I have seen complex projects start off as Agile and ultimately turn into more of a waterfall approach as the folly was realized of not putting enough upfront thought into requirements and design.
There is no such thing is pure Waterfall or pure Agile, "Commonsense and Experience" is the most important project management requirement. Agile is over hyped.
You're wrong on your first point: the point is instead of thinking what you want and then seeing how your resources will do it, you look at your resources and decide what you can reasonably expect. You kind of state that in your comment as well confusingly.
In your second point, if that isn't how it works in real world why not come up with a concept that reflects that - the agile concept for example. So I would say you're wrong again there.
For your third paragraph: te point is planning is based on assumption whereas real life is based on the truth. You can plan for three years and then realise your first assumption is wrong and it was all a waste of time. Better to find out. In a situation where there's a box turned upside down - is it better to suppose what could be under there until eventually every possibility is considered or just turn it over.
This whole concept is to avoid waste: both of time and resources. Often what works best isn't what you thought, and sometimes what you think is your USP no one is interested in. The best way is to 'test' not to 'plan'. If you test you know. If you plan you think and are really not much further along than where you started.
I would recommend you read a book called lean start-up. Be comfortable with iteration to perfection over planning to get it right first time - the latter rarely happens.
If you don't think complex things can be built agile and through iteration > planning check out the story of dyson's vacuum.
I agree and greatly appreciate with your views on Waterfall (which is commonly abused these days in many ways) and the relativity between budget and scope.
But I do not agree with your views on Agile. Not at all!! I have been developing enterprise level websites (some pretty critical as well) and apps using agile for years now. And they worked out great this way. If you talk about products, Agile is better suited for enterprise level products as well. I believe you might have misunderstood the concept of Agility in software development. It almost always begins with developing a less complex prototype and eventually develops into extremely complex product/application through multiple sprints.
Not saying that upfront thoughts are not put/required in agile process.These are rather a continuous process in Agile.
@@justarandomguy8989 It is plainly wrong to plan upfront and then to assume that this plan can be executed. This is rigid thinking. Planning means thinking upfront and foreseeing. We all know that planning is based upon assumptions, intellectual work is hard to estimate, situation may change, estimations are imprecise, etc.. So, one plans upfront, then the plan is used for execution. As the execution progresses, the plan is reviewed. If there is a discrepancy between plan and execution, either the execution and amount of resources are adapted to the plan, or the plan is adapted. Yes! The plan can and should be adapted when necessary. It's a living thing... also in Waterfall!!
Video inside a video. Wow
In the first 4 minutes, there was nothing of value for me. Cut the blabla, present the information lean
Go Belgium :)
best video
Sup global citizens. Still derping over the interweb?
Brown Kenneth Taylor Dorothy Gonzalez Sandra
He or SHE!
20:45
Stupidly long intro
what is this bruuuuh
Fgh
Poor, poor, poor, there is no value comparing waterfall with agile, a real professional will focus on the body of knowledge, waterfall will suit some projects, agile definitely in a development assignment. What about rolling wave ? Why do 40% of agile projects fail? The Agile manifesto was not new or original, another content free agile propaganda video.
The sad thing is that Waterfall is badly understood and badly applied by rigid minds and agilists. For example, there is no standard of Waterfall saying that one phase has to be completed before starting another or that no analysis or programming activities may occur during a design phase. A methodology, by nature, only suggests and does never impose possibilities. It's just a template that has to be adapted to the project. The decision and responsibility for the execution remain in the hands of the team.
@@axelvanhooren6325 Hi, agreed, assess the need before the solution. I have seen a number of Agile evangelists have dissenters fired then shoehorn in Agile "delivery" regardless of need.