Short Reach Revived

This first appeared on the Object Mentor blog in 2007, but I had to get a cached copy from google to reread it. I'm reviving it here so we don't lose it forever. I think it is still carries a valid point, and I would like to revisit it in the near future.

Short Reach
Posted by tottinger on Monday, April 23, 2007

I’m always trying to find newer, better, shorter, more powerful ways to explain what Agile is about. I suppose I’m some kind of obsessive about expressive power and economy.

Finally I decided that Agile, as I understand it today, is about the short reach.

It seems to me that all of the agile practices are about shortening our reach, the distance in time-and-space that one leaves an assumption, decision, or line of code untested and unconfirmed. All the practices seem to follow this one rule.

• The customer/analyst is kept in the same room, in the same short reach. 
• We feed back the iterations to the customer/analyst so that his every decision has a shorter reach. 
• We do iterations to ensure our planning has short reach. 
• We keep our teammates very close, in the same room, so that it’s a shorter reach to them. 
• The test is written first, so that implementation has shorter feedback on correctness. 
• We compile/test frequently because our code time should have a short reach. 
• We pair so that our code is instantly vetted through a peer. We don’t pile it up and review it after the tests pass. 
• Our planning is based on “yesterday’s weather”, data collected a very short time ago. 
• We don’t plan the team structure and the assignments, we self-organize so that tasks are waiting for the shortest time possible. 
• We talk face-to-face, not across chat and email and official company documents. 
• Tell-dont-ask and the Law of Demeter guide us in keeping the reach of our objects very short. 
• We use unit tests to exercise a class directly, and we isolate with mocks to reduce the reach of our tests through the system. 
• Shared code ownership means that the guy sitting behind your keyboard has all the permission he needs to do excellent work, even if it impacts existing design. 
• Test-first development means that the guy who makes a change knows very quickly whether his change is safe or not. He doesn’t have to wait until the week before integration when the “real” tests are run. 

Where does Agile run into logistical or operational difficulties? Wherever a long reach is required or imposed. Where an organization chooses to continue in waterfall-style management, where the team is distributed among managers with appointed “point of contact” and “official channels”, and where the developers are not placed in a common work area agility is very difficult.

I’m not saying that agile techniques can’t work for large companies, but that is an area where a lot of experts are trying (maybe succeeding) to extend the agile techniques and where the average “agilist” finds challenges. When it works, it is almost certain it will be because someone has found a way to shorten the reach of the teams so that all they need to know is never more than a few seconds or minutes away.

At least that’s my half-baked observation of the day. Let me know if I’m wrong here. Or if I’m more right than I think I am.