Management 3.0

Management 3.0 by Jurgen Appelo

In his foreword of the book “Management 3.0” by Jurgen Appelo, Robert C. Martin wrote that he hates management books, but “this book is smart”. I think that this book might be smart because Jurgen is smart.

If I try to summarize what you get from the book “Management 3.0” by Jurgen Appelo, you can consider the author as the hidden son resulting from a relationship between a Springer Verlag journal’s editor and Mike Cohn, with some influence from Aardman Studios in the education. You will therefore jump from sentences like “It is often seen as the opposite of reductionism, although complexity scientists believe that complexity is the bridge between the two, and both are necessary but insufficient [Corning 2002:69]” (I hope that you have all recognized the definition of “holism”) to a checklist for Agile Goals that contains questions like “is the goal manageable and measurable so that success can be determined?”

You will therefore go back and forth between high level system or behavioral theories and practical management situations and practices. Despite its high theoretical content, the book is very enjoyable and easy to read and you shouldn’t be afraid by what could appear initially as a strong theoretical content.

Jurgen Appelo is so smart that he even make the own assessment of his book at the end, based on the quote that “all models are wrong but some are useful” He says “It makes no sense discussing which idea is wrong, because they all are. The real challenge is in finding which ideas are useful in what context”. I think that reading “Management 3.0” will provide you with a larger ideas’ toolkit and help you assess which ideas might be useful in a particular context for your Agile project management journey.

Reference: “Management 3.0, Leading Agile Developers, Developing Agile Leaders”, Jurgen Appelo, Addison-Wesley

Quotes

It is a bit silly that self-organization of teams is regularly hailed as a “best practice” in Agile software development. Self-organization cannot be a best practice. It is the “default practice” of any system, including teams. Not matter how you manage a team, there will be self-organization. People will discuss and agree on lunch meetings, folder structure, workplace territories, and birthday parties. Everything that the management does not constraint (and much that it attempts to) will self-organize. Humans have behaved that way for 200,000 years. But is what happens also happening in the “right direction?”

Doesn’t anticipation violate Agile? Anticipation is like alcohol. It is healthy when used in a small dose. But it is addictive and most people use far too much of it. Agile software development does not reject anticipation. But it tries to reduce it to the smallest possible amount, where it is still beneficial instead of harmful.