DZone
Agile Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > The Pool: An Agile Fable

The Pool: An Agile Fable

Gil Zilberfeld user avatar by
Gil Zilberfeld
·
Feb. 23, 15 · Agile Zone · Interview
Like (0)
Save
Tweet
5.47K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What SREs Can Learn From the Atlassian Nightmare Outage of 2022
  • How to Leverage Method Chaining To Add Smart Message Routing in Java
  • After COVID, Developers Really Are the New Kingmakers
  • Use Lambda Function URL To Write a Serverless App Backed by DynamoDB

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo