One of the most important features in agile software development is continuous improvement. Although origins of that feature stem from lean principles and not directly from the Agile Manifesto, I can hardly imagine a real agile team without some sort of continuous improvement process on board. That being said, many agile specialists perceive that process is difficult to introduce and cumbersome to continue once it is set up properly.

Defining the Problems

Let me start with an example. Once I worked with a team of highly motivated developers who, when asked to pick some areas that could be improved, named dozens of them within a few minutes. The team was detached from architecture and process design activities, as all those tasks were outsourced to consultants so that the team could focus on coding only. Furthermore, estimates and tools were established by IT team leaders—again, not to disturb developers from their main task of adding code to the codebase. Those actions were not only counter effective, but also painful to all team members who felt like there was no credit given to their skills in the company.

Fortunately, making change happen was a relatively easy task because as a leader of agile transformation, I was able to settle with managers that all those practices would be discontinued. IT team leaders worried a little about a quality decrease, but the team members possessed enough skills to successfully start handling new responsibilities. In order to minimize a potential decrease, we asked consultants and leaders to help the team managing the new tasks—at least in the beginning. Afterward we had a few more pretty good retrospectives, and the prospect seemed fine.

At some point, however, the team declared that they had already solved all issues and there were no other ones they might think of. I could hardly agree. They had an impact on architecture, but their changes did not help so much in setting up functional automated testing. Additionally, each sprint business was declining way too many user stories based on failed acceptance tests.

I tried to encourage the team to refactor architecture to enable building functional automated tests, but this gave only mediocre results. We discussed a few ideas from architecture books, but that sparked not so much enthusiasm either. They found all those ideas too abstract and argued that related success stories were useless to us because all of them were working in a completely different technical context.

Eventually all team members agreed that nothing could be done to improve quality, so we should stop any efforts to change the process. I was deeply surprised by their resistance after all those good retrospective sessions.

In the following years of my career as a team coach, I had a number of similar experiences. The teams first start with enthusiasm for continuous improvement and pick issues to address. In my opinion, the initial energy comes from the allure that the agile team gets a forum for discussion about issues they have been struggling with. All hidden or ignored flaws that have been hindering the team finally will be taken away. But their enthusiasm declines over time, and at some point the team declares either that there are no issues left or that the issues are inevitable. As a result, the team suggests (sometimes strongly) to stop the continuous improvement process completely.

Agile makes a team the owner of its process. That brings about a “yes, we can” feeling that eventually leads to more intense acting on problem solving. However, what is going on later? The team addresses the most painful and often relatively easy-to-solve issues first. Issues that come afterward are harder to define and address. The team needs to rise to the new challenge.

There might be a hidden yet strong belief among the team members that no matter how hard they try, some class of problems cannot be solved. Consequently, nobody picks them during the retrospective. Even if a cumbersome issue does become visible, there are many reasons it could continue to go unaddressed:

• Solving the issue would mean changes in other teams or in the organization of the company. (Example: There is one centrally managed release process that imposes a global code freeze on every team.)
• The issue is complex and cannot be overcome at one go. (Example: The number of user stories that fail the acceptance process is too high. This may stem from various concerns related to the process or technical aspect that cannot be efficiently tackled at once.)
• The team has too little or no experience with a particular topic necessary to improve the situation. (Example: The technical architecture needs serious refactoring.)
• The team has tried hard before but their attempts failed due to lack of cohesion, ineffective self-management, or unrealistic expectations (that they set themselves) and now they see no reason to carry on with adjustments. (Example: Instead of using short leaps, the team decided to do a big refactoring step that proved to be too difficult to finalize.)

Eventually a feeling emerges among the team members that there is nothing left to modify, or any modifications do not make sense. This is a critical moment in the team formation process because if they stop finding issues and acting on them, the team will not instill habits necessary to perpetuate continuous improvement. As a result, team members might work on improvements against their will (and do it only to satisfy their managers), and consequently the retrospectives’ outcomes will be insignificant.

Why Does a Team Stop Improving?

First, I want to stress that this article is not about teams who struggle to get through existing problems that cannot possibly be influenced (like if an organization refuses to cooperate and there is no way to alter this behavior). This article is about teams that stop improving because they believe there are no issues present or the issues are unsolvable.

So for the purposes of this article, I will assume a team is able to deal with a problem. Perhaps the team needs to expand its knowledge on a particular subject, build better relations with other teams, or seek help from a consultant, but eventually team members will be able to carry out necessary changes that bring about improvement.

However, if a team avoids or refuses to address a hindering issue because of its difficult nature even though the team could possibly resolve it, then we have the problem of the team not seeing the need for improvement. And if a team does not take or refuses to take the necessary measures and instead discusses negligible problems, we have the same problem. It is not always easy to solve an issue.

In a retrospective, the team members should get together and discusses their progress. During the discussion the team picks the most painful issues and then plans actions to resolve them. After one iteration the team assesses their efforts and settles on further steps based on this assessment.

But things do not always go this way. I have a hypothesis:

A team may act efficiently on an issue if either the issue comes from a well-known domain or the team is able to make the mental model shift necessary to tackle the issue coming from a new domain.

Let me illustrate my hypothesis with a few examples.

