Art by Ulla-Maija Koivula

If you don't know what Scrum is but are still interested about this blog, here's a small primer on what's going on. There will probably be more posts about this later too as Scrum is a pretty big subject.

This post works also as a explanation on how I personally see Scrum and what aspects I prioritise about it, so maybe this will explain some things even if you already are super familiar with the framework.

Framework is the first thing that needs to be explained. Scrum is a framework for building complex things. It's related to agile and in many cases when people talk about being agile or working using agile methods, the actual situation resembles Scrum a lot or at least borrows a lot of terminology and ideas from Scrum. For example sprints and product owners can be found in many places where Scrum itself is not in any kind of use.

But what does it mean Scrum is a framework? Calling it a framework is trying to communicate that Scrum is not an all encompassing solution for every possible situation. It's just an exoskeleton that holds things together and sets a limited number of surprisingly hard rules.

Inside these boundaries, teams are free to shape how they work.

Team is the next big subject. Scrum is a team sport. It's created for cross-functional and self-managing teams.

Let's unpack that next.

Cross-functional means that the team should have all the relevant skills to accomplish its goals. This might mean there are some coders and a designer and a tester and in the best case scenario all members of the team also know multiple skills so the team as a whole is more flexible and resilient. Also note that if the team needs six baristas then that is what the team should be. Scrum teams don't need to be just coders and Scrum isn’t just about building software.

Self-managing means that the team takes care of itself. They solve problems, teach themselves new skills and decide what to build and how and when. There’s no spiky haired boss who demands 123 lines of code are written hourly or anything.

In addition of the people doing the actual building (the development team) the Scrum team also includes a scrum master and a product owner. I'll talk more about these roles in separate posts, because this one will be long enough even without starting to go through those.

Then there are the sprints. Everyone nowadays has sprints but Scrum is most excited about them. Sprints are a sort of a mini-project that has a definite length and a definitive goal. For more info about planning the sprints and setting the goals, see for example the posts about backlogs and sprint planning.

Sprints are the way Scrum ensures that you have focus. You can’t change what you are working on while the sprint is on the way. You are committed to the sprint goal. This gives you a chance to both concentrate on doing one thing and (as sprints are short) also an opportunity to inspect and adapt qhat you are doing often. The other rule about sprints is that you always have to have something done after a sprint. Having something done is the only way to truly know if you are going in the right direction. Once you have something done and show it to the world, you will know if the world actually wanted what you built.

Scrum works best when you don't know much at all about anything except that it's going to be difficult. You try out something small (have a sprint, do at least one thing to done), then you see how it goes and how the done thing was received, learn from it and immediately do it again (have another sprint).

The difference is that in the second sprint you know infinitely more than before the first one, because you have now done something and received feedback from the world about it.

Then you just keep doing that until you are ready or the world tells you to stop. You keep improving everything while being protected by the Scrum framework. Many features of Scrum try to protect the team from being micromanaged and being interrupted. Protecting things is a big thing in Scrum in general. Some feel that this is only because Scrum was formed to protect coders from toxic work environments and if your environment isn't toxic, then you don't need Scrum. I feel that protecting the team from itself is at least as important. People tend to need structures to avoid backsliding into bad habits. Watch out for a separate blog post about Scrum values and accountabilities later.

Some think of Scrum as entry level agile, but I feel there's astounding amount of depth and wisdom in how Scrum is built. The goal of Scrum is not to build something faster or more efficiently or even with more quality, but to build something that should be built. Speed and quality and all the other nice things come with time when you have kept iterating and learning. The true promise of Scrum is that if you work using Scrum, you will have opportunities to learn and change direction or even walk away completely and that it won’t take years or cost you your whole business.

This is why I think Scrum and life are such a good fit for each other. There are few things as complex and hard to predict as a human's lifespan. Maybe accepting that and taking it one step at a time makes sense?