Team Entropy

Code that is left alone will eventually start to break down. This is called code entropy  and is like this evil force of nature which can only be kept at bay by constant code refactoring. 

Each time you add code, entropy increases making the code a little bit more complex and a little bit harder to maintain.  In short, technical debt is slowly increased little by litte.

But what about team entropy?

Like code decay, team entropy is an invisible force constantly working on you to let things slide, beckoning you to return to the way things were before. At the core, this is one of our most basic instincts: avoid work by taking the easy path, not necessarily the smartest path. 

"I should go to the gym, but...". 

"We really need to do something about this, but ..."

All teams are influenced by it and many succumb to it. When energy is high, this is not a big deal, but eventually energy is lost. After numerous sprints and releases, things starts to get cosy and routine. Complacency sets in. The result is that continuous improvement suffers and the team eventually falls back to a pre-agile state. But the funny thing is that the team still believes they are agile, even though they are only going through the motions.

Here are some indicators that a team is affected by entropy or complacency.

• Retrospectives becomes a comfortable routine
• Longer iterations are introduced
• Re-planning during iterations are accepted
• Stand-up meetings gets longer and does not create energy for the team
• Less pair programming and/or pairs rarely switches
• The whole team is getting more quiet
• Agreed-upon practices are skipped in silent agreement
• Workarounds are accepted instead of fearless problem solving
• Bugs are starting to appear again

Team entropy is hard to fight or even notice once it has started to set in. They way to fight it to be vigilant (for lack of a better word). You need to be on your toes. Constantly challenge yourself and your team to improve and question the way you work.

How to fight it?

Retrospectives! Treat them seriously and never accept routine when it comes to retrospectives!

Change the way you do them, make them shorter or longer, try a new agenda, hold them in a new place, use different tools, try another time. In short, surprise your team!

For inspirations there are a few books which can help you with this. I recommend that you add Agile Retrospectives and Collaboration Explained to your reading list.