Danger of Agile Dogma
When ideas become dogma:
In Agile, the developers have to sit at the end of the row along the open hallway when everyone’s collocated. The business analysts have to be in the middle because they have to communicate with everyone.
In other words there’s a seating chart for an Agile team area. Or,
Sprints are always 30 days. It doesn’t matter if the product owner and the Scrum Master and half the team isn’t available, you can’t add a day to the project. That isn’t Agile.
And I thought the principal was responding a change over following a plan.
There are certain personality types that respond to messy situations by seeking the illusion of stability. They’ll either start laying down laws and issuing edicts, or will find some book to go by, without taking the time to understand it deeply. They tend to be effective in situations that require fastidiousness, but they’ll squeeze the life out of endevours that are necessarily messy and self-organizing.
When I hear or read statements like those, I don’t take them as “agile dogma,” but simply as an indication that the speaker or writer misunderstands the principles or the implementation of agile methods. Unfortunately, this sort of thing makes it more difficult for us to help organizations realize positive change, since people may be confused by conflicting messages about what “agile” means.
I think in this case it’s that individuals have taken one source of Agile to heart without getting exposed to any other viewpoints. In the technical arena I constantly am stunned by co-workers who’ve never read up on the things they practice or kept up with developments in their field in general be it QA, project management, business analysis, or development. If you have a single source for your information you’re much more likely to cross over into dogma.