This is a quick and dirty rundown of the methodology. You can can google the history if you like but it has been done to death by many already. If you are reading this then you ought to already know it well enough.

So what is the point of Scrum really?
Some would argue it is an agile method but only in a certain way actually. It is still a very plan heavy methodology that quick devolves around metrics and estimations rather than responding to changes happening in and outside of the team. What a lot of people rarely acknowledge is that when you have made a plan people don't want to deviate from it. Very often people tend to stick to planning because it feels like it is too much work to redo the planning even when you know it is flawed. This basically comes back to an old fallacy, sunken cost. We have already spent so much time to make a plan in the first place it feels better to try to follow it rather than picking at it. Like it is a house of cards but with infinite stakes. And while that may feel true, it never really is. It is just an idea of a future. One of many. Things change with your perception of the thing. At least if you are not dogmatic and or refuse to change your mind for some reason.

Which is perhaps the other reason people rarely want to change a plan. It is an admission of being wrong in the first place. Because it is more important for your ego to be right rather than admitting that you didn't know everything before you started working. But as most whom has done this work often enough, in any trade really, you never know what the future holds in terms of surprises. If you knew everything before hand you could have just generated the work with a machine of a sort. No skill needed at all. Which is why we do the work we do, it is not always obvious what actually is the problem.

This is the thing to remember though. Problems are different to tasks. A task is easy as we already know what to do with it. Clear the dishes, fold the laundry and so on. These tasks are generally very easy to work through and contain very little in terms of surprises. What most people work with within Scrum is usually not known issues. It has to do more with wishes and re iterative solutions. Once you have tested a certain thing you also know what to improve on. This is a feature. Once you have one it is easy to reiterate on them. But before you have it there is nothing. Sure, you can draw inspiration from things but there is no actual underlying thing for it.

Much like this site. I made a very basic template from an old way of doing it, 960 design. Is it perfect? Not for me, for looking at the site in the phone? It works. Did I make a big plan up front or did I wing it? Yep, winged it. It actually got the CSS, html structure and php done alongside with the setup of a work environment and all in less than workdays really. Why? Patterns. More precisely, it is a simple workpattern for each where I fill in the details. Is it how we work? Generally, yes. We all have basic patterns in how we solve things with our problems. While dinner is not the same as last time and recipes change over time there are some basic shortcuts we can make. If you are making a curry, do you make the spice mix from ground up every time or do you have a ready to go jar with a favourite mix already? Do you need a certain vegetable or can you do it with whatever? Indeed, most whom are comfortable with cooking will not even consider that as an issue. Why? Because it isn't. The underlying principle of cooking has little to do with the spices, the protein and the rest. You know so well what each step is that detailing every last step is kind of pointless. Yes, it will take time to shop, prep and actually cook it but they are all pretty finite.

What does throw you for a loop most likely is when your partner suddenly requests a steamed fish dish with potatoes and a salad to match. Is it harder? Perhaps but not by much. The thing that is hard is to change midstream. Most people are change adverse when they have already committed to something. Having to buy new things for the dish, maybe a little wasteful but by puch unless we have already prepped it but still, one can make it tomorrow instead. If it is already on the stove, sorry but dinner is served?

So what makes it Agile and or Scrum? Pretty much what people think is that Agile means do whatever you want. And no, that is not. It is whatever the customer asked for, good or bad. Within reason. This is the crux of it.

Lets consider these two parts of the Agile Manifesto

• Collaboration over Negotiation
• Responding to change over following the plan

So back to the dinner. When does it gets to the point that responding to a change of plan becomes too much work? This is the thing that is the pain point that most shy away from. It is easier to be on either side where the default is defined and easy rather than being in the middle. However if you read the manifesto you and actually worked with through it aside a simple case study you know that you need to be in the middle of them. And they are interlocked to the point that if you ever side fully in one direction you are by default failing in some way. This is where the problem lies with Agile overall. You will be wrong a lot of the time and mostly it'll be in the details. This is normal if humbling to be off and find unknown problems in what you think are fully known stories. So while we tried to fix this from the start by going over the stories and breaking them down this still comes up. As with cooking food, depending on what you are doing, you might find your self having to improvise.

So while when you start collaboration and responding to changes is easy, the further along you are the harder this become. At some point it just comes to a steep of price to actually do something other than the planned activity. It might seem silly because it becomes trivial with food. With a project spanning months it might seem like a stretch but the same is true. The shopping and prepping is more akin to deciding what to be done and getting the resources in place to make the feature, the dinner if you will, to get it done. But as with the dinner, planning, grooming and the like is just a little time in the totality of things. Getting the infrastructure, environments, and the tools to start developing, prepping if you will, is also not that expensive usually. Even when you have started the development cycles you can still pivot and change. But coming more than halfway through it might be getting more costly to change.

The true point is when you can't reuse what you have done already for a new thing. This of course can come very late into a project that you can not pivot anymore but generally it comes down to what I eluded to above, the sense of not being able to rather than actually being able to. Because of the invested time you feel you have spent setting up the planning. Which is a false sense of work. Planning in any tool makes it feel even more permanent. Much like writing this text. Never mind the two days spent writing up the software and the rest. Rewriting this text, now two hours of work feels even more permanent than the code. Why? Most likely because rewriting and rethreading the same thing makes it feel like repeating your self. It also might feel hard as this rarely practiced by many. You feel there is nothing better than what you have already done as you have invested so much already.

But as with food, once you have attained some skills in it gets easier to change what you are making midway through. Once you stop following recipes it becomes almost trivial as you will just use what you have to make something that you like rather than focusing on having each part as described. Same goes for a software project. When you begin you might stick to one particular that you have learned and everything else seems a dangerous proposition. Once you have dared to use a few others you start to see it as another tool. And then you look into a different kind of database type and when you have learned its differences to what you knew you start to see the similarities instead. Same with programming languages. You will have preferences but you can make do with the odd things as well as you learn how to work with them. But before that, asking to work with a new piece of technology always feels like a daunting proposition. The same goes with making a plan and their tooling. Once you have worked with it for awhile you start to see the corners of the puzzle. Writing an usable story gets easier, less need to be written as being succinct gets easier. Much like a chef that is well versed in his trade, he needs less to astound you with his skill of making food.

So what is the point of Scrum really?
To make plans that we throw away as we find out more about what we need to do. Is this revelatory to you? If so, are you the apprentice, the journeyman, or the master?
Trick question really, whatever title you claim it is probably wrong as we all have our blindspots and egos. This might make it seem like I know all the things I need to know to be a master but in reality, there is a lot I have probably forgotten, never been informed of, or just plain ignored to my own detriment. But that said, one can always improve with time and experience. So that is the conclusion of this train of thoughts. Scrum is mostly about making plans we try to execute where most of them are thrown away or adapted upon in the process of making what was asked to begin with.