Scrum is a means of creating small capabilities and testing to see if they are effective:
When creating a maze for your dogs you could spend 6 hours designing the maze, nailing wood together, and painting the wood to finalize the maze. Then you could take a few of your dogs and run them through the maze. You would find out A. If the maze is functional (is there actually a path from the begining to the end?) B. If it is doable by your dogs (are your dogs smart enough to get all the way through?) C. If it is fun to watch your dogs to go through (maybe the dogs can do the maze, but it is entertaining?).
If the maze doesn’t achieve all of these things, you will need to re-design, pull apart the maze and put it back together in the new arrangement. You may spend another 3-6 hours on this second part.
Test it again. If it doesn’t work, another 3-6 hours.
With Scrum: Instead of spending 6 hours the first time, you could spend 1 hour. It will be a smaller maze (or let’s call it the first part of the maze), but you have only spent an hour instead of 6. Once the first part is good enough, you can move to the second part, then the third.
How this is helpful:
- You spend a lot less time deconstructing and reconstructing for each test.
- Each section (iteration) you use what you have learned from the previous section. If you can build 10 ft in the first hour, by the 4th hour you might be able to build 13 ft or 15 ft of maze, and you have a better understanding of what makes it doable and fun.
- When building the 6hr maze, you don’t have a good understanding for “how much maze is enough” you might build a maze that takes your dogs three hours to complete (and that might be too long). When you build in sections, you have a running understanding of how long the maze takes (section 1 takes 20 minutes, section 2 takes 10 minutes and section 3 takes 30 minutes). If you want an hour long maze, you can stop working after 3 sections instead of after 6.
There are a dozen other benefits to working this way for specific products. I will also make note that a majority of the teams that “do Scrum” miss out on a lot of the benefits as they skip out on a lot of the effort (see: “We tried playing baseball”). I cannot blame anyone who is frustrated with “Scrum” or “Agile.”
It’s like trying to play football but everyone is just kicking the ball around.
I’m not so sure that it serves any useful purpose.
I think the simplest description is like playing among us and just being able to focus on your tasks for the round. The tasks get done and the goal is achieved. There’s someone there who should stop the imposter from getting to you.
The not quite an ELI5 answer:
It’s a small team of people focused on solving a problem. It is primarily used by people working in tech and with agile methodology.
When it’s done right and works it’s like the a team
If no one else can help and if you can find them. Maybe you can hire, The A-Team.
Scrum in itself is just a framework of work process. Designed to maximise the result of the work put in for a short period of work. No distractions, no interruptions. Just setting an achievable goal and committing to it. This works really well in agile environments, as it’s focused on short term goals.
These are buzzwords and are often mentioned without understanding or adherence. It’s difficult stay true to these in the real world.
There are people in the team whose job it is to keep all distractions away from those working towards the goal. As that just impedes it.
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems
The scrum guide is pretty brief and concise if you want further reading.
Wow, my brain does not work like that. I read so many individual words that have meaning for me but with so little overall comprehension. I don’t think I could be a programmer. It sounds like disorganised chaos and perpetual firefighting where there’s no overall plan and no one knows what their role really is. It seems so opposite to the stereotypes about programmers. I strongly suspect that’s not what it means and I just failed to understand but for just now I find it fairly strongly incomprehensible that that’s how you would deliberately try to run things.
It’s nearly impossible to plan. Sometimes a very difficult thing is done in minutes and then you want to add a simple button to the gui and it can take days in the worst case.
One time I had to add some kind of grayscale effect to a gui. Well, it was not supported by the gui system. So of course the boss told me to put it in there any way. It ended up taking days.
In the end it wasn’t even shipped! At least if it was open source I could have shared the work. So ya, it can be super frustrating. Especially if crunching is expected because your boss thinks its your responsibility.
It sounds like one simple idea meant changing things everywhere!
It can be like that. And hopefully you have a boss that has experience coding. But unfortunately that’s not the case all the time.
Its more a human thing: you have a big thing many people are working together to build, you have to organize somehow and make sure the thing actually is being built and does what it needs to do. Good companies do have an overall plan and good communication.
SCRUM is just one of many ways of organizing a project. It in itself isn’t really a programming thing even if it is most often used there, the general structure can work for just about every project that can be split in to multiple smaller tasks and sub-projects.
If your programming team is perpetual firefighting and chaos with nobody knowing their roles then that’s a sign of a bad organization or a lousy management structure. The last company I worked at was very organized. Status meetings thrice a week, clear seperation of responsibility, a good team lead divying up tasks the cropped up, and good communication between programmers.
Well that’s a relief. Thanks for explaining.
