The Pool: An Agile Fable

Once upon a time there was a pool. It was in a club, and the club people loved the pool.

This pool had 6 lanes. Each lane was wide enough for 2 persons to swim in parallel. Because the pool was popular, sometimes in certain hours, there were more than 12 people, and then people joined in already populated lanes. It wasn’t comfortable as swimming alone, or with a pair, but it was possible, to get by with 3 people swimming in a lane. 4 was a stretch, but it sometimes came to that.

There were certain rules for using the pool. But they were not enforced, they were used as guidelines. For example, two of the lanes had a small sign on them: “Fast Lane”. They were intended for fast swimmers. It was a well known guideline, but the guideline made sense only when the pool was full.  The system (pool and swimmers) was built that fast swimmers gravitated toward the Fast Lanes, slower swimmers to the other lanes.

Some experienced people even tried to game the system.

For example, when the 13th person came to the pool, he looked at the pace of the other swimmers, then joined the lane that was compatible with his or her pace. Others took into account which people they know and their schedule, how long others have already been in the pool, how long they are going to be in. Then they chose the lane that was optimized for these situation (mainly give them a free lane).

And the people were mainly happy.

Then one day, a new sheriff came to town, a new lifeguard. Fresh out of lifeguard school, he remembered what they told him in class: It is safer and more comfortable for swimmers if all in the lane swam at the same speed. His main concern was safety first, comfort second (as it should be). Armed with this set of priorities, knowledge and a set of more visible “Fast Lane” signs he started to enforce the methodology. He asked (rather authoritatively) people to move between lanes, so fast swimmers were swimming together, and the slower swimmers were swimming in their own lanes. Some of the swimmers had to move within the same session more than once, as the population of the lanes changed.

Because there were basically two classes of service –  Fast Lane and Slow Lane – The people who got moved around were in-betweeners. The fast swimmers still gravitated naturally towards the Fast Lanes, the slow swimmers towards the slow ones. The lifeguard then looked at all others, and decided where they fit best, then moved them.

And the people were less happy.

(Actually, only those who now needed to move around, you can’t really argue with a life guard.)

The agile perspective

Let’s see what happened here from an agile point of view.

Before the new regime, the pool was self-regulated. Even when gaming the system, it still supported safety and comfort, but the people themselves took decisions by themselves. Once it went into command & control mode, people felt that the choice was taken away from them, and resisted. Safety was maintained, but the comfort level dropped.

In addition, all decisions of “which lane should I pick” now moved to the lifeguard. Since the lifeguard was not that busy, that wasn’t really a problem. But creating a single point of decision creates a bottleneck, that in regular team work is not healthy.

Finally, rules and regulations are there for a reason, everyone will tell you. But the rules are only one way to solve problems. There are other ways to make sure safety is maintained.

The moral is: Don’t mess with a self organizing team. The chances of them improving just because you come with a tried and true methodology, are not big.