A part of my job is to debate with people about agile software development, sometimes, just analyzing discussions without taking part in it. I noticed one major factor that leads to arguments: misunderstanding. Two people may not agree on something only because they are simply not talking about the same thing, even though they are using the same words! In fact, words correspond to very different concepts or experiences in people. When the description is made using something that is unknown to us, we will first try, consciously or unconsciously, to link its properties to what we are already familiar with, and not necessarily take the required step back to interpret it globally by disregarding our existing knowledge. This understanding of things is partially or totally dependent on the subjective perception of the participants in a discussion. These perceptions are largely molded by the different cognitive biases that interact, self-reinforce. In psychology, we speak of heuristics in judgment. All of this can become very problematic in the context of so-called “psychological contracts,” where complexity emerges from these variable perceptions because of the positive (or negative) behavioral loops that become impossible to solve.

The debates can take long hours before we actually notice the problem, but in many cases, it remains unnoticed and everyone leaves with his or her beliefs and nothing changes. The fact that this article (and many others) exist is the consequence that there is widespread confusion caused by the creation of new terms to define similar (or existing) roles or behaviors. For example, the term “Carnism” or “Cisgender” create similar confusion and unnecessary division that prevents people from understanding each other.  Therefore, in some domains, knowing the good terms is so important that you don’t get your diploma if you don’t master them, such as in health or aeronautics. In some areas, using the right term is a matter of life and death.

What is the relationship with software development? The reason is that semantics are fundamental in the day-to-day work of knowledge workers and this is often the case with failed or poorly understood Scrum implementation. This goes from the very definition of a product owner to more fundamental things. But what motivated this post, besides my own observation of the problem (in many other contexts, as well), is the discovery that this phenomenon was much more widespread in the software industry than I thought and that it tended to annoy some (and that’s the least we can say).

In a recent blog post, Gregg Caines put it more gently, but very well:

When you want to get people to change the way they work, and you want them to understand the completely foreign concepts you’re bringing to them, it’s absolutely crucial that you name the thing in a way that also explains what it is not.

He continues with an example:

In Scrum, it’s also common to have a “sprint commitment” where the team “commits” to a body of work to accomplish in that time frame. The commitment is meant to be a rough estimate for the sake of planning purposes, and if a team doesn’t get that work done in that time, it tries to learn from the estimate and be more realistic in the next sprint. Developers are not supposed to be chastised for not meeting the sprint commitment — it’s just an extra piece of information to improve upon and to use for future planning. Obviously naming is hugely important here too, because in every other use of the word, a “commitment” is a pledge or a binding agreement, and this misnomer really influences the way people (mis)understand the concept of sprints. Let’s face it: if people see sprints as just more frequent deadlines (including those implementing them), the fault can’t be entirely theirs.

It is highly conceivable that Scrum defines new terms to impose a new way of thinking, as well (Agile Mindset). Ironically, this requirement is perhaps what contributes to the numerous failures of implementation of the framework, but also, and more importantly, to the proliferation of alternatives which infuriates its creator.

The lack of centralized and detailed information about Scrum can also contribute to the problem. The official scrum guide, with only a few dozen pages, is as highly subject to interpretation as your astrological sign of the day. The underlying psychological phenomenon for both is exactly the same:  it’s called the Barnum effect. It’s the tendency to interpret a general text to be specific to us. When it affects us, we filter the information and make it “match” our beliefs or knowledge, as I mentioned in the introduction. Sometimes it goes very far and I have already seen people develop theories about the functioning of the human brain based on sacred writings. This really makes me sad because the creator of Scrum probably agrees with me as they introduced transparency in the three pillars of Scrum along with inspection & adaptation:

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard, so observers share a common understanding of what is being seen.

OK, so far so good, but who benefits from the crime? Probably the agile consultants. It is possible for many of them to fill the electricity needs of an entire city simply talking in front of a wind farm. But how much does it cost? If I only rely on my experience to answer, I can attest that three generations of highly paid coaches are sometimes needed to make an organization understand agile fundamentals. Having been a “confluence archaeologist” several times, I can also attest that in some cases, it could never have been otherwise if the definition from my predecessors I read was the one submitted to the top management. They are not helped by the terms they need to promote.

That’s why I’m in favor of calling a spade a spade. Product Manager is the term everybody understands. It generally covers everything a “Product Owner” is supposed to do. I have the exact same opinion for the “Scrum Master” role (the “Servant Leader”), which creates further confusion, especially in different languages where the term servant is taken literally, and often leads to a “Scrum Janitor” or worse, a “Scrum Manager” in badly implemented Scrum. The guide mentions that it is simple to understand. I object. It also mentions that is it difficult to master. I agree. But one of the factors is definitely its inappropriate terms that create a breeding ground for misunderstanding. Therefore, a brave act would be to redefine the terms that would lead Scrum to the next level.

