Posted on

Agile = Antifragile Part 2

Antifragile by Nassim Nicholas Taleb

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.

Continue reading “Agile = Antifragile Part 2”

Posted on

Agile = Antifragile?

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.

Continue reading “Agile = Antifragile?”

Posted on

Larry’s Top Ten Agile and Scrum Myths

Top ten agile myths - Larry Apke

Top ten agile myths - Larry Apke

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!

– Larry Apke

Posted on

Drive: The Surprising Truth About What Motivates Us and Why Agile Works

In Daniel Pink’s bestseller Drive: The Surprising Truth About What Motivates Us, the author persuasively argues that what motivates people in the knowledge economy (of which software development is squarely seated) “is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world. ”

People are no longer motivated by the carrot and stick approach of past Tayloristic, manufacturing, assembly line business. What motivates new workers, and what has been supported by a wide range of scientific studies, can be summarized by the acronym AMP which stands for Autonomy, Mastery and Purpose.

As an Agilist, I am always curious why in one company an Agile implementation succeeds and in another it does not. While there are many reasons for Agile implementations to fail, one thing that many have in common is that they fail to take into account the three factors Pink describes in his book.

Continue reading “Drive: The Surprising Truth About What Motivates Us and Why Agile Works”

Posted on

Larry’s Presentation to Java Users Group

Last night I had a wonderful experience presenting to the Phoenix Scrum Users Group on Larry’s Top Ten Agile and Scrum Myths. It was a very friendly audience and there were a great number of comments and questions from folks representing the whole Agile spectrum.

I have uploaded my PowerPoint file of the presentation for those who are interested.

Posted on

The Fourth Agile Principle

“Business people and developers must work together daily throughout the project.”

I was in a backlog grooming meeting this morning when I was given reason to reflect on this, the fourth, Agile principle. The reason was that the team I was working with was struggling/arguing about the proper wording of a story. To a few on the team the absolutely precise wording of the story was of paramount importance. While I am a big fan of precision, the vehemence of the need to be precise was a bad smell. It took me some time to realize where the stridency came from.

Continue reading “The Fourth Agile Principle”