Other than using a bunch of new slick sounding software engineering terms, how is Agile Scrum that different than Waterfall? The Agile Scrum Business Owner (i.e., AKA the Waterfall Business Owner), Development Team (AKA the Waterfall Development Team), Agile Scrum Master (AKA the Waterfall Project Manager), Agile Scrum Product Backlog (AKA the Waterfall Enhancement/Production Bug Fix Backlog), Sprint Planning Meeting (AKA Waterfall Release Planning Meeting), Sprint (AKA the Waterfall Software Development Life Cycle), Sprint Reviews (AKA Waterfall Release Demonstration) and Sprint Retrospective (AKA the Waterfall Release Lessons Learned Session) have all existed since the early 1980s. I will credit Agile Scrum with highlighting the importance of delivering releases more frequently, breaking down barriers between both the Business Owner/Development Team as well as within the Development Team itself, and conducting regular lessons learned sessions. These items are all Waterfall framework improvements but instead of improving Waterfall, the decision was made to attack it and burn it down.
Nice simple presentation on Scrum. If people doing scrum are a bit confused this should help a little. However the title of the the video is not represented by the video really. If you read the previous comments you can get an idea that there is resistance to it. I think the main problem is transparency. Some people don't like transparency it threatens the rewards the were getting and maintained over the years.
Actually SCRUM is about cross functional universal collaboration, business culture and practical thinking combined an in a structured way. Set your goals right, (re-) evaluate often and early, take responsibility as an individual and as a group. In itself it is not so complicated, but people are often the biggest hurdle (bottleneck) to take.
Love it love it. Am a manager whose been a scrum master for few years now and each and every slide resonates with a loud bell. The words could have been stolen right out of my mouth. Mind If i steal a few slides for my year end retrospective ? Would save me so much time. Thank you again.
Scrum or agile is difficult because it demands discipline, which organisations and managers and teams may lack. High level commitment to scum framework is an a priori, looks like, for its successful adoption and implementation.
Seems like there's a dichotomy between Waterfall and Agile, wherein better results may be somewhere in the middle. Agile focuses on the tactical battles and adapt to inevitable unknowns, but lacks strategic decision making and long term tradeoffs or the critical role verification plays in development. Waterfall approaches try to address a-priori investment risk for the company but lack the ability to pivot with uncertainty. Pros/cons to each, and not every projected suited to one method.
29:49 "If we stick to the Scrum process everything that is dysfunctional in an organization will get exposed" I thought that Agile methodologies were about putting persons before processes. And that means that the person controls the process and not the other way around (contradicting Fred Taylor who invented Industrial Engineering). And then Jens tells us we should follow Scrum in order to avoid dysfunction. Is people before process or the other way around?
32:30 It takes more discipline to be agile. Otherwise you are just told what to do, and you do it expecting that will be enough. When on agile, you need to spend much more energy to understand and to commit to what really matters.
Religion is for the priests, then the State, then the priests. Scrum is for... well, you work it out. It's the ultimate methodology which disencourages thinking.
I think Agile methodology promotes writing bad code. In Agile the quality of code is meaningless because it does not add value to customer - customer cannot see the code. Customer can only see the final product.
Agile itself does not promote good or bad code - it promotes the team taking ownership & responsibility for the quality. If they want, and estimate for bad code - that's what they will get. Since the team members are responsible for estimating timescales for story items, it is their responsibility to estimate based on writing good code. The PO should also be able to see that in the mid to long term, there is a cost benefit. If I write bad code in this sprint and finish early - come the next sprint / revision, I'm not going to look so good! Agile exposes problems like this - and chances are, I'd be off the project team pretty soon!
but you definition of done should ensure you've met a good quality level of code? to not do so will just incur debt you'll need to pay back later. there is a risk that lazy teams wont care about quality and in that case there is value in measuring the quality.
Dmitri Snytkine I would have to agree with the other two comments here; even in the video he specifically addresses that "value" is for the organization, not just revenue. (e.g. if a sprint spent just on refactoring makes the team faster in subsequent sprints, that has value.) ...albeit, a good Product Owner needs to recognize that value, & the team is responsible for properly estimating to include quality code. And, at the worst, the team is also a stakeholder, so should be empowered to point out messy areas and push for prioritization of refactoring investments (after all, it makes the "final" product more stable & faster to continue developing - tangible Customer benefits!)
So, to discontinue using a typewriter will cause better books to be written, just as using Scrum will cause better software to be developed? Fortunately, I have experience managing consistently successful projects in multiple methodologies (yes..Scrum, too), and if folks are blaming their methodology for the failure of their development projects, then they have much bigger issues to resolve than just their methodology.
No. The SM is not a technical role. The SM is responsible for knowing SCRUM processes, making sure the are followed and explaining it to others in the company. The Dev Team should handle code-related issues.
Are you kidding? Scrum masters are often cannot tell the Java from JavaScript, most of them never wrote a line of code in their life. The builds are usually made by the lead developer or by designated release engineer.
Dmitri Snytkine All those SMs that I know do write code, what else would they do between scrum meetings, sprint plannings and retrospectives? They cannot spend all day helping the devs!
Moje Konto Most SMs are former Project Managers, they just took Agile training, adding "Scrum master" to their title and hopefully got a raise for that. That's is the Agile economy in practice.
No. The Scrum Master should be trying to make himself redundant. (Train up the Team not to need him.) The Scrum Master should not be doing anything for this self-organising team that they should be doing for themselves.
07:50 to skip the same old criticisms of waterfall as just a big failed methodology. (...while, as always, ignoring all the tremendously successful systems that were developed using the waterfall methodology.) :)
Read what I said before you put words into my mouth. Using a word processor might help you finish your book on time. If you don't see waterfall as failed relative to SCRUM then why use SCRUM? Yes some projects do pull through using waterfall the majority don't (many studies show this). And no-one (including the speaker) is saying SCRUM solves all problems.
Ah, yes...the old myth about most Waterfall projects not being completed. Of course, the truth is that the majority of IT project failures have nothing to do with methodology, but are due to management changes, corporate reorganizations, withdrawn funding, capital budgeting decisions, and any number of good or bad reasons that a business will end an IT project. I've managed projects in a dozen methodologies...all of which succeeded because of the wonderful people working on our teams.
Yeah. I've had successful V-Model Projects. But I still think I could have done better using a Leaner approach. Now I can't remember the precise numbers but it was something like 2/3 Agile Projects succeed (i.e. 1/3 fail) and 1/5 Waterfall projects succeed (i.e. 4/5 fail) when held to the same standard. ("Change Requests" / "Bug Fixes" and all that.) Check out the Standish "Chaos report" - think it's been going since 1994 or something like that. Let's just say that the empirical evidence doesn't support "traditional methods."
Implies scrum is hard because of organizational impediments - that scrum would be easy is a non dysfunctional organization. Doesn't ever mention sustainable pace, but does talk about a team that nearly burned out after 5 iterations of over-committing - burn out and sustainable pace are mutually exclusive
Does not work for sales projects resulting from sales to much clinking expert knowledge needed I have a degree don't have the time for a another one you need one page were you can see and move every thing not click new page click another page another, oops made a mistake wait till the administrator is back from lunch and then only can it be fixed, Stupid program, Simplicity is highest form of technology. worked on it for 6 months "Sucks" I can better project manage from Facebook waist of money!!!!
All I can say is that your presentation is the perfect showcase as to why 90% of all IT projects fail. You just nail it =) .. Thank you for sharing it
He is so cool!! So much not alike any Agile Coaches I had seen so far. Honest and blunt, great!
cool presentation with basics highlighted in simple language...
Other than using a bunch of new slick sounding software engineering terms, how is Agile Scrum that different than Waterfall? The Agile Scrum Business Owner (i.e., AKA the Waterfall Business Owner), Development Team (AKA the Waterfall Development Team), Agile Scrum Master (AKA the Waterfall Project Manager), Agile Scrum Product Backlog (AKA the Waterfall Enhancement/Production Bug Fix Backlog), Sprint Planning Meeting (AKA Waterfall Release Planning Meeting), Sprint (AKA the Waterfall Software Development Life Cycle), Sprint Reviews (AKA Waterfall Release Demonstration) and Sprint Retrospective (AKA the Waterfall Release Lessons Learned Session) have all existed since the early 1980s. I will credit Agile Scrum with highlighting the importance of delivering releases more frequently, breaking down barriers between both the Business Owner/Development Team as well as within the Development Team itself, and conducting regular lessons learned sessions. These items are all Waterfall framework improvements but instead of improving Waterfall, the decision was made to attack it and burn it down.
Great work Jens, thums up!!!
This is the best video Ive seen to this day
Nice simple presentation on Scrum. If people doing scrum are a bit confused this should help a little. However the title of the the video is not represented by the video really. If you read the previous comments you can get an idea that there is resistance to it. I think the main problem is transparency. Some people don't like transparency it threatens the rewards the were getting and maintained over the years.
Thanks for the insightful video. I appreciate as to all the sections you've discussed and hope to be applying what you've provided.
Actually SCRUM is about cross functional universal collaboration, business culture and practical thinking combined an in a structured way. Set your goals right, (re-) evaluate often and early, take responsibility as an individual and as a group. In itself it is not so complicated, but people are often the biggest hurdle (bottleneck) to take.
Love it love it. Am a manager whose been a scrum master for few years now and each and every slide resonates with a loud bell. The words could have been stolen right out of my mouth. Mind If i steal a few slides for my year end retrospective ? Would save me so much time. Thank you again.
Really good presentation, found it very informative - just learning scrum. Thank you!
Very nice presentation, Thank you for sharing.
Excellent Presentation. I enjoyed it very much.
I've built way too many of those 45% Never features. Sucks when you know you did a kickass job and it never gets used.
Scrum or agile is difficult because it demands discipline, which organisations and managers and teams may lack. High level commitment to scum framework is an a priori, looks like, for its successful adoption and implementation.
Agree with the speaker that introducing scrum in an organization is difficult as it is seen as challenging the existing culture and beliefs.
thank you by sharing this presentation, it was very good!
Seems like there's a dichotomy between Waterfall and Agile, wherein better results may be somewhere in the middle. Agile focuses on the tactical battles and adapt to inevitable unknowns, but lacks strategic decision making and long term tradeoffs or the critical role verification plays in development. Waterfall approaches try to address a-priori investment risk for the company but lack the ability to pivot with uncertainty. Pros/cons to each, and not every projected suited to one method.
29:49 "If we stick to the Scrum process everything that is dysfunctional in an organization will get exposed"
I thought that Agile methodologies were about putting persons before processes. And that means that the person controls the process and not the other way around (contradicting Fred Taylor who invented Industrial Engineering). And then Jens tells us we should follow Scrum in order to avoid dysfunction. Is people before process or the other way around?
excellent talk.
32:30 It takes more discipline to be agile. Otherwise you are just told what to do, and you do it expecting that will be enough. When on agile, you need to spend much more energy to understand and to commit to what really matters.
Religion is for the priests, then the State, then the priests.
Scrum is for... well, you work it out.
It's the ultimate methodology which disencourages thinking.
Max Hodges You just gave a religious testimonial.
Case closed.
indeed, my good sir.
@Supreme40x check video description
I think Agile methodology promotes writing bad code. In Agile the quality of code is meaningless because it does not add value to customer - customer cannot see the code. Customer can only see the final product.
Agile itself does not promote good or bad code - it promotes the team taking ownership & responsibility for the quality. If they want, and estimate for bad code - that's what they will get. Since the team members are responsible for estimating timescales for story items, it is their responsibility to estimate based on writing good code. The PO should also be able to see that in the mid to long term, there is a cost benefit. If I write bad code in this sprint and finish early - come the next sprint / revision, I'm not going to look so good! Agile exposes problems like this - and chances are, I'd be off the project team pretty soon!
but you definition of done should ensure you've met a good quality level of code? to not do so will just incur debt you'll need to pay back later. there is a risk that lazy teams wont care about quality and in that case there is value in measuring the quality.
Dmitri Snytkine I would have to agree with the other two comments here; even in the video he specifically addresses that "value" is for the organization, not just revenue. (e.g. if a sprint spent just on refactoring makes the team faster in subsequent sprints, that has value.) ...albeit, a good Product Owner needs to recognize that value, & the team is responsible for properly estimating to include quality code. And, at the worst, the team is also a stakeholder, so should be empowered to point out messy areas and push for prioritization of refactoring investments (after all, it makes the "final" product more stable & faster to continue developing - tangible Customer benefits!)
This guy looks like Chuck from Better Call Saul.
So, to discontinue using a typewriter will cause better books to be written, just as using Scrum will cause better software to be developed?
Fortunately, I have experience managing consistently successful projects in multiple methodologies (yes..Scrum, too), and if folks are blaming their methodology for the failure of their development projects, then they have much bigger issues to resolve than just their methodology.
until 5:06 is interesting, and after 11:00 is more advanced
Good video :)
Should the scrum master also be responsible for managing source code builds and version controls?
No. The SM is not a technical role. The SM is responsible for knowing SCRUM processes, making sure the are followed and explaining it to others in the company. The Dev Team should handle code-related issues.
Are you kidding? Scrum masters are often cannot tell the Java from JavaScript, most of them never wrote a line of code in their life. The builds are usually made by the lead developer or by designated release engineer.
Dmitri Snytkine
All those SMs that I know do write code, what else would they do between scrum meetings, sprint plannings and retrospectives? They cannot spend all day helping the devs!
Moje Konto Most SMs are former Project Managers, they just took Agile training, adding "Scrum master" to their title and hopefully got a raise for that. That's is the Agile economy in practice.
No. The Scrum Master should be trying to make himself redundant. (Train up the Team not to need him.) The Scrum Master should not be doing anything for this self-organising team that they should be doing for themselves.
Is it possible to get the presentation file? How can we get in contact?
07:50 to skip the same old criticisms of waterfall as just a big failed methodology.
(...while, as always, ignoring all the tremendously successful systems that were developed using the waterfall methodology.)
:)
Read what I said before you put words into my mouth. Using a word processor might help you finish your book on time. If you don't see waterfall as failed relative to SCRUM then why use SCRUM? Yes some projects do pull through using waterfall the majority don't (many studies show this). And no-one (including the speaker) is saying SCRUM solves all problems.
Ah, yes...the old myth about most Waterfall projects not being completed. Of course, the truth is that the majority of IT project failures have nothing to do with methodology, but are due to management changes, corporate reorganizations, withdrawn funding, capital budgeting decisions, and any number of good or bad reasons that a business will end an IT project. I've managed projects in a dozen methodologies...all of which succeeded because of the wonderful people working on our teams.
Yeah. I've had successful V-Model Projects. But I still think I could have done better using a Leaner approach.
Now I can't remember the precise numbers but it was something like 2/3 Agile Projects succeed (i.e. 1/3 fail) and 1/5 Waterfall projects succeed (i.e. 4/5 fail) when held to the same standard. ("Change Requests" / "Bug Fixes" and all that.) Check out the Standish "Chaos report" - think it's been going since 1994 or something like that.
Let's just say that the empirical evidence doesn't support "traditional methods."
Why say "SM has no authority" ?
Scrum is easy. If you have to give it much thought, something is wrong. It should help you, not hinder you.
Implies scrum is hard because of organizational impediments - that scrum would be easy is a non dysfunctional organization. Doesn't ever mention sustainable pace, but does talk about a team that nearly burned out after 5 iterations of over-committing - burn out and sustainable pace are mutually exclusive
Yeah, and many good books were written on a typewriter. That doesn't mean you should continue to use one.
Comic Sans... for real?
If it didn't work then you are not implementing it correctly.
i stopped watching this video before a minute passed because of the comic sans :(
wow you must be a joy to work with
Bac club
Does not work for sales projects resulting from sales to much clinking expert knowledge needed I have a degree don't have the time for a another one you need one page were you can see and move every thing not click new page click another page another, oops made a mistake wait till the administrator is back from lunch and then only can it be fixed, Stupid program, Simplicity is highest form of technology. worked on it for 6 months "Sucks" I can better project manage from Facebook waist of money!!!!
4:50 to skip the useless, personal history and riffraff