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.”
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:
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.”