On the importance of correctly defining agile software development terms

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.

8 reasons why the the Sprint Goal is highly effective to deliver value

The Sprint Goal, as defined by the creators of Scrum, is a selection of product backlog items that form one coherent feature, which helps a development team to work together rather than pursue separate initiatives. Ian Mitchell, a writer on agile software development, summarizes the usefulness of the Sprint Goal by writing the following statement on a blog post:

What we are getting at here is that the whole purpose of a sprint is to meet a Sprint Goal, and Scrum is framed to support sprint-based delivery. Take away the Sprint Goal and the rationale for using Scrum disappears with it. You might as well operate on the basis of continuous flow. Without a Sprint Goal to meet, sprint backlogs can serve no useful purpose.

The Sprint Goal is a description of the coherent increments that will be delivered at the end of the sprint and it provides guidance to the development team on why it is building an increment and how it should do so. If the development team discovers that they won’t be able to deliver that coherent feature during the sprint, they can negotiate the scope with the PO.

We can go even further by describing all the advantages of a well defined Sprint Goal and how it helps to get things done effectively. It helps …

  • The team to understand the purpose of their work beyond the description of individual PBIs, which stimulates intrinsic motivation and compliance. This leads to better implementation as the team can keep the big picture in mind. A well known man built an empire on this concept alone.
  • To keep the team focused on a small objective and avoid the negative impact of context switching. It can be seen as mini projects. These are clearly achievable multiple goals instead of a big one that is divided into chunks used to fill sprints (Waterfall disguised as Scrum). Focus is a very important concept to understand when you work with knowledge and creative workers (in the case of the vast majority of people in software development); it is probably the most important thing to work on in order to deliver value and quality to your customers.
  • The team to collaborate on a single objective with required flexibility and empowerment (cohesion vs individualism). This leads to better shared responsibility as the success of the sprint will be evaluated based on whether the goal has been met, instead of counting all the individual tasks that can lead to individual developer comparison in the worst implementation of Scrum. This helps in getting cohesion which is the most important factor for a high performing team.
  • The PO provide clear value beyond the selected product backlog items (PBI) and therefore improve prioritisation. This helps getting a realeasable product increment at the end of each sprint, which is the whole point of agile software development.
  • The PO to communicate on progress based on working software, instead of a percentage of a list of individual tasks that means nothing to the customer. This also helps to create a valuable roadmap to communicate to users.
  • The PO to get structured feedback from each meaningful increment instead of individual tasks. This provides the next sprints with new insights which automatically leverage the power of Scrum or any other iteration based framework.

The Sprint Goal, when properly used, is a proof that Scrum is understood and correctly implemented. Together with the (potential) release of a new product increment, this makes the Scrum Sprint really useful. Therefore, this is the first thing I check when I’m asked to audit an existing Scrum implementation. Sadly, this is the most overlooked artifact of Scrum, so if you begin a new implementation, start with the sprint goal and explain why it’s useful.

“Scrum in 10 slides” presentation has been updated

When I created the first version in 2012, I never suspected such a success. After a few years of practice in agile coaching and the resulting deeper understanding of the Scrum framework, I decided to update the slides with the latest changes from the official guide. I also decided to focus on some of the things that are not well understood in the many Scrum implementations I’ve had to observe.

First, Scrum is not always adapted to the environment that wants to implement it. Prior work on mentalities must be done. I specified that the Scrum Master was responsible for leading the entire organization towards that. The role of the Scrum Master is also in my experience, the most misunderstood element in the framework. Its related slide has been updated to allow you to explain what exactly a Scrum Master is doing on a daily basis.

Then, I also noted that important steps in the Scrum process were deliberately forgotten, often for lack of understanding of their usefulness. I added the notion of visibility and transparency of the backlog on the slide of the Product Owner but also the fact that the Definiton of Done could be the result of a reflection at the level of the entire organization. The slide on the Sprint Planning was already very clear about the usefulness of the Sprint Goal, but the importance of the latter is put more in the slide of the Daily Scrum which is undoubtedly one of the most important Scrum event but usually badly conducted by the team.

Finally, I made some minor corrections, for example in the elements related to the Development Team, the practice of Backlog Refinement which should not exceed 10% of the team’s time during a sprint or what is a Product Owner.

This should now allow you to address the most important elements of Scrum fairly quickly. If you have comments about the content or if you notice an error on one slide or the other, do not hesitate to let me know.

Download the latest version here.

The actor–observer asymmetry

There is a difference of judgment in any activity depending if we are an actor or an observer (Malle, Knobe, Nelson 2007). I realized this fact when I was practicing martial arts, long before my studies in psychology. The audience, usually parents, downplayed the difficulty of the discipline and very often judged the activity incorrectly. One of the most common expressions was, “but it is only dancing.”

This comment annoyed many of the new practitioners, but not the more experienced who knew that this was a gross misjudgement. You could see the difference when these same people decided to try the discipline once. As you can imagine, most did not usually go beyond the first attempt as it was physically demanding and much more difficult than they had imagined. Their judgement of the activity observed radically changed when they became an actor.

In our everyday life, we alternate between the positions of observer and actor. In both situations, we make judgments and many of the various decisions we take are based on them. As an observer, we can judge incorrectly the behavior of others. As an actor, we take into account the judgment of observers. It is important to recognize these situations and act accordingly.

Let’s take a concrete example: starting a software business. This is a subject dear to my heart as I far too often watch the growing disillusions of entrepreneurs when they take in the reality of things. As the disillusionment grows, only those predisposed (very rare) or those working for pleasure keep going.

The reality is that entrepreneurs work very hard and take on tasks that we would probably never have agreed to do as an employee.  You must also be aware that very few projects succeed at first; most stop after the first failure.

When we see talented entrepreneurs in the newspapers, we think it’s easy and as simple as registering a domain name, writing 10 lines of code and then selling your company for millions. The reality is that most successful people have worked hard, often in physical and psychological pain, for many years and have faced all kinds of problems. They made the difference by persevering. All my successes have been preceded by hard work and pain.

It is difficult to realize this when you have not been there yourself. But how do you know before you make a judgement or take an important decision?

The first step is certainly to become aware of any bias and take it into account. It is very difficult as these behaviors are unconscious and judgment is rooted in how we operate.

When you realize that you are in an observer’s position and about to judge and eventually take a decision, you should not be satisfied with the information available. As you may have noticed, observing is insufficient to get an opinion, even if one is aware of the bias. Failing testing it yourself (and you can’t start a business as a test in the same way you can attend a single martial art class), the only solution is to ask questions of the actors. Those who have experience in the field or are in the situation. Do not just question one of them. The more people you question, the more relevant your information.

The only concern with this approach is that it can block you from moving forward. Indeed, if you ask too many questions you can start to stagnate. Everyone now knows that one of the primary qualities of an entrepreneur is his ability to move forward quickly. Many are also characterized by a certain impulsive trait which will be discussed in a future article.

Awareness of the actor / observer asymmetry is directly related to critical thinking: identifying biases, separating fact from opinion and analyzing data. Awareness of our mental functioning is, again, the key.

Why the sprint review is important to developers

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