Review: Exploring the Practice of Antifragility


I wrote a review on Amazon for Exploring the Practice of Antifragility.

I am republishing it here:

First disclosure: As of the 5th of December 2015, I am a contributor to this book! I do not have a financial stake in it, but I do wish the book to succeed, because I believe the idea of antifragility to be important. I won't review my own contribution, of course, but stick to the things I have read by the other contributors.
Second, Exploring the Practice of Antifragility is itself antifragile! The book is a Kindle ebook, and like all Kindle books, it can be updated with new material from time to time. This means the book itself can evolve according to pressure from the environment, i.e. reviews and sales data can actually make this book better over time.
Thus, if you buy the book, think of a way to improve it, and write about it in a review, your wish might come true. While this is possible to do with all Kindle ebooks, I do not think too many of them make good use of it. When Si Alhir, one of the editors, told me about the book having planned updates when he invited me to participate, I found this to be a very attractive feature.
Third, the book also features another very important property of antifragile systems: Variation!
The book is an anthology, with essays written by very different people, who have very different backgrounds, and who do very different things. This means you won't be interested in everything, but, if you are interested in antifragility, there will almost certainly be something in it that you find very interesting.
Fourth, the book was practically useful to me! Two years ago I began building an antifragile organization. We are now more than 350 people. One of my book projects is a book about the organization, and I have struggled with explaining, in a simple way, the difference between the antifragile organization, and fragile organizations in the same domain.
Todd Nilson solved the problem for me, writing about Nicholas Taleb's triad schema. It was exactly what I needed. I can borrow the idea, adapt it for my own book, and it will work beautifully.
Si Alhir made the connection between antifragility and the OODA decision loop from John Boyd's Maneuver Conflict, which I find interesting, because the antifragile organization I am deeply involved in, directly uses many ideas from Boyd.
Again, Boyd's ideas are echoed in Todd Nilson's: "…the purpose of the community trumps all else."
I also enjoyed reading Elinor Slomba's piece about sustainability, connectivity, and diversity, and how to use simple free tools to collaborate over the Internet.
Valuable ideas I can use in my own work. Highly useful.
Also, Slomba's ideas about cascades the properties of aggregated and distributed systems are practically useful to me. I recently released a book about reducing lead times in the book publishing business. The method I wrote about, and use to write my own books, applies the same ideas. Slomba has given me a slightly different perspective, which will help me express the ideas in a simpler manner in my own books.

So, I give this book five stars, because it actively uses the ideas it proposes, because it will get better over time, and because it was practically useful to me immediately when I read it.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more