The sprint review meeting is crucial for you, the developer, because this is the time you will be able to both give a lot of visibility to what you are doing and also get the feedback necessary to better align your work on the real needs of customer and or users. Yet too often, this meeting does not achieve these objectives because it has been badly prepared.

Show what you have done

I would like to draw your attention to two of the main problems that may be encountered.

Firstly, showing the result of work that has no user interface, and then secondly making sure you show something that works.

For the first point, the difficulty intensifies when you are dealing with people who have never been programmers. They often do not realize that a developer can sometimes work for weeks for minimal changes to the user interface. In other words, they can hear what you have to tell them, but they cannot see it. The solution developers choose far too often is just not talk about it.  If you can’t demonstrate it – don’t show it.

This attitude is typical of personalities we technicians have.  It is undesirable because you cannot then get the views of your user on the progress.  Their understanding and view is much more important than yours.  You are first and foremost in their service, and not the reverse. Developers who comprehend this have a very significant advantage over others.

The best way to show something that will not be obvious in the user interface is to use a presentation slide that describes the change. Because every time you develop software it is supposed to add value, you must find a way to highlight it. Some examples:

• For performance improvements, clearly indicate the gain in a metric understood by the user.
• If you have completed some intensive code refactoring, you should be able to demonstrate the usefulness of the work by using metrics highlighting the reduction of complexity, testability, or other value that will in the long term give significant savings in maintaining the code.
• For the functions for which it is impossible to show something, such as support for a new source of information in a communication tool, do not settle for spending a few moments going through an a list of work done. Describe the challenges you encountered – this should give them the context that they lack.

In any case you should avoid sounding as if you are just justifying the time you have spent on the work.  The idea here is to evidence that you have progressed and that you are in control of the situation.

One last thing about the demonstration: Make sure you do the following things:

• draft a scenario that you will repeat to your users.  You must not just randomly chat about the project
• This scenario should cover most of the needs expressed by the client. This makes sure you are not interrupted by constant questions during the demonstration. In addition, this will allow you to ensure good feedback (we will cover this again below).
• Run the demonstration several times on the machine that will be used during sprint review. This should eliminate most problems.
• Rehearse it once or twice under the same conditions as the meeting. That is to say physically in the room with the same equipment.

Collect feedback

Great developers excel in this task. They know that developers who give the most satisfaction to their users or customers are those who understand and realize the things that bring their customers the most value. This type of profile is very rare and it is again very difficult for a technician to fully grasp this concept.

Everyone knows that the users are usually more comfortable when describing their problems than with finding solutions. There must be a real interaction between the technician who will eventually devise the solution and the person who has the problem. For this interaction to be productive, the programmer should be able to ask the right questions and discuss areas for improvement – and this is especially true during sprint reviews.

Many developers fear this time because they are likely to be criticized. This particularly affects perfectionists. Here are some tips to manage any negative reviews:

• Be aware that criticism of your work is primarily criticism of the latter – the work, and it would be inappropriate to assume that the customer is actually criticizing you.
• Remember that criticism relates mainly to the person who has made it and how they have interpreted the situation.

Having considered the two points above, we must consider every criticism as an opportunity for improvement.

Of course, all this also applies to positive feedback and I will write an article soon that will cover this in detail.

To summarize:

• You can show your progress and all your activities
• Feedback is an opportunity for you to excel in your profession

When I needed to do presentations of Scrum to executives and students, I started to look for existing ones. Most presentations I found were very good for detailed presentations or training. But what I was looking for was a presentation I could give in less than 15 minutes (or more if I wanted). Most of them also contained out dated content. For example, the latest changes in the Scrum framework were not present and what has been removed was still there.

I decided to start over and created a new presentation with the following objectives:

• Based on the official Scrum Guide: the structure is very similar and I attempted to extract only the essentials.
• Not more than 10 slides (without the front and back cover).
• The least text possible to extend the possibility for the presenter to say what is important to his organization without missing the core principles of Scrum.
• Having good visuals to make it attractive.
• A final invitation to read the official Scrum Guide for those who wanted more detailed information.

The result is a ten slide presentation that you can download then use as a powerpoint by clicking on the button below. Images are also available so you can use another presentation tool. It is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License (commercial usage & sharing allowed & encouraged). Feedback & suggestions welcome in the comments of this post.

UPDATE 14th of January 2018: I updated the slides to integrate latest Scrum Guide modifications.

Here are the slides preview:

Scrum Development Team

Scrum Product Owner

Scrum Process Overview

Scrum In Ten Slides Intro

Scrum In Ten Slides Credits

Scrum Sprint Retrospectives

Scrum Sprint Review

Daily Scrum

Scrum Sprint Planning

Scrum Definition Of Done

Scrum Product Backlog

Scrum Master