In response to “Change Quotients” Laurent Bossavit laurent_at_bossavit.com wrote:

“Change quotients” prompted one particular thought – since I’m usually the person recommending a change, I tend to be more sensitive to lower quotients than mine. Yet, I do recall one organization which had an intrinsic change quotient which apparently exceeded mine – they reorganized every two weeks, more or less. 🙂

Your remark on how change quotient relates to system size suggests that there must be some absolutes – a reorg every two weeks may be too much for a 40-people company trying to stabilize its software processes.

Change disrupts the status quo. Change events can be external (a new competitor, government regulations, market conditions, …) or internal (promotions, people leaving, new product lines, process improvement…). Let’s call the change event, a foreign element. When a system experiences a foreign element, its output fluctuates over time until things return to normal. The following graph shows a system exhibiting this behavior.

Quarter Wave Decay

 

After a foreign element the system returns to its previous output. The output varies but gets closer to and eventually achieves the desired value. (Control theory buffs will recognize this as a quarter-wave decay response to a step change in the input. I should note other desirable responses exist to step change inputs including critically damped, absolute integrated error and others.)

Now what happens when the system experiences another foreign element, say at t = 4? We’ll use the same “step change” for the input. The resulting output graph looks like:

Changing during change

 

Now the system takes longer to return to the desired output level. So far changing during change doesn’t look desirable. For convincing let’s add one more change at t = 5 (same parameters).

change at T=4 and T=5

 

These graphs apply to bounded, linear systems. I have yet to meet a bounded, linear person. People respond to foreign elements more like:

Satir Change Model

 

I “lifted” this graph from my colleague Steve Smith’s article The Satir Change Model.

Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change?