Top 10 Laws in Agile

poster_top10-laws_72 Update: I’ve created a poster out of 8 of the laws. Just click on the image to get a file that ought to be big enough for an A4 / letter size print.

Original Post: There’s a handful of laws that agile and lean folks like to quote. Even though I’ve read about them all I sometimes forget which one’s which. As a reminder to myself and a service for interested third parties (that would be you, hopefully) here are 10 laws floating around my filter bubble (loosely ordered by how often they’re quoted):

 

1. Little’s Law

Cycle Time = Work in Progress / Throughput

Little’s law is the reason multi-tasking is such a bad idea: If you double WIP you double the time it takes to finish.

This is the law the Lean & Kanban part of my Twitter stream references most often.

2. Goodhart’s Law

When a measure becomes a target, it ceases to be a good measure.

Pursuing some measurement might very well prevent you from reaching the goal that made you watch that measure in the first place.

3. Conway’s Law

The interface structure of a software system will reflect the social structure of the organization(s) that produced it.

I find it fascinating that communication and power structures will surface in the products companies build. Many usability WTFs have their root cause in this law.

4. Parkinson’s Law

Work expands so as to fill the time available for its completion.

This story of a Domino Challenge demonstrates the law nicely.

5. Humphrey’s Law

The user will never know what they want until after the system is in production (maybe not even then)

There you have the reasoning behind short iterations and the review meeting in Scrum.

6. Law of the instrument

If all you have is a hammer, everything looks like a nail

7. Law of Demeter

… is also called “Principle of Least Knowledge” and is a design principle in Object Oriented Programming:

The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of “information hiding“.

Luckily there’s an easy to spot warning sign when you’re about to violate this law – Don’t use more than one dot (in dot-syntax languages such as Java):

  • a.b.Method() bad
  • a.Method() is A-okay

Wikipedia provides the following analogy:

When one wants a dog to walk, one does not command the dog’s legs to walk directly; instead one commands the dog which then commands its own legs

8. Dude’s Law

Value (of a project) = Why over How [or Value = Why / How]

If you don’t have a good reason to be doing the project, it doesn’t matter how well you do it. Yves illustrates the law by telling:

David [the law’s creator] comes from the music industry. New musicians focus on having a nice sound. Professional musicians first think about the mood of the song, the emotion they want to bring across and then work out the sound that fits it”

9. Law of 2 Feet

This one is from Open Spaces:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.

Some organizations try to apply this law to all their meetings. Don’t feel like you contribute? Just leave.

An broader implication is that people can leave a job they’re not happy with.

10. Law of Propinquity

This one is hardly ever mentioned but IMO it should be, so it’s in here 🙂

The probability of two people communicating is inversely proportional to the distance between them.

Interestingly, this is still true in the digital era. It’s holds even though we don’t have to get out of our chair to communicate!

Bonus: Prescott’s Pickle Principle

Okay, it’s not a law but it deeply resonated with me, when I first read it (still does, akshually) so here go Jerry Weinberg‘s timeless words:

Cucumbers get more pickled than brine gets cucumbered.

When you get into an environment it will influence you more than vice versa.

What laws are missing? Which others offer insight?

The following laws were contributed by commenters:

  • Allan Kelly suggests Moore’s Law and Metcalfe’s Law because they shape the IT industry
  • Natalie Warnert suggests Newton’s Third Law. She sees “it as when an outside force tries to control actions, those who are trying to be controlled generally push back with the same force (maybe not always obviously but…). In a more positive situation a good action – say removing a block by a servant leader can produce an equally good result in efficiency and throughput.”

Thanks for the additions!

Published