When we want to change our behaviour, we have at least two ways.

One is to start with the basics. Learn about facts, basic principles and values and work your way up from there.

The other is to find clear guidelines. A well-defined process. Something that gets you moving fast and gives you a sense of safety and confidence.

These ways might seem contradictory. Both have their pros and cons. Both are being discussed all the time by people trying to find a correct answer.

Nowhere is it as visible as when it comes to agile development.

Some people like to use a well-known framework like Scrum. Others complain that following any specific process stands in a clear opposition to the heart of being truly agile and limits one’s ability to innovate.

So, which group is correct? Are standards like Scrum always bad? Or maybe there is some value in them?

Two ways to learn

If you want to understand something deeply, you have two paths to learn. For the sake of this article, let’s focus on learning how to become more agile.

Start with the basics

The first path is to start with the basics and work your way up from there. In this approach, you would start with the Agile Manifesto. You would think about each point and try to figure out what it means to you.

“Customer collaboration over contract negotiation”. How to achieve that? How can you increase customer collaboration? One way is to have meetings with a customer often. The other is to have a customer do the actual work with you. Another one is splitting work into smaller parts and asking for feedback often.

“Responding to change over following a plan” What about this one? Should you stop planning at all? Maybe plan for shorter periods of time? Maybe just focus on the goal instead of planning specific tasks?

The point is that we can come up with many ideas based on the values we believe in. Each team is different. Each product is different. By focusing on values, we can craft an individual solution. A process that’s tailor-made to our specific environment. And knowing that a process will never be perfect, we can reiterate, adjust and improve on a daily basis.

Start with a framework

Starting with values seems like “the way” to do this. The problem is that it’s not easy: It requires time and patience to come up with different solutions and try them. It requires a proper mindset and readiness to break existing habits. It requires being extremely open minded. It requires a will to risk being worse for some time in order to get better after.

Some of these issues can be mitigated by starting with well-established guidelines — a framework. Instead of crafting our own process, we can start with a framework like Scrum.

Starting with a framework provides a few potential benefits: A common process that is well-tested by other people, which reduces a risk of failure. Community support. A lot of people are doing Scrum, so we can easily find a common language with other people and ask questions:

“How long are your sprints?”
“Do you do daily standups?”
“What do you talk about during retrospectives?”

We can ask others about their problems, ask for advice, read a lot of content online. A clear message to the team that says “Our old way was wrong, let’s try something else now”. Changing the current way of working may be hard. People often get used to their problems. “That’s the way we’ve always done it” is a pretty common thing to hear. By “forcing” a specific process, we can accelerate the process of forming new habits.

One of the biggest obstacles to changing behavior is uncertainty. If I’m confused with how to do something, I’m very likely to fall back to an old habit. Starting with a specific process gives me clear guidelines, which eliminate uncertainty. It directs the Rider. Following a clear process allows us to change our habits more easily.

Of course, the new habits will not be perfect. There are risks of following the process without understanding the values and principles behind it. Cargo culting is one of them.

All frameworks are just the defaults

Frameworks are not rules. They do not tell us what to do. They guide us towards some goal. This is the role of Scrum. It guides us towards a more agile way of working.

Scrum gives us the defaults, which have a pretty high risk of working for your team. At the same time, it gives you a way to change the default that does not work — this is precisely what retrospectives are all about.

To me, it’s all about the constant improvement, not about what you do at any given moment. I’m always confused by people that used to follow Scrum, but now complain about it. They say that they have found a better way. They are doing things differently. In a better way. They no longer follow Scrum blindly. And, unfortunately, they advise others not to follow Scrum either.

That’s an absurd! I’m sure that what you do now is in fact better for you. But it doesn’t mean that there’s no value in following a different process. It doesn’t mean that someone following your way will succeed.

Values or process?

So, which way is better? Is it better to start with values, or choose a well-known process and evolve? While there is no correct answer, I feel that the important factor is how experienced you and the team are. If you have a lot of experience working in an agile environment, you might not need a framework. You understand the values and you can be the guide a team needs. You’ve probably seen a lot of problems and you can identify and solve them without a framework. An experienced team might quickly come up with a process that’s better than Scrum’s defaults.

If you’re new to agile development, on the other hand, a framework can be useful. You can start with a proven process and build new habits. As you’re working, try to understand the values behind the process. Each week, identify what’s working and what’s not. Identify what parts are annoying. Try to understand why. And change it. It can take more time than starting with values, but the risk of failing is lower.

I have a plea to more experienced people, though. Just because you can find your own way based on values only, don’t ignore the role that frameworks like Scrum have. Continue speaking about values. Continue pointing out disadvantages of the frameworks. But don’t condemn people using them. These people need guidelines. Your role as a more experienced member of a community is to support them on their path, rather than force your own one.

Not only agile

This approach is true for any complex problem, not only Scrum and agile development.

When it comes to software development, there are many guidelines and rules as well. A class should have no more than 100 lines of code. A method can have no more than 10 lines of code. Each public function should be tested. You should write the test before you write the code. You should deploy every day.

If you want to get in shape, you can start reading about human anatomy, muscles, nutrition. You can choose exercises that are optimal for your body, your current shape. You can count calories, macro elements, build each recipe from scratch. Or you can find a proven exercise plan and a diet. Is any option better than the other?

The rules and processes we follow are not objective facts. They don’t guarantee success. These are just guidelines. You can follow them to build good habits. At the same time, you can try to understand the underlying values. You can learn how and when to break the rules. But you don’t have to follow them.

The path you take depends on you. The only sure thing is that none is correct and none is wrong. Regardless on which path you take, there’s no one final destination. As long as you strive for ongoing improvement, you’ll be fine. So enjoy the ride!