Dave, you are one of the rare guys on Internet who speaks clearly enough for the beginners in Agile to understand what that really is. Do you know anyone else who speaks that clear, simple and organized language like you, but goes deeper in telling about Agile and is available on internet to watch? I see you have only 2 videos about Agile, although I watched your other videos and saw you touching some aspects of Agile as well. Any suggestions? Greetings from Latvia
Andris, thank you for your kind words. We are continuing on with the series about Agile development and will release the next few installments in the coming weeks.
One reason for specification change requests from clients during development is that it's easier for someone to know what they want when they can look at something that's not quite what they want. The best tool I've found for checking a design or work process is to do a backward analysis. Look at the required output. Work backward through the logic to the beginning... the inputs and resources. When you understand it forward and backward, you'll have found most of the bugs and probably found ways to improve efficiency.
Hey Dave , very helpful understanding agile for beginners but need more, as I see many ppl have been waiting for the next video , when can we expect them to be released by plz ??
dammit... i hate it when i start a series of videos with promises of explaining things... then the series stops prematurely. Not the first i get caught... At least i didn't "invest" too much time into it... and i still got some well explained overview of the process.
Hi Holiephere Chee. Thanks for your feedback. We are getting so many requests/questions for new videos, it's been hard to keep up with the Agile series. It's actually been shot already and just needs to be edited. It will be soon, I'm sure! thanks, Dave
There are a lot of approaches, but ideally there will be QA before any story is accepted as 'done', yes. But, a bigger app will need proper testing/regressions to maintain stability and that's best done continually rather than just at the end.
Hi Dave, thanks for those videos, they are much appreciated. :) I understood you didn't had time to invest in this series anymore; do you still plan to release the part 3 ?
+Georgy Louis This question is answered in the comments of part #1, but I'll repeat the primary premise. Use whatever documentation is necessary- there is no set format. But, always favor communication and collaboration between team members over documentation when possible.
+SourceSeek It seems like you example assumes the client would be doing most of the testing. On a larger scale project with a dedicated quality assurance team, when do they become involved and how does that affect the documentation that must be kept (and continually updated due to the amount of change allowed)?
Hi Kyler - Great question, although it's hard to provide a simple answer. Regardless of who is testing, it's critical to make sure there is a bottleneck at the 'acceptance' phase, so that either the client or a pro QA team takes the time to test and validate the new changes. There are lots of ways to organize it, but it's key that someone is testing things after delivery, and maybe before release. This can happen per story, or per iteration but it's gotta happen. We could spend hours on the topic :) thanks for watching, Dave
Im trying to find simple small explanations for big daunting topics for a friend who wants to get into Digital QA - I'm very impressed at this series of videos I'll definitely send him a link to this. 5*
So as a 25-year veteran of classical project management, I see this Agile methodology as largely 'BS'. Anyone else agree? Let me explain. Agile tries to make itself into some 'fancy' methodology, when in fact, ALL projects have this iterative process, collaboration, etc. Maybe not in such short iterations but that's not because of 'Agile', that's just because software development can sometimes move faster than hardware development can. So I can see why people want to say it's mostly useful for software development, but that's only because software is just that...."soft"ware. So developing user interfaces, what this button does or that button, and showing it to the client as you are creating it only makes logical sense. But not sure why we have to wrap a fancy word around it, and create this Scrum Master term, and all these other names (e.g. sprints). I call it more 'common sense' methodology, and believe it or not, it also applies in waterfall methodology too. It's just design and development may take a bit longer (as it's not just coding), so 'sprints' are not necessary, nor relevant. But are there periodic design reviews, to discuss design milestones of substance? Of course there are, and there's constant communication in between as well. Very rarely have I seen where someone just goes off into their little corner, after a project scope/spec is set, and we don't see that person for another 2-3 months. So to me, Agile is trying to make itself out to be more than it really is, which is just applying common sense to the way you manage a project (i.e. knowing clients will want changes, explaining the impact of those desired changes, ongoing communication amongst team members, and with the client, and showing your development work to the client as you go along). It's a great video, this series is....and Dave does a great job here of explaining the methodology - kudos !! I'm just not sure what all the hub-bub is about, and why it's such a 'must have' in terms of 'experience' for today's PM roles. If someone can teach me what I am missing, I'm all ears. Thanks.
Funny, even as I watched the end of this video, and Dave talks about "a good Project Manager" will say, with 2 weeks to go "Hey, we need to finalize and start testing, debugging, etc". Well this too is nothing 'new'. We used to have a saying in the automotive industry....and please it's JUST an expression...but the expression was "it's time to shoot the Engineers and launch the project". All this meant was 'Time's up', if we don't start testing, debugging, validating, etc, we will miss the launch date. So this idea that Agile brought this mentality to the forefront, I'm just not getting it. We've been doing projects like this....at least good Project Managers....for a long time.
And even on the hardware side, if a client does not know precisely what they want, then we do rapid prototypes, 3D prints, etc...and give them a few options/ideas to choose from. So again, none of this is new. The other key I realize to Agile is a collaborative team, working together, focused on the same project (i.e. scrum, as in rugby). But unless a company dedicates itself to this methodology, then we are left with a typical matrix organization, cross-functional team, with members who may have several priorities/projects, and you as the PM are still left vying for their time to work on your 'agile methodology' project.
Please please continue this series. Your explanation is so clear and to the point.
Dave, you are one of the rare guys on Internet who speaks clearly enough for the beginners in Agile to understand what that really is. Do you know anyone else who speaks that clear, simple and organized language like you, but goes deeper in telling about Agile and is available on internet to watch? I see you have only 2 videos about Agile, although I watched your other videos and saw you touching some aspects of Agile as well. Any suggestions? Greetings from Latvia
Andris, thank you for your kind words. We are continuing on with the series about Agile development and will release the next few installments in the coming weeks.
SourceSeek in the coming 2-3 weeks or 5-10 weeks?
***** Not sure, but hopefully within about a month.
Any word on those videos?
part 3 didn't meet their agile schedule. :)
Yes, it's getting embarrassing!
Can you please still continue this series?
Haha!
Hi Dave. As with Part 1 - well done! Your discussion was very well organized as well as simple and easy to understand.
Straight forward and vivid example, nice video.
Just wanted to say you explain very well the whole concept. Very helpful, thanks!
+Antoine Hakim Thank you very much!!
That's the most useful explanation of AGILE on the internet, I say after a search of many hours :-) Thanks @Dave:-)
Vishnu Haridas Thank you I'm happy it was helpful.
One reason for specification change requests from clients during development is that it's easier for someone to know what they want when they can look at something that's not quite what they want.
The best tool I've found for checking a design or work process is to do a backward analysis. Look at the required output. Work backward through the logic to the beginning... the inputs and resources. When you understand it forward and backward, you'll have found most of the bugs and probably found ways to improve efficiency.
Great job. Could you tell me what type documentation are being produced along the agile process?
Nice introduction....Very aptly put ..
Hey Dave , very helpful understanding agile for beginners but need more, as I see many ppl have been waiting for the next video , when can we expect them to be released by plz ??
Your videos are great. Thank you very much for this clear video.
Best explanation I've come across. Thank you!
Hey thx so much for this effort and the way you give us this tutorial , is there a book or videos training for mastering agile: thx in advance
Great explanations - you'd be a great teacher! Did you ever film part 3?
Very well explained, Really appreciated how you explain things as a jr web developer this cleared confusion in my mind.
Please, I would like to watch part 3 of this series.
Am I missing something here? Lots of promises about part 3, but I can not find it. Did it happen?
This got only 6 dislikes for a reason. Very clear! Thank you.
Nice explanation, Dave. I totally love it. Now, I understand more better on agile topic.
dammit... i hate it when i start a series of videos with promises of explaining things... then the series stops prematurely. Not the first i get caught...
At least i didn't "invest" too much time into it... and i still got some well explained overview of the process.
sir, may i know where the Part 3 is? It is very helpful to me as an IT student
Hi Holiephere Chee. Thanks for your feedback. We are getting so many requests/questions for new videos, it's been hard to keep up with the Agile series. It's actually been shot already and just needs to be edited. It will be soon, I'm sure! thanks, Dave
thank you sir, i'm looking forward to it :)
Nice video! Wouldn't it be part of agile development to actually do bug testing in each sprint/iteration? Instead of at the end of the project?
There are a lot of approaches, but ideally there will be QA before any story is accepted as 'done', yes. But, a bigger app will need proper testing/regressions to maintain stability and that's best done continually rather than just at the end.
Hi Dave, thanks for those videos, they are much appreciated. :)
I understood you didn't had time to invest in this series anymore; do you still plan to release the part 3 ?
Watched first two parts and they were great..
I wish you could continue this course!!!
+Nazih Ibrahim Yes, I promise it will continue!
It's a shame you didn't continue this series. 5 years later and still no part 3..
so the key benefit is flexibility and the possibility for continuous improvement?
That's a major benefit, yes, but the iterative approach also helps with budgeting and other factors, too.
great explanation :)
Nicely explained !!!
Wow best explaination, thank you Sir
Great video. Thank you.
+Georgy Louis This question is answered in the comments of part #1, but I'll repeat the primary premise. Use whatever documentation is necessary- there is no set format. But, always favor communication and collaboration between team members over documentation when possible.
+SourceSeek It seems like you example assumes the client would be doing most of the testing. On a larger scale project with a dedicated quality assurance team, when do they become involved and how does that affect the documentation that must be kept (and continually updated due to the amount of change allowed)?
Hi Kyler - Great question, although it's hard to provide a simple answer. Regardless of who is testing, it's critical to make sure there is a bottleneck at the 'acceptance' phase, so that either the client or a pro QA team takes the time to test and validate the new changes. There are lots of ways to organize it, but it's key that someone is testing things after delivery, and maybe before release. This can happen per story, or per iteration but it's gotta happen. We could spend hours on the topic :) thanks for watching, Dave
Downvote for no part 3, these 2 videos are super helpful though
best way of explanation waiting for moreee.. :)
thank you for this video series
Im trying to find simple small explanations for big daunting topics for a friend who wants to get into Digital QA - I'm very impressed at this series of videos I'll definitely send him a link to this. 5*
Thanks for this great feedback, Leyton.
Thank you Dave for your video!!
good shit man!
Where is Part 3? 😧
Can you provide subsciption for video like part 1 in english is good
How Agile development is better than waterfall technique ?
waher is part 3 ??? we are waiting ....
This seems so common as the lean startup method.
More!
+Jesse McAdam Soon, I promise!!
did part 3 ever come out?
apparently not
2018 still waiting for part 3
No part 3?
part 3 please
thx
Part 3?????????????
where's part 3?
can someone notify me by replying to this comment when part 3 gets uploaded, please?
👌👌
We'll explained
Agile is an adjective, not a noun.
So as a 25-year veteran of classical project management, I see this Agile methodology as largely 'BS'. Anyone else agree? Let me explain. Agile tries to make itself into some 'fancy' methodology, when in fact, ALL projects have this iterative process, collaboration, etc. Maybe not in such short iterations but that's not because of 'Agile', that's just because software development can sometimes move faster than hardware development can. So I can see why people want to say it's mostly useful for software development, but that's only because software is just that...."soft"ware. So developing user interfaces, what this button does or that button, and showing it to the client as you are creating it only makes logical sense. But not sure why we have to wrap a fancy word around it, and create this Scrum Master term, and all these other names (e.g. sprints). I call it more 'common sense' methodology, and believe it or not, it also applies in waterfall methodology too. It's just design and development may take a bit longer (as it's not just coding), so 'sprints' are not necessary, nor relevant. But are there periodic design reviews, to discuss design milestones of substance? Of course there are, and there's constant communication in between as well. Very rarely have I seen where someone just goes off into their little corner, after a project scope/spec is set, and we don't see that person for another 2-3 months. So to me, Agile is trying to make itself out to be more than it really is, which is just applying common sense to the way you manage a project (i.e. knowing clients will want changes, explaining the impact of those desired changes, ongoing communication amongst team members, and with the client, and showing your development work to the client as you go along). It's a great video, this series is....and Dave does a great job here of explaining the methodology - kudos !! I'm just not sure what all the hub-bub is about, and why it's such a 'must have' in terms of 'experience' for today's PM roles. If someone can teach me what I am missing, I'm all ears. Thanks.
Funny, even as I watched the end of this video, and Dave talks about "a good Project Manager" will say, with 2 weeks to go "Hey, we need to finalize and start testing, debugging, etc". Well this too is nothing 'new'. We used to have a saying in the automotive industry....and please it's JUST an expression...but the expression was "it's time to shoot the Engineers and launch the project". All this meant was 'Time's up', if we don't start testing, debugging, validating, etc, we will miss the launch date. So this idea that Agile brought this mentality to the forefront, I'm just not getting it. We've been doing projects like this....at least good Project Managers....for a long time.
And even on the hardware side, if a client does not know precisely what they want, then we do rapid prototypes, 3D prints, etc...and give them a few options/ideas to choose from. So again, none of this is new. The other key I realize to Agile is a collaborative team, working together, focused on the same project (i.e. scrum, as in rugby). But unless a company dedicates itself to this methodology, then we are left with a typical matrix organization, cross-functional team, with members who may have several priorities/projects, and you as the PM are still left vying for their time to work on your 'agile methodology' project.
gg
Subscribed, then read the comments and unsubscribed.
i need part 3 to live
+Nataly RAW I promise it will come! It's really getting embarrassing but I never have time to continue this series.
+SourceSeek timebox it :-)
lady got 424 subscribers for no reason. :-p