Intro to Scrum in Under 10 Minutes
Vložit
- čas přidán 27. 05. 2024
- Follow Hamid, or ask questions from him on Twitter here: / hamids
For Scrum software, visit: goo.gl/T6F2KX
Scrum Overview Diagram:: www.scrumhub.com/
What is Agile Scrum? Learn Scrum in under 10 minutes in this video introduction to the Scrum software development methodology. By the end of this fast-paced video, you'll practically be a scrum master. You'll know about burn down charts, team roles, product backlogs, sprints, daily scrums and more. You'll also be ready to start implementing Scrum in your own team.
Of course, for an easy to use tool to help implement scrum, you can visit www.axosoft.com.
#axosoft #agile #scrum #projectmanagement #kanban - Věda a technologie
*Quick summary:*
- Scrum is a specific agile software development process
- Agile software development processes focus on developing iteratively (basically, intermingling design and development)
- In Scrum, you write the desired features of your software as "user stories" (which are formatted like so: "as a user, I want to be able to check my bank account balance")
- You choose a subset of the user stories for a particular release (e.g. version 0.1), this subset is called the release backlog
- You break up the release backlog into a bunch of sprints ("sprint backlog")
- For each user story in a sprint, you estimate the amount of time it will take you to compete that user story
- You assign these user stories to developers
- As developers work on their user story, they update how much time is remaining on their user story
- the burndown chart shows you how much time remains in order to complete all the user stories in the sprint
- ideally, as the developers work on their user stories, the burndown chart should show that there is less and less time remaining in order to complete all user stories in the sprint
Hope that was helpful to someone!
Thanks for the video, very clear and concise.
Thank you so much
Thank you! 👍🏾👌🏾
Thank you
Thank u
THANK YOU! ~ A tired grad school student
I paid my university $4187 to do a course and they give me the link to this video
Lmao
sue your university
Funny story, two of my lecturers sent us here smh
now I feel like i saved $4187.... awesome baby ! Yang2020
EZ money from people who think a University has something more to offer than the infinite amount of free knowledge online. My my my, when will people learn.
"And these guys, they generally get in the way, but you can't get a project done without them."
i felt that lol
"He's a lot like a project manager, but that's quite a boring title, so we will call him Scrum Master to imply he knows some jiujitsu" 😂 😂 😂 😂 LOL
7:51 Review / Summary
- Product Backlog > Release Backlogs > Sprint Backlogs (short-duration milestones)
- Monitor progress of Sprints with Burndown Charts
- Daily Scrum Meetings to ensure everything is on track
- Retrospective Meetings after each Sprint for fine-tuning
small addition, Burndown chart is feed by hours completed on User Stories.
Thanks this is useful
Thank you, this makes the whole process uncomplicated
Glad I was properly caffeinated prior to watching this video! I love the pace and visual aids. Very well done.
this is how a video should be made, perfect words, perfect video editing, and a piece of perfect background music.. respect....
Found this video more than 3years ago and even today it's still the best Scrum video around. Thanks Guys!
2024 and still valid. 😊
The overview of the Agile Scrum methodology presented in this video was awesome! It covered the basic components of Scrum in such a way that was very helpful to my learning of all things Agile and Scrum. Very impressive!
Believe me I found this presentation the best ever THANK YOU
Too bad, it is chock full of inaccuracies. Good summary of the factual errors: czcams.com/video/XU0llRltyFM/video.html&lc=Ugw22fmi6bZsli4iXNZ4AaABAg
I was really late on studying for my finals in software development, and haven't worked with scrum with he internships i followed so far. You really nailed in explaining the concept in 10 minutes, i took notes from your video and they have helped me a lot in my current study-sprint for today :) Thank you a million times Hamid.
This is by far, the most brilliant illustration and explanation of agile scrum I've seen here in youtube.
I like it when the person goes directly to the point, normally people tends to speak too many words for a certain topics which will eventually lead us to a more complicated way.
Good job and Godbless.
I am just beginning to work with Agile Scrum and this video has been the best I have seen thus far!!
I have spent hours and hours to get the correct and simple content on Agile and literally got frustrated after a while. But then here comes this video which give me everything i needed to know about Scrum Agile in short and simple video with real time project reference. You guys are awesome and saved my lot of time. Thanks a lot keeps posting such informative video.
This is the best presentation I have ever seen. I can't believe you conveyed this entire info in just under 8 minutes, that too effectively.
I'm starting an internship soon and am going to be observing and bouncing around some scrum teams to start understanding how software companies handle their business, and this was an awesome video to help orient myself to what I can expect to see at this internship. Thanks a ton and an overall excellent video!
A great video for those who want to get into Scrum or are just starting out. This explanation is brief and fast-paced, yet chock-full of information. Well executed video.
Thanks for the concise overview. Im a midlife mum switching from education to tech--every minute is precious!
Amazing synthesis of information within 10 minutes, I am an absolute illiterate on SCRUM and I grasped the structure of it and how it works perfectly, great job!
I wish all videos were this good and efficient. Thank you for the quick intro!
Excellent video with a very good coverage in a short time and it is never boring, not even for a sec.
Best video ever saw about explanation of scrum,thanks alot .
I've came to this video multiple times over my consulting career to brush up, one of the best out there. Thank you Hamid.
Thanks for this. Its extremely informative and under 10 mins as promised. I'm currently working on a kanban + scrum for the first time and watching this vid with the Intro to kanban in under 5 mins, was just what I needed to get going. Thanks once again. You guys are super cool!
one of the best professional videos I've ever watched. I learned a lot in just 8 minutes! I love to be a product manager and am searching a lot through the web, this was one of the best, hands down!
Could not agree more!
In a Linkedin post, I pointed out that this video has dozens of inaccuracies. I've decided to post my point by point clarifications for anyone that cares to read them: 0:29:User Stories are not a Scrum practice, they come from XP. While commonly used, they are not Scrum. This will be a common theme in these comments.
0:50:Release planning is again not a core aspect of Scrum. Scrum is built to inspect and adapt at the end of every sprint, not predict or plan exactly what will be delivered in a multi-sprint release
1:14:The description of the Scrum Master is pretty incomplete. They don't make sure the project progresses smoothly, they ensure the team is working collaboratively and inspecting and adapting as they go. They aren't required to set up meetings (the "team admin" dysfunction, they don't monitor the progress (the development team is self-managing, so they do that). Since Scrum is intentionally silent about release planning, it's not part of the core job description to facilitate it. The Scrum Master is NOT a lot like a Project Manager - they don't manage the project. The help the team. The team manages the project. The Scrum Master name is regrettable, but it's not just a relabeling of Project Manager that implies jujitsu skills.
1:37:The description of the Development Team members implies a Code-Test sequence, while most development teams will eventually adopt a test-driven approach. There are no official roles on a development team, only collaborative team members with skills in various areas.
1:41:Executives "generally get in the way" is a frustrating meme in the Agile community. It creates an us vs. them dynamic that doesn't help agility thrive. Agile executives are a rare breed, but they exist, or can learn to take an Agile approach, but not when we start with the premise that they just get in the way.
1:46:There is an entire section here on Release Planning. Again, not a core aspect of Scrum. There are many concepts in this section that I would not recommend, even when teams need to do release planning, such as picking all of the User Stories up front, creating a separate Release Backlog (there is no such artifact in Scrum) the team doesn't prioritize the User Stories, the Product Owner does, though effective ones will do that collaboratively with input from the team and stakeholders.
2:27:"Story points don't answer the question of when will my product ship". Actually, they do, and in my experience, more reliably than time estimates. This whole section on estimates shows a lack of experience or understanding for how Story Points and Velocity work. I recommend reviewing Mike Cohn's Agile Estimation and Planning book for all the details here. I could write an entire post on the drawbacks of time estimates (lack of collaborative estimation, overlooking the integration pieces, etc.).
3:19:"plan out several sprints". This is a dysfunction. We don't do this for many reasons. Slotting Product Backlog Items in sprints tends to bias us against inspecting and adapting at the end of each Sprint. That takes away one of the two core benefits of Scrum: the ability to adapt the Product Backlog based on feedback after each Sprint.
3:24:Calling Sprints milestones again overlooks the important Inspect and Adapt capability upon which Scrum is founded. In traditional projects, milestones are just checkpoints towards a shippable product. In Scrum, each Sprint results in a shippable product.
3:33:While it's theoretically possible to do a two day Sprint, I've never seen one that short. The event overhead would be too high and the timebox too short to get something meaningful to an inspectable state. Two days also overlooks the "human cadence" aspect of Scrum, where the Sprint cadence mimics other standard cadences, like a week, two weeks, or a month.
3:41:Specifying from 2-12 sprints for a release is just confusing to me. Releases and Sprints are decoupled in Scrum. Many Scrum teams release many times during a Sprint. Every team actually using Scrum as intended should be shippable every Sprint.
3:47:Sprint Backlogs are not created during release planning, and are not just a subset of the Product Backlog (or Release Backlog to use the video creator's terminology). Sprint Backlogs are created just in time, at the beginning of each Sprint, during the Sprint Planning meeting. The development team pulls items from the Product Backlog at that time into the Sprint Backlog for just that Sprint, and then does additional planning to figure out HOW they will deliver those items during the Sprint.
4:09:"A late finish of the Sprint" never happens in Scrum. Sprints are strictly timeboxed, so they don't get extended. The team may cut some scope to meet the timebox, not the other way around.
4:18:The author of the video is confusing two practices, neither of which are required in Scrum. A Sprint Burndown chart gives the Development Team visibility into their progress during the Sprint towards completing the items they've pulled into the Sprint Backlog. It's a common tool but not the only way to do this. A release burndown chart gives the Product Owner insight into progress towards a release goal. I prefer to use a Burnup chart at the release level in this context, since it provides a more elegant visualization for Scope is changing, which happens on nearly every multi-sprint release.
4:20:The burndown chart is far and away NOT the number one reason for Scrum's popularity. Maybe in the author's experience that's true, but not broadly speaking. The number one reason for Scrum's popularity is probably that you can get certified in it (cynical reason), or that it allows us to iteratively improve our approach through Sprint Retrosepctives and the Product through Sprint Reviews, so that the thing we build is actually what customers want. It's also just a more human way to do work, meaning it aligns with how software developers naturally thing about the craft of software development.
4:51:I've never heard the term Burndown Velocity before. The author is describing a trendline. Velocity, as it was popularized by Mike Cohn in the previously mentioned book, is the average number of Story Points completed in a Sprint. It's also how Story Points answer the question of when the product will ship. It's not a daily metric, it is a Spint by Sprint average. The rest of this section on Burndown Charts is pretty accurate, but applied to the Sprint Burndown, not the release burndown.
6:42: The author skips the Sprint Review entirely, a core Inspect and Adapt step of Scrum.
7:00:This section of the video is a sales pitch for OnTime, one of several ALM tools available. When I coach teams, I ALWAYS encourage them to start with a physical board so that they can tweak the process as they Inspect and Adapt. Any tool vendor will have a specific vision for how Scrum is used, and it is often (as in this video) not aligned with core Scrum concepts. The teams that start with a tool like this start doing Scrum according the tool vendors vision, rather than iteratively figuring out how best to use Scrum in their context. That's not to bash OnTime - all tool vendors have the same drawback.
7:34:Well, the tool vendor here bashes physical boards, implying that they're like the abacus of visualizing the work. I get it, they're selling a tool, but this is a recommendation and viewpoint that I strongly disagree with.
7:45:The Product Backlog is more than just a collection of User Stories. This description leaves out two core aspects of a Product Backlog. First, it is Ordered (or prioritized). Second, it is emergent, dynamic, and always changing as we learn (through the absent-from-this-video) Sprint Review meetings what is most important to build next.
7:50:The rest of the video summarizes the earlier points, and since I've already commented on them, I won't reiterate them here.
Closing thoughts:I actually know some Axosoft folks, and they're a fine group of people doing good work. I don't like coming off as overly critical, but if anyone views this video as a key summary of how Scrum works, they're going to get the wrong impression. I'd reccomend, instead, that you check out the free videos Icreated here: czcams.com/video/eRlIKDTetIs/video.html
youre awesome
@@annon123 Thanks!!!
But this video is pretty familiar with the scrum I have been reading at my university.
❤
Brilliantly done. Short to the point with sufficient detail and no fillers.
This is one of best, most concise videos on ANY topic on CZcams. Dude! Well done!!!
Very useful video. Its smooth, on point and easy to follow. Its got all and only the critical content on the basics of SCRUM. Also the narration is very fluid and comfortable to the listener. it s evident that the video has been refined and revised to communicate everything effectively. GOOD JOB.
It's also full of errors, as pointed out above.
Phew! That was a marathon presentation.....Good and concise video
This is by far the best introduction to Scrum and facilitates the terminology in a fun way using brilliant animation/graphical images and articulates the framework in a clear and concise manner. No jibberish. Thanks a lot. Really helpful ..!!!
Wow this presentation was short but loaded with depth. Straight to the point, no beating about the bush! I would really like to hear great failure stories of Scrum/Agile! Thanks for the presentation video.
I just want to say this was the best tutorial on Scrum I've seen, and I've gone through literally over a couple dozen. Can't believe how easy you've made it seem, and so clear. You rock!
I changed my working style to Agile Scrum back in 2007 and I am not coming back to old work habits. It also changed my communications style. For this methodology to work, everybody in the company must be involved as "team players".
The problem with "team players" only is that the team becomes the "mob" and the individuality that promotes innovation is lost.
This video is very awesome, I went from zero understanding, to a pretty clear idea of what to expect from a scrum environment. EPIC
This is the way that videos should be made. Precise , Fact paced and informative with a bit of humor. You my friend deserve an Oscar !!!1
Cheers
Thanks a lot for making the concept to understand in short period.. It's really a good one.
Thanks! Clear explanation, informative video, and the plug to your product actually made sense.
Fantastic video!!! This has really increased my understanding of Scrum as I prepare to enter a new job that uses it heavily. Thank you for making it easy to gain a foothold!!
No BS in this video. Straight to the point and articulate. All meat and no fluff. Nice job Hamid.
Perfect! You are an impressive speaker. Keep up the good work
Loved this! First video that I laughed at and engaged in. Trying to brush up before my final Scrum Master interview tomorrow. Thank you!
Just came across this your comment amd I hope you're doing great as a scrum master now. I'm trying to transition to tech too with major focus on scrum master. Hopefully I'll become a scrum master like you soon.
I am using this video as a quick introduction for my students. It's pace is great to get the conversation started, and my students are informed that this is not an exhaustive view of Agile in advance. Great video for the intended use!!
What an eloquent explanation of scrum! Good enough for a 6th grader to understand and engaging enough for the professional to stay tuned in. I like it!
Great video, fast paced, straight to the point and upbeat. I feel more informed about Scrum.
+Xander T I think so too. Also I am excited to use Scrum after this video :D
Love it, great course in less than 10 mins, brilliant!
one of the best video i have seen in my 12 years of career, its super quick, informative and has all the topics, thanks.
Perfect! A model for others to follow on how to make a concise, comprehensible tutorial video. So many on CZcams can learn from this example.
Wow! Impressed with how much info you conveyed in such a small amount of time. I really want to learn this process!
I bet he used scrum to produce this video.
That pretty much scrums it up, thanks.
get... out
Oh, Thank you so much for such a great presentation!
stay tunned and wait for more videos!
I've watched numerous videos regarding scrum and this is the best one. The explanation was kept simple yet informative. Thank you so much!
Great explanation. Thank you!
Woa! You explained it Sir clearly. Thank you!
I'm learning, somehow. ^_^
Hehe. good for you my Deborah. :*
Great, quick way to have a good understanding of what Scrum. Way better and faster than reading an article or a textbook...
Loved it !
This is an excellent overview to get someone super interested.
The clarity in your presentation along with the visuals is awesome.
Why do they have to put whistling musics everywhere? Why???
Whistling is love. Whistling is life.
Whistle while you work... disney-esque happiness?
that's borrowed from Maroon 5 song - moves like Jagger... move wuuuu....
An operations vs sales dilemma question. The video content is the actual product that adds value, but the accessories like whistling music is to make-feel-good selling point. Which works as commented above for some.
Music here was a distraction. When you have serious business, avoid distractors.
💯Definitely the Best. Love the way you broke it down and explain everything about the subject. 👌🤗
It seems like ontime is a great tool to incorporate in an enterprise, which is built by the team who understands on how to like the technology, people, constraints in an efficient order to deliver it on schedule.
Nice☆
Thanks Mr. Hamid, for such a short, but an awesome presentation.
This was the best YT information I've seen on Scrum
Best ad ever! thank you :)
Dude amazing work thoroughly impressed. I would like to know Agile as well.
T
Now that's an agile video! Precise and apt. Good work.
absolute, crisp and clear, feeling lucky to have come across this video on youtube !!!! Thanks a tonn!!!
In my experience developers update the time sheet (long existed) with the activities they have done and most of the time they just punch in some numbers because it is such a hassle and they want to get it done with and get back to work. Can I say this is probably the key hindrance to scrum and what can be done? I've been both a developer and a PM.
I literally laughed out loud at the Scrum Master joke... Thanks for that!
Really amazing to see that how beautifully all info is conveyed in a short timespan!
This was the best intro in a nutshell i have ever seen you remind me of true efficiency and competence
Holie smolie, I was 95% into the video before realizing it was a sales pitch!
At least they offered value :v
whats wrong with a sales pitch with information and value
He provided excellent bit sized info in just 8-9 min and you could not get that even with a bigger course. Please show some gratitude and he never did too much sales pitch too. The guy has stuff so his work speaks for itself
What's the problem? It is a win-win situation. We get a free short introduction to scrum and he has a platform to promote its product.
I just knew the term "scrum" before watching this video. But i have plenty of scrum terminology and concepts now. thanks to you.
Great video for the beginner. Easy to understand with a confident voice and no accent. I appreciate the brevity without sacrificing content.
Thanks, Hamid! This is the coolest and a very dense way to explain the scrum!
And just like that I'm going to pass this software architecture course. Next I'd like to ask for tuition assistance in a 10 minute video.
Even this is a video recorded for commercial purpose, still this is a good video
Thanks ! Great tutorial! Preparing for a interview, watching this just in case the interviewer asks me about what scrum is .
Hi, Hamid Shojaee... thanks to KEEP this video on CZcams - I used it for some novice people to know better about Scrum - and it was really nice to find it here yet! All the best for you and AxoSoft Ninjas Team ;-)
I was very interested until you said you prefer hourly estimates vs story points. It is very easy to estimate when something will be done but you need to know the teams velocity first. Hours don't work with difficulty estimating.
Read Jeff Sutherland's book on Scrum. A great read.
Coming from a Project management/ Prince 2 background, I'm looking to transition to Scrum and will be going for certification in a few weeks. Your video has helped shed a great insight into the methodology. Thank you!
Thank you for the short, brief and nice intro to Scrum.
I tend to think Agile/Scrum/flavor of the day methodologies are composed of two parts. The first are the obvious things you should do: breaking problems down into smaller pieces, testing, etc. You don't need a special word for this: it's common sense.
The rest of them comes up with arbitrary rules and labels or juvenile names like the "Scrum master" or the "Product Owner" or the "Product Backlog" or "Sprints". Why do you need this specific of a set of rules? Can't intelligent adults just decide, "Hey, we should have someone/some group of people responsible for this aspect of the product" on a project by project basis?
it's a model that was devised, and in order to describe it, you need to constantly refer to its subjects (players and components). what better way to do that than to give them names?
i do think that the names are not as straight-forward as they could be. "scrum master" could just simply be "project manager" or "producer," "back log" could simply be "features list," but in the end, you're still referring to the same concept.
I think you're restating the problem, though. It's a devised model. Instead of calling someone "the scrum master" why wouldn't you just say, "I think we need someone to be responsible for x on this project", and call them Lisa or George or whatever. The irony is that this kind of thinking exactly mirrors what it is purportedly trying to combat. You're starting off by saying, "we shouldn't define the solution to our project before we get there". Then on the other hand you're saying, "every project needs a scrum master and a product owner and sprints and ...".
+Ryan Williams So when you move on to the next project with a different set of folks, what would you say? "We need a Lisa or George for this project too!" It's just a standardized term so that everyone understands. Any methodology is just that - a standardized set of terms given to standardized way of doing things, so that everyone talks in the same language.
Hey u missed about sprint review.
At the end of the video he did say sprint retrospective at the end of each sprint.
Retrospective is not review :)
Also missed the Sprint Planning, but IMHO, in this presentation Sprint Planning & Sprint Review is in one pack of Sprint only
I'm trying to quickly learn a little bit about Agile and Scrum for a new communications role I start in a couple of days, supporting an IT executive. This was a very helpful and engaging video. Thank you!
Excellent, straight forward explanations without raising more questions and confusions.
It's a shame about the misinformation about story points. Estimating in hours/days misses an important aspect of Agile/Scrum. Story points most certainly do tell you when your product will ship, but only when taken together with the team's velocity, which can only be calculated after a few sprints. So story points divided by velocity = when your product will ship (in sprints).
I thought the important aspect of relative estimation was to elicit discussion, particularly when different Developers provided different estimates. It may highlight a difference in understanding/knowledge that could be useful. It also serves as a shield to personal velocity; meaning we are agreeing on the distance, not the running speed. Therefore a junior and senior would agree it was 3 points, despite the fact a senior could complete it in an hour, while a junior may take over 4 hours. It might be hard for different skill sets to estimate a task in a common time, given they would take different times to complete.
Some gotchas in the video. Estimating in hours can be recipe of disaster and brings out conflicts while estimating as a team. Hour estimation is mainly dependent on the expertise of the team-member in question and cannot be termed as team-estimate.
Scrum Master is NOT like a Project Manager. By definition she's a servant-leader focused towards removing impediments and shielding the team from external interferences.
Important ceremony Demo is missing. Lot more focus on burndown chart as that's the selling idea of the video anyway.
ShriKant Vashishtha user stories must definitely be estimated using Points, however tasks will be translated in Hours to quickly visualize issues on teams progress and maturity
You cant even imagine how much it has helped me.
This is brilliant .. thank you for this short video. I work in scrum but when you are explaining the concepts, I was trying to relate.. which gave me better understanding
Estimating in hours is the big mistake in this video. User stories estimated in days or months is even worse. Storypoints are very important to eliminate the debates on hourly estimates ("I could do it in 5 hours!") and to disconnect the story from who will develop it (as ShriKant says below). I would not use this video as a Scrum orientation.
"This just became a job"
Gylfoyle!!!
@@alamjim6117 uuu
An amazing condensed version of SCRUM that is easier to understand , and the voice is just outstanding!
Awesome video. Well-structured. Easy to understand. Excellent work!
Sounds incredibly stressful...
In practice, I imagine it is simple and makes work-flow practical. But I agree, it does sound as straight-forward as the US congress. xD
It is. For instance just try having a daily meeting where everyone shows up and shows up on time and then try constraining it to 15 minutes. Those meetings often result in excuses given and accusations made against others that are present as to why they can't get whatever done, which usually degrades into a scream fest that you have to somehow control without any authority over those involved. And that's just the start of your day. And those executives that "generally get in the way"? That is an extreme understatement. They constantly harass and irritate you for updates and lengthy explanations as to why something isn't going quite as planned, as well as making you develop lengthy "action plans" as to what you are going to do about it. This while you are trying to focus on all the dozens of different complex aspects of the project each day.
As someone who has worked on this type of team, it is actually pretty simple. It can be pretty annoying having a meeting everyday about what you did the previous day when the work is actually pretty slow and you are trying to focus on the same thing for days. Here it sounds a bit complicated but it's not as bad. Being a developer, I have never had to deal with the executives that are mentioned in this video. They usually bother the managers above you. This methodology seems a bit unpractical as it makes you waste 30-60 minutes of your day trying to conduct a meeting, but in the long run it is very useful.
I totally agree.
I guess you need to have very specific people with very specific experience and training. I can't imagine anyone from my office able to work like this even after some training.
Ah, the background music is so annoying!
jon hahaha, true!
jon i didn't hear it till the end. It's called reticular activating system
i didnt even notice it. you have bad attention
It is a greatest SCRUM explanation I've ever seen in 10 minutes! Thanks!
One of the best and time savvy visual representation of the scrum!!!
SM is not a project manager with a different name!
First of all - thanks - that's a very beautiful and professional presentation. And now to the issue at hand:
Scrum and Agile are just more buzz words and methodologies to justify looking at people and using them as brainless robots.
Hell, most people indeed are, and need such micromanagement by a "master" with bloated ego and zero trust in his own selection of people. He selected them, but he can't trust them to manage themselves.
No - you can't predict so much ahead, this never works. Taking a big mission and defining it to many small chunks, defining "sprints" and other such nonsense - COMPLETELY undermines the philosophy of refactoring. It also completely undermines the philosophy of self esteem - since you don't have esteem to others, and must have them "predict" the future - you don't have self esteem. People only demand others to "predict" duration of tasks so that they can cover their own asses.
When you simply trust the developers, and they have a healthy share in the business and are really devoted to the success - they can produce in light speed, beyond your and their imagination and "predictions".
When forced to define time frames and durations for tasks and "sprints" ("faster slave boy! faster! sprint motherfucker sprint! run!" I hear...) this only ensures people work as slow as possible, feel blame shame and guilt when there's something un-predicted (this gives the scrum "master" an excuse to look down at the faulty developer who can't predict everything in the future right).
The scrum master takes no responsibility and needs to make no predictions - all his predictions rely on the developers whom he can always blame - in others words - scrum and agile are nothing but idiotic ideas to provide the top tier with job security on the expense and dignity of the bottom tier. Only people with very little authentic self esteem (but a bloated fake one) would engage in such "methodology".
We live in a very broken world. 20 Million animals are butchered every hour, politicians still manage every aspect of our lives, no wonder only 1% voted this video down, and it's not because of the way it's presenting the issue - but because of the issue itlself.
Most projects don't get delivered in time, predictions don't work over longer time, it's a waste of time - but - everybody WISHES they could predict the future - so it's easy to sell such idea - as it is easy to sell the idea of voting. 99% still believe voting is freedom - and here we see 99% who believe they can delegate the "task" of predicting the future down the chain of command, and then they believe they can get to blame the people under them when the predictions fail to meet reality.
It's the same story as with religion (still over 90% of the world population) - most people can't live with the idea of uncertainty - they feel that they MUST KNOW and predict. Can't admit "I don't know". They FEEL a blow to their self esteem when having to say I DON'T KNOW. So they never say it. It takes a lot of self esteem to say I DON'T KNOW - and all those robot developers who obey their bosses and "predict" their work and define all the future work in little boxes - they don't have the balls to say I DON'T KNOW. I'm sure I can do it very fast, but I can't predict.
If you take an hour to "predict" a month's work ahead of time with 80% accuracy, you're lying to yourself. You take an hour long work and say it takes a month.
Development is brain work and you can't work your brain in 1 hour to know what your brain will do in 1 month - it's a theory that doesn't stand the test of theory even. There are unexpected issues that take most of the time, unexpected I said.
Go back to sleep.
Mind. Blown. You have a point, but what of the 20 Million animals butchered every hour? That's about 3.4 billion per week, so, about 175 Billion per year. I guess that's not very much, but consider if they're not butchered most of them would be multiplying, so there's that, let's just say 3.4 Trillion per year. That's a lot of greenhouse gas! The UN could never collect Carbon Tax from those ANIMALS, but if they could we'd probably be living in Utopia! Of course we humans might be dead without our meat massacre, unless we could somehow harness the great water of the Ocean, remove the salt, and water our crops... yes with WATER like out of the toilet! This would insure sustenance be available other than flesh. Ewe. Gross. Flesh. That makes me want to be a vegan.
Go back to work!
LaxM
Go Vegan! Definitely!
You are sadly misguided. The purpose of Scrum/Agile isn't to "predict the future" as you so wrongly believe, but to break down large tasks into smaller, more manageable ones. Time frames are intended to be flexible and react to the developers' needs. If the developers encounter a problem and realize a task is going to take a lot longer than they expect, they make a note of it and change the ETA of the project. If the developers are being 'forced' to work harder or faster to meet a deadline, then it is a failure of the company's culture and/or management. The company I work for uses Agile and every single time I encounter a problem, I simply tell my boss what is going on and let him know that a certain task is going to take me more time. For each time I've done this, he has either allocated more workers to the task, updated the timeline of the project to account for the increase in time, or modified the task in some way to reduce the amount of work needed to be done without significantly affecting the end result. Not once in the three years I've worked there have I been scolded, insulted, or punished for encountering and explaining a problem. Sure, I've had to put in extra work and hours (working hard - scary, I know) on occasion so that the project could meet its deadline, but it was never unreasonable, and I always spoke up if I was concerned about an unreasonable deadline. I work in software, so it's usually very easy to predict how long a task is going to take.
In many cases, development is NOT "brainwork" (I'm assuming you mean the creative thought process, as you failed to actually explain what your imaginary word means). The company I work at provides customized software solutions for its clients. For each project, we listen to what the client wants and look at what they already have. Then, we try and create the best piece of software for their needs. This actually does require a bit of creativity since we have to guess exactly what they want. However, each project is built from the ground up using a template and the final product is designed using pre-made 'building blocks'. There is a fairly standard thought process and creativity is only employed at the time of the initial design, or when our template and building blocks are not sufficient to provide the functionality that we believe the client needs.
Scrum and Agile aren't intended to be used for highly creative works; you're right in implying that creative accomplishments cannot be predicted, but you fail to realize that there is a separation between creativity and development. In the work field, creativity is often only employed as a starter and a solution - it is used in the initial brainstorming and is also used when something doesn't work right, or if somebody sees a better way to do it. I'm going to assume you've never actually worked for a company based on your overall tone and bringing up the concept of refactoring. In fact, I'd like to point out the irony in you bringing up refactoring. Refactoring is pretty much only ever done when code is less efficient than it could be. If it's less efficient than it could be, then that means we know there is a more efficient method that has already been done before. It takes an incredible amount of time and intelligence to create a proof in computer science, so anybody that tells an employee to create a previously non-existent method to improve code efficiency should be fired immediately. If code is being refactored then it isn't going to take much creative thought because the developer can simply look up how something was done and replicate it in their own project. In fact, breaking a project into smaller tasks through Agile makes refactoring easier because the code can be isolated and tested in its own space.
dahoboman
"You are sadly misguided"
"you failed to actually explain what your imaginary word means"
"I'm going to assume you've never actually worked for a company"
Oh.. the arrogance...
You mention that your work is very repetitive ("we listen to what the client wants and look at what they already have") so sure it's easy for you guys to predict how long things will take. It becomes harder (even impossible) to predict when you're a developer in a startup, always doing new things you never done before. Even when it's things I did before, I have to do them each time using a different/new technology.
So scrum being incompatible with creativity, is not the only argument against the most-of-the-time insane practice of predicting the duration of tasks. Non repetitive tasks, new things and new technology for old things make it hard-to-impossible to predict - and sure, I can predict that a certain new task with new technology is not going to take me a year, but I can't know if it will take a day, 2 days, a week, or maybe it won't be worth the time and we'll drop it.
But surely if your work is repetitive, it's silly not to predict the duration of it. I can see why you like that. Work for you, good for you.
"Refactoring is pretty much only ever done when code is less efficient than it could be"
You think there is only your way of doing things, and you are very certain you know - when you don't. Have some doubt in yourself. Be a little skeptical. Maybe read "A study of Quality Improvements By Refactoring" by Bart Du Bois.
startxxx1991
Have you EVER worked on an actual project? You seem like a kid who believes that the typical project is like in highschool. Let me tell you, it's NOT that easy! Every bigger project is doomed to fail if there's no proper planning, and I tell you that from experience.
I agree with you that the monetary system isn't a fair place, but you just throw everything around with pure speculation, but no real knowledge behind it.
Next time, stop the speculation and actually take the time to educate yourself about a topic.
Great presentation! The best scrum overview in 10 minutes, loved it. I would like to learn more.
Thanks Hamid! Probably the best video I've seen on SCRUMs