What's in a Framework? The Scrum Guide 2020

So, The Scrum Guide 2020 is released!

The collaboration framework Scrum has been around in one form or the other since at least 1995. That was when it was presented at the OOPSLA conference in the USA, as one of the early attemtps to codify what smooth and nimble collaboration around service development could look like.

There has been a lot of development to it through the years. People have been trying its practices, modified them, and starting to understand when and where it's time to use them. Especially the wording around things has evolved.

In a sense, an upgrade of the Scrum Guide is an important event. Because the words in it have impact. People care for what "The Guide" says, and are affected by it.

But why? Why does the Scrum Guide matter?

Agile ways of working are basically about a collaboration trying to become more flexible, by adhering to a set of values and principles. So what is exactly the role of frameworks here?

Let's Go Back

During the 1980s, systems development had started to become a more common activity in business. And with the advent of commercially available internet in the 1990s it became even more so.

Many organizations had tried to combat the growing pain of systems development by trying to organize it as they organized much of the rest of the operations (not business development, business operations):

• Functional specialization: Special IT folks in special IT departments did all the IT things, including systems development.
• Internal hand-offs: People in other departments "ordered" systems development from the IT department, like they were some kind of a customer instead of a colleague.
• Pre-planned activities: The development of both new systems, new ways of working, and new ways of doing business (these three often go together) was regarded as a series of activities. The organization viewed the problem with development mainly as being able to identify all of the activities, and understanding precisely when each activity should be made, by who, and at what cost. As early as possible, so we can put everything in a plan to follow.

Let's Go Even Further Back

For what now seems like obvious reasons, this didn't work out well. The track record for the system development projects from this era is terrible. The number of projects that could be called even vaguely successful were abysmally low.

The thing is that these were obvious reasons for failure long before the 1990s. Experts in the field knew since way back that you can't build good software this way. IBM had warned for the idea that you could pre-plan large system development projects for long. They wrote about it in their manuals they sent out with newly sold computers in 1969 (the year I was born).

So while some tried to combat the growing failure-rate by having even more specialization, even more explictely worded hand-offs, and even more detailed plans, others went the other way.

Dusting off old practices. Of collaboration. Of short iterations where the understanding of both problem and solution grew for all parties. Of constant replanning

And, lo and behold, the old methods from the 1960s and 1970s did work! With some modifications though. They had to deal with the fact that systems in the 1990s were way more complex and had higher demands on them, than those developed in the 1970s.

The modifications of the old ways of working led to new ways of working. People started to collect their favorite practices in toolboxes and frameworks. And started to label the toolboxes: DSDM. Crystal. Extreme Programming.

And Scrum.

You Must Do Something!

After a couple of years, these pioneers gathered and tried to answer the question of what they had discovered in terms of successful software development. They came up with a bunch of values and principles, like:

• It is about collaboration.
• We are here together to meet the customer's need, through fast and valuable changes to our services.
• That is a discovery process, so we shouldn't try to plan it in detail.

(Their exact words in the Agile Manifesto aren't exactly these but the essence is there.)

Note that these principles and values were put to words after the methods came to be. Before the manifesto, its writers tried out for many years different pragmatic ways of collaborating. They found out what worked and what didn't. They presented it to each other, and learned from each other, and improved. On their day-to-day job.

And then, as an afterthought, they tried to capture their common principles and values in words. In what became the Agile Manifesto.

Just thinking about principles doesn't create change. Changing the actual way you work does. So how you collaborate is important.

The Role of a Framework

The most important feature of a framework is to inspire people to try out new helpful behaviors.

Take Scrum for example:

• It can be helpful to work tightly together with people who have different competences, if you have a joint responsibility for delivering something complex.
• It can be helpful if these experts have the authority to make important decisions about how to create value.
• It can be helpful to have a clear and shared understanding of your priorities.
• It can be helpful to plan a minimum amount of time ahead, just to get the service to a new and improved state.
• It can be helpful to look at the improvement together with other people, and get ideas about the next steps.
• It can be helpful to also continuously improve not only the service but also improve your ways of working together.
• It can be helpful to share where you are and make room for a small replanning, everyday.
• It can be helpful to have a coaching servant leader of the whole process. A person that facilitates the collective decision making needed for this to work.

Many practices also fit together, and are the most effective if they are combined. That is something a framework can inspire to: Please use this framework in its entirety, since all parts need to be in place.

Sometimes that is a helpful attitud: we need to use many or all parts of a framework. But sometimes it isn't, and we should go for just picking one or two of the practices. The framework invites us to experiment to find out what's best in our own situation.

The Process Trap

But a framework for development can also inspire some very unhelpful behaviors.

An organization that doesn't really understand service development might act as they did in the 1990s: believe that development is a kind of operations that is best managed as a set of activities. And that the purpose of the framework is the same as for a well-defined process in a controlled environment optimized for repeatable operations.

An organization with those beliefs will treat a development framework as a definition of best practices, and maintain that strict adherence to the rituals and movements of the framework will automagically produce excellent results.

Which, of course, is an illusion. For the same obvious reasons that we have already mentioned: Productive development is an effective discovery process. The frameworks can suggest some practices and tools for this, but in the end it will be your skillful application of them that determines your success.

Your skillful application and your collective understanding of your situation. What in your current way of working is blocking you? Can elements from this platform be of any help when it comes to removing the blockers?

There is no magic involved.

The New Scrum Guide 2020

Regardless whether you actually use Scrum or not, I think that there can be good inspiration to find in the new version of the Scrum Guide. Scrum is such a neat little package of some of the more common practices in the agile world, so even if you don't use Scrum, I bet that you use at least some of the practices described therein.

And I think that the new Scrum Guide overall gives us a better explanation of the practices than its predecessors. Especially regarding three important concepts:

• The concept of value.
• The concept of empiricism.
• The concept of team-work.

Because, organizations stuck in the process trap often misunderstand precisely these three things.

They do stuff, but don't understand how the stuff connects to value.

They have whiteboards and other kanbans, or use an electronic equivalent such as Jira. But they don't use it to visualize the important things, and don't use the visualizaton to make new decisions together, based on new insights.

They have "teams", but don't grow the ability for the teams to decide anything important. So they miss a lot of improvement opportunities.

Do This!

If you do Scrum, or some other framework, or if you are considering it: take a minute and think about this question:

"What is the purpose we have for looking at a framework? How will a framework help us?"

Actually set aside that minute and write your purpose down. For yourself.

Now, the next part, which is the important part: Ask someone else the same question. Preferably a person you intent to collaborate, and maybe use a framework, with.

"What is the purpose we have for looking at a framework? How will a framework help us?"

Ask them to write their answer down. Then you compare, and discuss. And if you can do this together, in a whole team, the better.

More to Come

I have a reflection or two on these three areas in the Scrum Guide:

• The concept of value.
• The concept of empiricism.
• The concept of team-work.

Plus a thought about when Scrum and its Guide can be less helpful.

And I promise to not keep them to myself, but to publish them. So look out for more!

I Can Help!

If you want to receive some help around understanding Scrum and other frameworks, just let me know!

Be it workshops, trainings, self-study material, or something else.

Or if you want a more helpful attitude towards the agile frameworks established in your organization.