Scrum – Back to Basics

In this article, Anton Vanhoucke, scrum master of the first hour, gives 4 tools to help you separate the wheat from the chaff. Every tool and game rule of scrum can be measured against these ‘Agile’ principles. Do they contribute to it? Keep it! Having doubts? Try to leave it out as soon as possible. Maybe your process will run smoother!

Handle 1: Interaction between people over processes and tools

Scrum brings many new mini-processes and tools. It’s easy to get lost in them. You tend to come up with extra rules and conventions at every mid-term review. Or you stick scrum names on things you’ve always done. That way you scrum in form but not in spirit.

Because working Agile means putting people and interaction between people ahead of processes and rules. If it’s not quite working, it’s better to put your heads together than to further define your process.

And scrum itself, that’s also a process, right? Isn’t that paradoxical? The principle says interaction over processes, but it doesn’t say you have to get rid of all processes.

It can be so much easier. If only you look differently.

Take scrum story points, for example. In scrum, we assign story points to work packages. We do this to get a feel for the size of those work packages in the workload. Assigning story points is a group process that leads to healthy discussion: assumptions always come to the surface when you discuss why something is much or little work. It also ensures that a team can commit to a quantity of work packages. In practice, however, an energetic scrum master may end up assigning story points on her own. That seems efficient because you don’t have to spend as much time talking about them. But then you ignore the purpose of the story points and put the process above the interaction. You ignore the first Agile principle.

Handle 2: Products take precedence over administration and documentation

In scrum, we want to make things. Because it’s nicer to have things that work than to have things you’ve only talked about for a long time. Because you can learn the most from working things. Because working things are the most valuable to the end customer. Still, it’s helpful to keep some records here and there. For example, of ideas for features that you are not going to build right away. Or problems you can’t solve right away. Or of roadmaps you don’t go through every day.

It is important to always ask yourself: is it really necessary to write this down? Is anyone ever going to read it? Who? What is the purpose of this administration? Can I accomplish that in a simpler way?

Take scrum planning poker, for example: You can slavishly join every sprint planning meeting write and estimate all user stories with planning poker because that’s the way it’s supposed to be. You can also ask: If the purpose of planning poker is to uncover hidden assumptions and make the burn down fair, could it be simpler? What if we wrote all the user stories and just made them the same size? That allows you to work without story points. This doesn’t work in all projects, but it can lower the administration in your scrum project.

Handle 3: Working together takes precedence over negotiating contracts

You get the best out of a team when members feel ownership. When the whole team is challenged to work together to deliver business value. It runs on intrinsic motivation. Drawing up a classic contract, in which certain functionalities are delivered for a certain amount of money, has just the opposite effect. Then the project becomes a kind of coloring page, with the team coloring neatly within the lines. In scrum contracts, therefore, there is no defined project scope.

You use the scrum backlog – the work inventory – to have a healthy discussion about priority and degree of completion of project deliverables.

I have experienced a backlog being used as a contract. Then there is no longer collaboration, but a stick. The team starts putting its energy into dodging the stick instead of creativity.

Handle 4: Act on advancing insight over slavishly following a plan

When you start a big project, a plan is always handy. It helps you not overlook things. The trick is to be flexible with a plan. After all, such a plan is never made with a crystal ball: there is never a total overview of the situation or total insight into the future. You can almost take it on faith that things will turn out differently than you imagined.

An Agile and Scrum method such as scrum takes that into account and helps you stay flexible. But it’s not a guarantee. Much also depends on your mindset. For example, you may find that the standing workload can be handled better in a different team composition. Rigidly continuing with the same team is then a less good idea, even if it was so arranged and planned. It may even happen that at some point scrum is no longer the most convenient way to tackle the work that is on hand. Perhaps a kanban process is more effective. For example, if the team ends up in a service & support situation after the initial delivery.

Conclusion

If you are overwhelmed with a mountain of new rules and processes because you are applying scrum for the first time, you can always fall back on these four simple principles:

People and interaction over processes and tools
Finished products take precedence over administration and documentation
Working together takes precedence over negotiating contracts
Acting on advancing insight over slavishly following a plan
They help you prioritize and properly interpret the rules of scrum.