To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyses reviews to verify trustworthiness.
After 40+ years as the goto for Development Management, this book replaces the still fantastic Mythical Man-Month as your first point of contact.
This collection of evidence and advice is perfectly paced, interesting, and has a lovely non-dry style that keeps you engaged. It explains an awful lot about the basics and more interesting personal interaction of Team Management that are not taught, and managers are expected to gain - experience says they often don't and wing it.
If, like myself, you have had the great fortune in the past of leading a true agile environment, and then the misfortune to have to change job to non-agile environment with a futile management team then this book will help you re-evaluate and realise you were not mad. If after presenting this information to that management then I leave you with the only option you have: GET OUT!
There are many great books with wisdom on how best to form effective teams, but the trouble has always been that this folk knowledge is widely distributed and uses different words for the same things. What the authors have achieved here is to organise this knowledge in a clear taxonomy of team topologies and interaction patterns.
What's more, they do a great job of citing other important works on the topic so that the reader can follow ideas back to their source: Melvin Conway, James Lewis, Daniel Pink, Evan Bottcher, Michael Nygard, Nicole Forsgren, Jez Humble, Gene Kim, Allan Kelly, John Roberts, Don Reinertsen and many more are liberally quoted throughout the text. That makes this book a great summary work on a topic of vital importance to any software organisation of any size - how do we best divide the work so that teams have the best possible chance of success?
Lots of useful content and references here, spread throughout. Also some informative diagrams to prompt discussion.
I did feel however the overall content of the book could have been written in 40 pages, a lot of repetition and use of academic language when a simpler conversation style would have sufficed. It led to cognitive overload which is ironic
This is a great book for people who want to create teams that deliver value. The authors define four types of teams that provide a different set of objectives. They also describe the communication between these teams making it very clear how each type of team operates in relation to each other. The punchy delivery and simple illustrations offer an easy to read resource that is also a great reference to help you establish the team structures needed to deliver value to your customers. I highly recommend this book for those who want to structure their organisation to deliver high value.
I thoroughly recommend this book to anyone involved in, or interested in, software development management or architecture (as the two are linked). Most of the general idea behind team topographies can be found on the website and other articles & talks the authors have given but this book dives a bit deeper and provides some good example of the team structures and relationships. I ended up highlighting about a quarter of the book for future reference.
Wow. It's the year 2020 and books that elaborate on the importance of teams and thoughtful team design are still ranked high on Amazon. I am in software dev for nearly two decades and during that time there were some seminar books of processes and Teams. I think of Cockburn, Tom de Marco, Nygard and Kent Beck. Those books were thin and still crammed with ground-breaking well formulated ideas.
Many trustworthy people recommended this book to me and am totally disappointed how few ideas I could digest from it. It's full of repetition, lenghty convoluted sentences with many buzzwords and little meaning.
The images and diagrams are colorful. And that's the most positive I can say. Chaotic. Confusing. Vague. I am a single reader, but I tell you. "This is not a book you need to read." The topic is important but you will not learn enough from it. Go find it elsewhere.
This book has given words to some team problems I have seen over several years, along with ways to fix problems. Essential reading for managers, stressed out devs and anyone who wants to make software delivery flow better.