[carlzukki]

A lot of good ways of looking at this, and your phrasing @bombcar it's really nicely put.

In my opinion, once you play a game for a while, it's easy to know exactly when and how to break ANY rule: you must understand what the rules are there for.

Think of any agile framework, a ton of them are practiced like cults by the most. However, if you think that those are there for 2 simple purposes:

  1. you want to ensure nobody in the team is ever idle
  2. you want to ensure everyone is working on the most relevant available task that hasn't been picked up from others

Then it's easy to see which rules are useful to the goals and which are hurting you, thus you just gotta break them!

This is just an easy example, this is really about anything in life though!

[GlennS]

You have taken a completely different 2 key lessons from agile than I would have picked.

I think mine are closer to the agile manifesto, but perhaps yours are closer to how agile is actually practiced in most places.

Problem 1: you want to ensure that you build the right thing.

Solution 1: you should get feedback from end users as frequently as possible.

Problem 2: you want to be using work processes that are appropriate for your team and task.

Solution 2: teams should be able to modify their own work processes.