A recent post by Ryan Marten of Rally Software describes a “cool down” process for a team at the end of a release. In my book “Beyond Software Architecture: Creating and Sustaining Winning Solutions“ I refer to this as an entropy reduction episode. Indeed, I even talk about the concept of being consumed by your work and “giving in” to your job in my first book, “Journey of the Software Professional”. These are important concepts, because, quite frankly, I reject the concept of “sustainable pace” means “40 hours per week every week like a robot”. I learned a long time ago that I have cycles in my work, my life. When I’m committed and passionate, I want to work hard – it consume me, and man, am I happy when that happens. I don’t arbitrarily stop myself. I run with it. Similarly, Agile teams need to be allowed to run passionately hot when needed and need to be given a chance to recover.

Don’t be afraid to run hot. Don’t be afraid to recharge. And don’t be afraid of finishing strong.

For your reference, here is how I described an entropy reduction episode in Beyond Software Architecture. Enjoy!

In the heat of the battle to ship a product a development team will usually need to make some compromises on the “quality” of the code and/implementation to get the product finished. It doesn’t matter if this team is “agile” or not – to get the product shipped you have to focus on shipping the product. This usually means that the team is going to have to put in compromises (“hacks”, “ugly code” – you get the picture!).

No matter how they get into the code base, unless these compromises are removed the quality of the source base will degrade. After the product is shipped some reasonable amount of time needs to be devoted improving the source code. I call this process “entropy reduction”. A development organization realizes several crucial benefits from the entropy reduction process. A few of these are itemized below, in no particular priority order.

• Maintains a focus on source level quality. Developers know that a very fundamental level source code quality matters. And the company reduces risk associated with an unmaintainable code base.
• Reinforces feelings of good will in the development team. Great developers wince when they compromise the source code in order to ship the product. They’ll do it, but they will wince. If you don’t let them go back and clean up they will become “dead” to quality. And if their sense of quality dies, so does your products.
• Substantially improves the maintainability and extensibility of the system.
• Allows the team to clearly understand the specific sets of behavior that exist within the system and gets their mind present to the possibilities of really changing it.
• Ensures that any inconsistencies relative to things like the coding standard are addressed.

Entropy reduction is NOT about making substantial changes to the architecture or adding lots of new features. The goal of the entropy reduction process is to hold the external behavior of the system constant while improving the internal structure of the system.

Entropy reduction episodes are usually scheduled after major releases. Within these release cycles your team should be refactoring their source code as needed. Entropy reduction is often about handling refactoring that were postponed so that you could release your system or avoided because they were deemed too big or complex.

It is important to establish appropriate rules or guidelines when initiating an entropy reduction episode. The biggest, and most important, is the requirement that no new features or capabilities should be added during an ER. To help enforce this rule, try to keep product management from becoming involved. Keep ER as a pure development activity. Functional tests, such as they may exist, of course need to run. Do not ship the product after ER without a full and complete regression test.

Teams vary in their willingness to engage an entropy reduction episode. Teams that embrace it are easy to manage. Teams that enthusiastically embrace it may be trying to use the process to change their architecture—be wary! Teams that have had their sense of quality and their desire to tend their architecture beaten out of them by repeated poor management may have to required to do it (“I know that this ER thing sounds weird, but this is just the way that I do things, and since what we’ve done in the past isn’t producing the results we want we’re going to try and start something new”).

Before engaging ER the team should create and peer review a plan that details the specific modules and/or functions they’re going to improve. This is important because sometimes a team will propose changes that are a bit too big to accomplish in a 1-2 week period of time, which is the amount of time I normally allow for an ER episode. To help ER episodes happen smoothly here are some “best practices” that have worked well for me.

1. Code tags. Code tags are some way of identifying sections of the source code that should be fixed in a future ER episode. I’ve had teams use “TODO”, “REDO”, or even “HACK” to alert readers of the source that something should be fixed. Finding the tags are easy.

2. Establish a rhythm. The rhythm of ongoing releases is very important to me. Successful teams develop a nice rhythm. The work at a “good” pace during the majority of the development, like a brisk walk – sustainable but fun. Near the end, they work as needed, including 80+ hour work weeks, if necessary, to hit the release date. The sprint to the finish. After the release date, the team recovers. We rest, work on ER (which should not be mentally challenging). The recovery race.

3. Time box the ER activity. 1-2 weeks works best. I once tried 3 weeks, but the process was too hard to control—new features were being added. If you need 4 weeks or more to engage a productive ER session look in the mirror and say “The architecture is dead”.

4. Don’t ship the result. I really didn’t have to say this, right? I mean, you could be making changes all over your code base. Just because your automated unit tests pass doesn’t really mean you can ship it without a full regression test.

5. Choose your language carefully. I’ve used the terms “technical debt” and “entropy reduction” to generally mean the same thing. Different people hear these words in different ways, so consider if the phrase “entropy reduction” will work for your team before you use it. If it won’t, consider something else, like “technical debt payback”, “architectural improvement”, or whatever else will work best for your team.

6. Use ER to reinforce other values you deem important. You can use ER to instill a whole host of values, including source code quality, the importance of finishing on time, responsible management (“incur a little technical debt now and you’ll get the time to pay it back after the release”). You can associate cultural artifacts with the first ER episode, like a “chaos” game or a toy (a symbol).

7. Don’t commit unless you can deliver. If you promise an ER episode, make certain you can deliver. I almost lost all credibility in a turn around situation when the CEO of the company told me that I couldn’t do an ER episode because he promised a new feature to a key customer. It took some stringent negotiation, including a few heated meetings, but in the end we had the ER episode before we attempted to deliver the promised new feature. Avoid this pain and make certain you have appropriate senior executive buy-in before engaging an ER episode.

Looking forward to hearing your thoughts on release rhythms!