It was 1983 and I was in science class when I first heard the term entropy.

I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.

Entropy is the state of existence

I long attributed the phrase "entropy is the state of existence" to my science teacher. Looking back, I suspect that I either misunderstood him or made it up myself, but in any case, the phrase stuck with me and I use it to this day.

For me, entropy is not a fatalistic notion, rather a reminder that all things need tended.

It requires the application of new energy to keep a system at status quo

Disorder is natural and all systems, left un-tended, eventually fall apart. It requires the application of new energy to keep a system at status quo. Our desire to change nothing in order to keep things as they are is unrequited. We must change in order to stay the same.

Entropy and Process

No matter how well your process works today, I can promise you, left unchecked, it will eventually fail to deliver the results it once did. I believe there to be two primary reasons for this. First is that the process in-deliberately changes over time. Second is that our needs for process change as our project evolves and our team matures.

The process in-deliberately changes over time

How many of you have been on a team with stale stand-ups? The format hasn't changed. The participants haven't changed. And yet the value isn't what it once was. We stick to the process and try to recapture the magic.

How many of you have participated in a process that doesn't seem to make sense anymore? When the team started working together, no one knew the system well and there were lengthy debates over what might be true. The code might be complex or poorly covered. It might not.

Our needs for process change over time

Estimating sessions took forever. So management put a silent estimating process in place. This allowed the team to get through estimating sessions quickly. Six months later, everyone had solid experience with the code and was able to articulate real concerns, but the process didn't allow for it. No worries, the process served them well this far; it must be right.

Inspect and Adapt

As a runner, I train regularly in order to maintain my current level of fitness.

I vary my training to ensure balance. It requires effort simply to stay the same. And if I want to improve, I must assess my current status, evaluate where improvement is needed, and adjust my training accordingly. If I need to build strength, I work in more hills. If I need to improve my speed, I focus on track work. I monitor my progress to ensure I'm getting the desired results. Pain, fatigue, faster times, improved strength, and no perceivable change are all valuable pieces of information that help me determine if what I am doing is working and what other adjustments need to be made. Invariably, when I stop paying attention, I end up with an injury.

Enter the Retrospective

Retrospectives are the one practice I feel are an absolute must for teams; agile or otherwise. Remember, entropy is the state of existence. It requires the application of new energy to keep a system at status quo. A regular dialogue about what is working, what is not, and what we plan to change is paramount to simple survival. Without it, entropy wins.