There are very few topics of exploration that have unceasingly retained my curiosity throughout life. One is software development, another is religious thought.* But in my teens and 20s, I didn't really expect them to overlap...
You've likely heard the word "religion" used to describe the Agile movement (or, now more aptly, the Agile industry), and usually it's meant unkindly.
But it's an apt analogy, and I've often used it myself. In a way, Agile is indeed an umbrella term for a collection of "religions of software development." I don't think that's a bad thing.
A religion, as a topic of study, circumscribes a set of beliefs, ethics, and practices. Every religion in history and today has its share of dedicated practitioners, crackpots, expert teachers, and charlatans. Every one started out as a new, challenging idea, appropriate to historical context, and usually rejected by the status quo. Every one provided value to its adherents. Every religion has been abused for personal gain. Every single one.
Over time, some ideas become the status quo, some practices that once had value are performed mechanically, and some ethical systems are paid mere lip-service. Like in a "cargo cult", people will continue to perform the practices though they get none of the value. Often because they've confused cause and effect.
Agile is no different. In the late 1990s, we were considered rebellious. Now you will encounter Agile frameworks that recommend ritualized adherence to well-regarded practices, and are packaged in a way that's palatable to folks with Theory X management styles.
Just last week I met with a team resisting Scrum as "too heavyweight" and "requiring attendance at too many meetings." That's sad, because Scrum is intended to be an extremely lightweight approach, with minimal overhead, oversight, or waste. "Where do such misinterpretations come from?!" you may ask. Human nature, my friend.
With Scrum and Extreme Programming (XP) in the 90s, we were looking for a "middle way" (if you'll pardon the personally-biased reference) between basement hacking and the Rational Unified Process (RUP).
We are still, today, looking to improve on the way we build software. The search for greater fluency doesn't ever end.
In my experience, the chosen system of thought, to continue to provide value and comfort, needs to (a) be self-reflective, and adapt to changing context (i.e., it has to "change with the times"), (b) adapt to regional realities and native cultures, while still providing the original, foundational values, and (c) be easy to describe and to learn the basics (though there are always higher and higher levels of fluency to be explored over a lifetime).
"Is he still talking about scaling Agile in a complex corporate setting?!" Of course.
* There are others, and you may note significant overlap, but they are not as relevant to this post: Science, and fitness. Ask me about those; I'll pedantically talk your ear off. You've been warned. ;-)
You've likely heard the word "religion" used to describe the Agile movement (or, now more aptly, the Agile industry), and usually it's meant unkindly.
But it's an apt analogy, and I've often used it myself. In a way, Agile is indeed an umbrella term for a collection of "religions of software development." I don't think that's a bad thing.
A religion, as a topic of study, circumscribes a set of beliefs, ethics, and practices. Every religion in history and today has its share of dedicated practitioners, crackpots, expert teachers, and charlatans. Every one started out as a new, challenging idea, appropriate to historical context, and usually rejected by the status quo. Every one provided value to its adherents. Every religion has been abused for personal gain. Every single one.
Over time, some ideas become the status quo, some practices that once had value are performed mechanically, and some ethical systems are paid mere lip-service. Like in a "cargo cult", people will continue to perform the practices though they get none of the value. Often because they've confused cause and effect.
Agile is no different. In the late 1990s, we were considered rebellious. Now you will encounter Agile frameworks that recommend ritualized adherence to well-regarded practices, and are packaged in a way that's palatable to folks with Theory X management styles.
Just last week I met with a team resisting Scrum as "too heavyweight" and "requiring attendance at too many meetings." That's sad, because Scrum is intended to be an extremely lightweight approach, with minimal overhead, oversight, or waste. "Where do such misinterpretations come from?!" you may ask. Human nature, my friend.
With Scrum and Extreme Programming (XP) in the 90s, we were looking for a "middle way" (if you'll pardon the personally-biased reference) between basement hacking and the Rational Unified Process (RUP).
We are still, today, looking to improve on the way we build software. The search for greater fluency doesn't ever end.
In my experience, the chosen system of thought, to continue to provide value and comfort, needs to (a) be self-reflective, and adapt to changing context (i.e., it has to "change with the times"), (b) adapt to regional realities and native cultures, while still providing the original, foundational values, and (c) be easy to describe and to learn the basics (though there are always higher and higher levels of fluency to be explored over a lifetime).
"Is he still talking about scaling Agile in a complex corporate setting?!" Of course.
* There are others, and you may note significant overlap, but they are not as relevant to this post: Science, and fitness. Ask me about those; I'll pedantically talk your ear off. You've been warned. ;-)
