Do you recognize this? You are not happy about a person, a meeting, or a result. And you complain to someone about it. The answer you get: that’s how Scrum works. OK, most of the time this is not said. But you get an explanation that the person you complain about, is doing their job according to Scrum. Or that the meeting is held according to Scrum. Or the process is according to Scrum. Result: it complies with Scrum, so it’s good. If it’s not, it is probably you.

A manager who writes down a set of rules to achieve a goal, but does not check if a goal is achieved, is seen as a bad manager. And rightfully so. Scrum was written as a set of rules to achieve some goals. But almost no company that implements Scrum checks if those goals are achieved. I’ve seen bad Scrum masters, that make sure all the meetings are held according to Scrum. Bad product owners, that make sure the product backlog is determined only by them. And bad developers, who are very independent and give feedback.

Scrum itself doesn’t help. There is a lot of information about what you should do, but not a lot of information to find out if you are doing it in the right way. When you read about Scrum, it’s mostly about what you should or shouldn’t do. Not much about how that thing what you do is done right.

The standup is for me the best example. You can see if it’s mentioned what is done, what is going to be done, and if there are impediments. But if the impediments are the same as last week. Or if a person is working on something for 2 weeks and saying every time he/she will be finished today. Is the standup really working?

How do I believe it should be? Let me take the three pillars of Scrum as an example.

Adaptation

Good adaptation is based on new information. This new information can be because the situation changed. A deadline has moved, the company has a new customer, the Agile team gets a new member, a new bug is found. Or you find out that you were missing information: the risk is higher or lower, the costs are higher or lower, the change is more complex.

Bad adaptation is based on the same information, but the decision is now different. Something is now less or more important because someone spoke to the manager. Priority changed because the deadline all of a sudden is very close. A meeting is canceled because people complain about the number of meetings.

Now, you could say: but knowing that people say that there are too many meetings is new or missing information. Yes, it’s new or missing information. But it’s not new or missing information about why the meeting is held. So it should not change if you have the meeting or not.

Inspection

A good inspection results mostly in improvements you can do yourself. When something goes wrong, the result of the inspection is not often ‘There’s is nothing I could have done to prevent this’. I am realistic enough to know that that can happen, but it should be the exception. I have seen many persons and teams where this is almost the rule.

A good inspection also looks at whether goals are achieved for improvements. This means that, if an improvement is done, but the problem still isn’t solved, you adjust the improvement. Or you reverse the improvement.

Bad inspections see a lot of problems as caused by external problems, completely out of your control. Or are done by checking if promises are kept and/or tasks are performed. And when that is done, the topic is closed.

Transparency

Bad transparency goes no further than: everyone can see everything. You can see the product backlog and the sprint backlog. You can read the stories. You can find the definition of done.

Good transparency is also based on understanding. When there is good transparency, people can understand why a priority is this way. Or why a group of tickets is in the sprint. When you talk to the Scrum master, he can tell you in words you can understand why the retrospective is held as it is. A developer can explain to you why a story is 8 story points.

You can show all the information you have and everyone might be able to find it. If people don’t understand it, it is still not transparent.

So, now what

If you want to implement Scrum correctly, there are two things you can do. Try to find out why the rules are there. And check if the goal of these rules is achieved. Adaption should lead to a better product, process, or team. Inspection should lead to good adaptations. And transparency should make it possible to inspect properly. And so has every rule and line in the Scrum material a goal. And you are only doing it correctly if that goal is achieved.