Changing Quicker

We finished “Change and Stable Systems with the questions: Will reorganizing every two weeks lead to stable software processes? What conditions would enable this to happen? When should we schedule the next change? Today we’ll discuss some conditions that enable quicker change.

I want to recognize I’ve been using two words interchangeably: systems and organizations. In this context, I view an organization as a specific type of system.

Systems contain three basic components: reinforcing loops, balancing loops, and time delays. Reinforcing loops cause growth or decline. Balancing loops interact with reinforcing loops and create stability. Time delays separate cause and effect by days, months, possibly years. These delays determine how quickly a system responds to a change.

Delays occur in several places for organizations.

Transport delay involves the time required to move information around the organization. Information that development needs to know may enter the organization in customer support. “Oh no! The Frammin module appears to be broken! It’s reformatting the customers’ hard drives and displaying Elbonian profanities on their monitors!” The standard hierarchical organization communications path would be up the chain to the common node, then back down the development change to the managers who decide what should be done, and then to the programmers who actually do the work.

Decision delay results from the time required to decide what to do. I used to believe that inside every complex system, there was a simple system trying to get out. I still largely feel that way, but some software systems are complex, and that’s that. We’ve been writing software for 50 years. Most of the easy programs should be written. That leaves the difficult and complex programs. Quick decisions can spell disaster if the long and short term ramifications aren’t considered. When the development managers learn the Frammin module causes problems, it may take a while to determine the circumstances surrounding the problem event, exactly what part of the Frammin module causes the event, and what to do about it.

Implementation delay is the time required to do the work. The classic line here: “You can’t produce a baby in 1 month with 9 women.” Some work is separable and can be done in parallel by multiple workers. Some isn’t and must be done by a single person. Quick thinkers will try to create separable work. While work can proceed in parallel effort, communications (and gaps) and interfaces become issues. These issues are avoided when a single person does the work. So which answer is better?

Time delay relates to a system parameter called time constant. When the system output reaches 63.2% its next value, one time constant has passed. The following graph shows a system with a time constant of (approximately) 4.5.

Time Constant = 4.5


By reducing any or all of the delays, we can achieve a result in a shorter time period as demonstrated by:

Time Constant = 3


We’ve moved the time constant to (approximately) 3, or reduced the time it takes to respond by 1/3.

How do we remove delay from the system?

Transport Delay: All organizations have informal networks that pass information to where it should go. These networks are usually called “friends”. Some organizations explicitly encourage this by “cross assignment.” A developer works in customer service. A tester may spend time in development. Besides broadening the skills and creating an understanding of what the other person does, this creates the informal network that keeps information flowing.

Decision Delay: “Empowerment” bothers me. I actually think it’s a great idea, but in many situations the idea gets morphed into an evil double bind event. Nonetheless, we’re talking about empowerment. Move the decision making authority to the person closest to the information (reducing transport delay) and work effort (possibly also reducing implementation delay). The management problem resides in authority to make a decision can be delegated, responsibility for that decision can’t. Maybe this causes the standard empowerment double bind.

Implementation Delay: Better people make better products. I can’t put my hands on the data, but I seem to remember that Jerry Weinberg, Tom DeMarco, and Capers Jones have all released studies showing that individual performance varies by an order of magnitude. So get better people. Read Johanna Rothman’s book: Hiring the Best Knowledge Workers, Techies & Nerds. Improve the skills and abilities of the people where you work. Send them to the AYE Conference. Improved workers will impact Decision Delay by allowing true empowerment.

Can you think of other delay causes? How can we mitigate them?

Agree? Disagree? Add a comment.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *