Recently, I’ve been working to establish another magic funnel. One of the first things we did was to find the person who formerly handed out work to the developers and made him a single point of contact. In our case this is not the scrum master, but is another trusted line-manager type. He has been given a number of people to work with on the Customer side of the house and also works with technical people.

We have tried to establish story feeds from all the various stakeholders. Developers, operations people, technical writers, customers, sales people, marketing people, inside security consultants, and others have been feeding their ideas in to our point-of-contact man. This part of the funnel is working fairly well.

The next thing we have tried to do is to match the feed of work to the rate at which work can be done. This has created a fair amount of back-pressure on the stakeholders (which I believe to be healthy).

We have also worked on making the bottom of the funnel narrow, meaning that our guy doesn’t scatter new work to the team, but feeds it through the scrum master who protects the team’s productivity and keeps the work flow and tasks visible on the status board. He makes sure that the team is not expected to “absorb” changes, but that adding two points of work to the iteration results in two points of unstarted work coming off. This also creates a healthy back-pressure.

As a pun on “in-flight”, I named another area of the board “flying standby”. This is for stories that aren’t important enough to swap a story off the board (or for stories that are displaced by more important ones). If the developers finish more work than they expected, there are stories that can be picked up even though they’re not a scheduled part of the iteration. Stakeholders are told that there is no guarantee of these stories being picked up at all in this iteration, but there is some small chance that it could happen if the team discovers that it has overestimated some other stories.

The bottom of the funnel is working pretty well.

What’s missing is the “magic” bit.

Imagine my joy as I realized that I could make it 11:30 again, and go enjoy another lunch. Meeting at 3:30? No problem, just turn the hour hand up to 6:00 and go home! I can sleep as long as I want as long as I turn it back to 8:00 when I get to the office. All my work estimates are now “five minutes”, and I complete them every time.

My coworkers have no idea the awesome power that I’ve gained with this one happy accident. They ask “what time is it?” and I say “what time would you like it to be.”

Of course the above is a total fabrication. Pretending it’s 6:00pm when it’s 8:00am isn’t going to do anybody any good at all, and is likely to make a mess of things for me.

But people still try to mandate velocity.

Its 5:00. I have one hour. With the kids gone, the cub cadet (with plow) still in need of repair, I wonder can I meet my requirements and finish the job by 5:55 so I can dust off, open a beer and get in the shower by 6. The schedule looks tight, I could do more analysis, but starting the job will tell me a lot and help me get it done too.

I get my back friendly shovel and get to work, shoveling behind the car we plan on taking. After fifteen minutes I have a realization, I am not going to make it. The pan is not doable. A quick estimate and I see I have cleaned off about one eighth of the driveway and I have used one quarter of my time. Sound familiar. My back was not going to let me move more snow more quickly. Wishful thinking would mean not getting to the shower on time and possibly being blocked in the driveway. Thirty minutes from shower out the door is a metric established long ago. I needed to adjust the plan.

I got a committee together to discuss our options. Oh wait a second, that was a different plan.

I cleared about one eighth of the drive in fifteen minutes. Using my velocity it looks like a two hour job. So, its likely I will only have time to move half of the snow that’s preventing access to and from our house. I better focus on the “critical path”. The other car would be buried for another day and the front walk would have to wait.

A good snow drift could have destroyed my plan, but surprisingly there were none on the critical path. Shoveling this software is predictable, and my velocity was stable. I did not set any stretch goals, because I wanted to shovel another day. Keeping with my sustainable pace, I delivery the critical path by 5:55. The Heine tasted good, and we made the next milestone: dinner with our friends.

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 keep 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.