Why Teams Stop Improving—and How to Jumpstart Their Efforts

[article]
Summary:

One of the most important features in agile software development is continuous improvement. However, after an initial burst of inspiration and productivity, teams may stop improving because they believe there are no issues left to address or the issues are too difficult to solve. People need to switch their mental models to keep addressing processes efficiently.

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.

Pages

User Comments

2 comments
Doug Shelton's picture

Great Article.  

 

I've seen the same issues myself in teams that feel they can no longer improve - and even some resentment that they are being asked to try and see what can be done to improve "more".  

I've found that individual [separate] coaching of team members [to avoid the "crowd mentality response"] can also help here - often getting the team members to realize any fears and concerns about bringing up additional ideas to improve are "getting in their way" and furthermore, are not really "valid" [i.e., the while it is true they feel this "fear" and it should be acknolwedged, the concern that they have the fear about is not really valid] can help spur more discussion of what more can be done.

November 9, 2014 - 2:17pm
Aleksander Brancewicz's picture

Hi Doug,

Thanks! 

Yes managing the fears that stand behind a "we won't change" attitude is very important activity. I share your view completely. What I do is I always create an environment in which one may easily change your position (thus also stop following your fear) without loosing credit/ face(based on reasearches continuity is a very important factor that contributes to personality formation).

November 10, 2014 - 6:29am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.