• A new JavaScript framework has proven to work better than the one currently used. However, the new framework handles events in a slightly different way and there are some data translations that must be done. In order to deal with those issues, the team members can use their current knowledge, while the new issues have only a local impact on the system the team is working on. Solving those issues fits the team’s current view on how to develop software, so this change can be done without a mental model shift.
• A team wants to introduce end-to-end functional automated testing. It needs to design a system response that is read and asserted by software instead of an end-user and also needs to inject test data in the database. Previously, all software interfaces suited humans only, and the database was tightly coupled to the middle layers. To satisfy the task, the team members must replace their mental model of “the proper” application architecture and data modeling with a different view. They read blogs, articles, and books on how to do it, but if they make no mental leap, they will try to understand the new architecture principles through a filter of a previous paradigm. Although this may prove to work locally, it is likely that the overall architecture will still stand in the way of automated functional testing, so a mental model shift is inevitable.
• The responsibility of scheduling test environments and testing cross-system concerns has been given to development teams from the software integration department. Before, teams could develop in relative isolation, and all interfaces were designed by the former integration department. Realizing how one team influences another in the multisystem complex environment is tough. Another challenge is to start working with people a team hardly knows without any understanding of what they actually do. The mental model shift from working in isolation to efficient cooperation will be a big step to everyone.

I think a change from one set of views, habits, and logical structures to another is what enables teams to further improve their work, unless an issue resolution lies within current well-known domain. Consequently, the need to change a mental model also relates to teams that stop improving:

Teams that struggle with a mental model switch will at some point stop or significantly slow down their improvement rate, regardless of their previous performance, because it is impossible in a complex environment to deal exclusively with problems from a well-known domain that can be solved without a mental model switch.

Before I propose some tips for how to support teams when the shift seems too difficult to make, I am going to describe results from two scientific inquires that shed some light on how mental models affect what we do.

Two Scientific Results

The first result comes from a beer distribution game created by MIT Sloan School of Management and then simulated uncountable times by Peter Senge.

The goal of the game is easy: You sell different sorts of beer, acting as a shop owner. At some point the demand for one sort of beer rises unexpectedly. The shop owner must react by ordering more of the demanded beer. But here is the catch: The beer cannot be produced enough to satisfy all shops at once because the breweries need to adjust their production lines. The average person playing the shop owner role continues ordering even more of that beer from the wholesaler. When asked why they kept ordering more beer, the shop owners typically respond, “The demand was growing and I didn’t get enough beers from the wholesaler, so I had to order more to efficiently compete with other shops.” In reality, though, the demand grows only once during the whole game

The second example is that Ilan Yaniv from the Hebrew University of Jerusalem conducted research to see if people trusted their own guesses or other people’s guesses more. Although the guesses based on other people’s data were better, people trusted their own guesses more. Furthermore, people tend to use others’ better data instead of their own intuition if they are asked to suggest a response for someone else.

There are certain traits of mental models that make it difficult for us to change our perceptions.

• A local solution fits all: We tend to perceive the whole system from our local context (our current mental model) and extrapolate a perfectly working local solution to the other chains of the system. (For instance, a shop owner wants to get more beer, so she keeps pushing a wholesaler because the more she pushes herself, the more she gets work done in her own shop.)
• Disregard of factual data: When we follow our current mental models, we stop analyzing data. (That is why shop owners thought customers kept raising their demand for the one particular beer. They did not check that in reality, the demand remained stable after the initial growth.)
• Attachment: If it is not our problem, we use resources less coupled with what we do and how we think normally to find a solution.
• Blind trust: We feel we can trust our current mental model above everything else. After all, this model has helped us a great deal in the past.

How to Deal with Improvement Stagnation

I have found the following points helpful when teams are experiencing a slowdown of their improvement rate.

Get together and name a number of options that may resolve the issue. Pick only those options that are significantly different from each other. That way team members won’t only consider solutions they have used in the past and also will examine new methods.

Collect data. If there is an issue with user stories rejected by the business, collect data on how many user stories were rejected per sprint, how many had real bugs, and how many were found as improperly defined. If there is an issue with too much time spent on reviews, measure the time and ask team members to sketch a few real review interaction chains that happened in the past sprints. This way the team will have to face facts and not continue with the current mental model.

Use the ideal world concept. If we all like automated tests but the interface between the back end and the persistence layer stands in the way, then ask everyone to forget about the obstacle for now and describe how they would like to see the tests work. When everyone stops seeing the situation through the lens of their current mental model and starts thinking in terms of how an ideal system would function, that can help reveal a solution to the obstacle.

Help other teams. Although a problem can seem to be invincible, by nature a similar problem another team experiences seems easy for us to solve. A team can try bringing in a representative from another team to help solve their issue. In most cases, both parties will realize that the one real impediment was sticking to the view that there was no way around the issue.

Always learn. That helps in every case. So read, discuss, and watch lectures that may enrich your views.

Conclusion

Teams may stop improving because they believe there are no issues left to address or the issues are too difficult to solve. In one way, they could be right: There may be no way to solve an issue based on the current mental model the team possesses. As a result, team members need to switch their mental model to address the issue efficiently. Everyone should learn how to continuously switch thinking paradigms so that continuous improvement may endure.