As humans we learn by analogy, metaphor and simile, adding new knowledge by initially relating the new to our existing understanding of the world. When we try to explain the software development process to the initiated (translation business stake holders), we use all kinds of similes to help them understand the process. The problem with similes is that they argue that something is like something else and many times people confuse the similes with metaphor, thinking that one thing is another. Not only do people confuse simile with metaphor, but many of the similes we use in explaining software development are not appropriate because they can cause more harm than good and they are not very accurate in their explanation.
When I tell people I am an Agile Coach, unless they are in IT, I tend to get a lot of strange looks. Most of the time they will say something like, “I get the coaching part, but what the heck is Agile?” It is at this part of the conversation that they experience immediate regret as I launch into an endless barrage of commentary on Agile development.
Lately, however, I have begun to re-examine my own assumptions about what it the Coaching aspect of an Agile Coach is, especially now that there are so many professional coaches looking for work after the end of the regular NFL season.
I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.
While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.
I am currently reading the book Antifragile: Things that Gain From Disorder by Nassim Nicholas Taleb. I loved two of his other books, The Black Swan: The Impact of the Highly Improbable and Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets so I thought that I would give this one a go.
His central thesis is that there are systems that are not only robust, able to withstand randomness and chaos, but there are those that actually thrive on such events. He calls these “antifragile” as opposed to fragile systems.
I gave the Larry’s Top Ten Agile and Scrum Myths talk to the Java Users’ Group in Phoenix recently and people have asked me what the top 10 myths are. I have posted a copy of the powerpoint, but for quick reference, I have listed below.
- Myth #1 – Agile is a Framework/Methodology
- Myth#2 – Agile Means No Documentation
- Myth#3 – Agile is Less Disciplined / Easy
- Myth#4 – You Can Achieve Agility Without Organizational Change
- Myth#5 – Agile is Scrum
- Myth#6 – Scrum Will Lead to “Hyperperforming” Teams
- Myth #7 – You Must Get 100% of all Stories Complete or You’ve Failed
- Myth #8 – Scrum Master = Project Manager
- Myth #9 – We Can Do Scrum Without a Product Owner or Many P.O.s
- Myth #10 – With Scrum We Can Make Changes Whenever We Feel Like It
Now feel free to rip into these as you wish!
Wow! Just noticed that I had not blogged at all since October of last year! Between starting a new gig on October 31st and the holidays I have been way too busy getting acclimated to my new surroundings, shopping for the perfect holiday gifts, feeding my face with holiday cheer, etc. to spend time writing about Agile development. Time to get back to it. My new year’s resolution is to begin contributing again on a regular basis. It is therapeutic for me and I have found out through Google analytics that there are a number of folks out there that have found some value in my musings. I hope you all had a great holiday season and I wish you the very best in the new year!