BOOK RECOMMENDATIONS
For the specific context of Designing Product Companies as Agile Organizations, some books are brilliant in their entirety while some require more careful consideration. Here, I will share some books with respective comments and caveats from my personal perspective and in relation to the aforementioned specific context.
Creating Agile Organizations by Cesario Ramos, Ilia Pavlichenko
STRONGLY RECOMMENDED
The best book I can recommend for the topic of creating Agile organizations. It is based on multiple scientific research and extensive experience of its authors. Essentially, it is comprised of two main parts about the organizational design of Agile companies and how actually you can create such organizations for that design.
I also provide public courses based on the first part of this book.
The best book I can recommend for the topic of creating Agile organizations. It is based on multiple scientific research and extensive experience of its authors. Essentially, it is comprised of two main parts about the organizational design of Agile companies and how actually you can create such organizations for that design.
I also provide public courses based on the first part of this book.
RECOMMENDED
I can recommend this book and suggest reading it after the first book on this list or after visiting the DAO course.
A great book to understand organizational design in general. The book is quite practice-centric, equipping the reader with principles, suggestions, tools, and techniques.
For instance, the famous Star Model of organizational design was proposed by its author Jay Galbraith. I modified this model into the Six Star Model by adding a missing element which is vital for successful org design from my experience.
The authors of this book also have an analogy of Optimization Goals - the design criteria. However, this concept is lacking clarity in distinguishing from business goals, in its critical place in the whole approach to organizational design, and in its application for systems thinking.
Finally, this is not a specialized book for designing Agile organizations, hence lacking some crucial aspects in provided examples.
I can recommend this book and suggest reading it after the first book on this list or after visiting the DAO course.
A great book to understand organizational design in general. The book is quite practice-centric, equipping the reader with principles, suggestions, tools, and techniques.
For instance, the famous Star Model of organizational design was proposed by its author Jay Galbraith. I modified this model into the Six Star Model by adding a missing element which is vital for successful org design from my experience.
The authors of this book also have an analogy of Optimization Goals - the design criteria. However, this concept is lacking clarity in distinguishing from business goals, in its critical place in the whole approach to organizational design, and in its application for systems thinking.
Finally, this is not a specialized book for designing Agile organizations, hence lacking some crucial aspects in provided examples.
Designing Dynamic Organizations by Jay Gilbraith
Re-creating Corporation by Russel L. Achoff
RECOMMENDED
I can recommend this book and suggest reading it after the first book on this list or after visiting the DAO course.
This is a quite fundamental consideration of organizations as systems and approaches to manage them. Not specific for product companies yet can augment the already learned specifics with more generic concepts, views, and approaches.
I can recommend this book and suggest reading it after the first book on this list or after visiting the DAO course.
This is a quite fundamental consideration of organizations as systems and approaches to manage them. Not specific for product companies yet can augment the already learned specifics with more generic concepts, views, and approaches.
RECOMMENDED with Suggestions
I can recommend this book and suggest reading it after the first book on this list or after visiting the DAO course, just because in that case you will have a more structured foundation with a clear connection of all the aspects of the topic of organizational design.
A Great book to get a deeper theoretical and practical understanding of Systems Thinking, Lean Thinking, Queueing Theory, and other aspects relevant to Designing Agile Organizations.
I can recommend this book and suggest reading it after the first book on this list or after visiting the DAO course, just because in that case you will have a more structured foundation with a clear connection of all the aspects of the topic of organizational design.
A Great book to get a deeper theoretical and practical understanding of Systems Thinking, Lean Thinking, Queueing Theory, and other aspects relevant to Designing Agile Organizations.
Scaling Lean & Agile Development
by Craig Larman, Bas Vodde
by Craig Larman, Bas Vodde
Large-Scale Scrum
by Craig Larman, Bas Vodde
by Craig Larman, Bas Vodde
RECOMMENDED with Suggestions
I recommend this book to anyone who has reached the point of learning about product group design. Respectively, I suggest first reading the first book on this list and/or visiting the DAO course to optimize your learning experience and better understand the overall organization design with its principles before learning its specific part.
This book is dedicated to a reader interested in the adoption of the Large-Scale Scrum framework.
BTW, if you reach this point of designing your organization and you are interested in the respective training, coaching, or consulting about the LeSS framework, reach out to me for advice on the certified LeSS trainers and coaches I can recommend.
I recommend this book to anyone who has reached the point of learning about product group design. Respectively, I suggest first reading the first book on this list and/or visiting the DAO course to optimize your learning experience and better understand the overall organization design with its principles before learning its specific part.
This book is dedicated to a reader interested in the adoption of the Large-Scale Scrum framework.
BTW, if you reach this point of designing your organization and you are interested in the respective training, coaching, or consulting about the LeSS framework, reach out to me for advice on the certified LeSS trainers and coaches I can recommend.
RECOMMENDED with Suggestions
I recommend this book to anyone who has reached the point of learning about product group design. Respectively, I suggest first reading the first book on this list and/or visiting the DAO course to optimize your learning experience and better understand the overall organization design with its principles before learning its specific part.
This book is dedicated to a reader interested in the lower-level design of processes within the product groups.
It contains a set of suggested experiments - literally, the sections are either "try ..." or "avoid ... "
I would say that the way of thinking you can grasp while reading the book is as valuable to learn as the experiments themselves.
BTW, if you reach this point of designing your organization and you are interested in the respective training, coaching, or consulting about the LeSS framework, reach out to me for advice on the certified LeSS trainers and coaches I can recommend.
I recommend this book to anyone who has reached the point of learning about product group design. Respectively, I suggest first reading the first book on this list and/or visiting the DAO course to optimize your learning experience and better understand the overall organization design with its principles before learning its specific part.
This book is dedicated to a reader interested in the lower-level design of processes within the product groups.
It contains a set of suggested experiments - literally, the sections are either "try ..." or "avoid ... "
I would say that the way of thinking you can grasp while reading the book is as valuable to learn as the experiments themselves.
BTW, if you reach this point of designing your organization and you are interested in the respective training, coaching, or consulting about the LeSS framework, reach out to me for advice on the certified LeSS trainers and coaches I can recommend.
Practices for Scaling Lean & Agile Development
by Craig Larman, Bas Vodde
by Craig Larman, Bas Vodde
Organizational Structure by Kjetil Sandermoen
SERIOUS CAVEATS
If you are keen to read this book, suggest you ensure that you do it ONLY after switching on your full power of critical thinking and ONLY after reading the first book on this list (or after joining one of the DAO courses).
The book contains some nicely explained important considerations relevant to product companies. For instance, I liked the first part of the chapter DEVELOPMENT VERSUS OPERATION explaining the danger of structuring in a way that various development units are placed inside operation-centric ones.
On the other hand, even in the example of this chapter, a very limited consideration of the possible organizational solutions. Here, splitting was the only considered option while actually there are much more options for the problem of Coupling between Unit Functions (which is not considered in this book at all) that you can read in the first book or learn in my courses.
And this is just one example while the whole book is full of suggestions without deeper analysis and lacking alternative solutions and answering WHY actually that or another solution might be preferable in the specific context.
Moreover, this book is solely about structures. However, structural decisions without consideration of other organizational elements are the reliable way to sub-optimize the whole organization. Furthermore, all the considerations are lacking the critical element - optimization goals.
And BTW, this book is not about building Agile organizations at all.
If you are keen to read this book, suggest you ensure that you do it ONLY after switching on your full power of critical thinking and ONLY after reading the first book on this list (or after joining one of the DAO courses).
The book contains some nicely explained important considerations relevant to product companies. For instance, I liked the first part of the chapter DEVELOPMENT VERSUS OPERATION explaining the danger of structuring in a way that various development units are placed inside operation-centric ones.
On the other hand, even in the example of this chapter, a very limited consideration of the possible organizational solutions. Here, splitting was the only considered option while actually there are much more options for the problem of Coupling between Unit Functions (which is not considered in this book at all) that you can read in the first book or learn in my courses.
And this is just one example while the whole book is full of suggestions without deeper analysis and lacking alternative solutions and answering WHY actually that or another solution might be preferable in the specific context.
Moreover, this book is solely about structures. However, structural decisions without consideration of other organizational elements are the reliable way to sub-optimize the whole organization. Furthermore, all the considerations are lacking the critical element - optimization goals.
And BTW, this book is not about building Agile organizations at all.
RECOMMENDED with Suggestions
I recommend this primer (as well as the materials on the respective website Org Topologies) to anyone who has reached the point of learning about product group design. Respectively, I suggest first reading the first book on this list and/or visiting the DAO course to optimize your learning experience and better understand the overall organization design with its principles before learning its specific part.
This is a unique and valuable tool for evaluating the adaptiveness of different types of organizational structures and structural elements - for instance, Agile frameworks and team shaping methodologies with their authorities and responsibilities. On the website, you can find detailed evaluations based on deep studies of various popular concepts. It also provides suggestions about the systemic approach to optimizations.
BTW, if you reach this point of designing your organization and you are interested in the respective training, coaching, or consulting about Org Topologies, reach out to me directly.
I recommend this primer (as well as the materials on the respective website Org Topologies) to anyone who has reached the point of learning about product group design. Respectively, I suggest first reading the first book on this list and/or visiting the DAO course to optimize your learning experience and better understand the overall organization design with its principles before learning its specific part.
This is a unique and valuable tool for evaluating the adaptiveness of different types of organizational structures and structural elements - for instance, Agile frameworks and team shaping methodologies with their authorities and responsibilities. On the website, you can find detailed evaluations based on deep studies of various popular concepts. It also provides suggestions about the systemic approach to optimizations.
BTW, if you reach this point of designing your organization and you are interested in the respective training, coaching, or consulting about Org Topologies, reach out to me directly.
Org Topologies Primer by Alexey Krivitsky and Roland Flemm
Team Topologies by Matthew Skelton and Manuel Pais
MISLEADING / DANGEROUS
In the beginning, the authors claim that the goal of their concept is to maximize speed. Later on, they mention that actually, their focus is first of all on the speed of change within teams. And this is exactly the optimization goal of the entire concept. However, this is not made clear from the very beginning and is hidden deeply inside - that is misleading.
Customer value is a result of work done in cross-component flows. However, three out of four team types offered by Team Topologies are de facto component-centric. Hence, customer value would have to pass through more than one of such teams.
Here is one of several good points from the book: "Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers." So, if you use those three component-centric team types, you will optimize for their internal flows which will not necessarily help improve your real customer-value flow. Moreover, from the Systems Thinking we know, that with considerable probability local optimizations sub-optimize the whole.
There's a single place within the whole book, where you can find the confirmation: "Generally speaking, we need to optimize for fast flow, so stream-aligned teams are preferred." This can be easily overlooked or forgotten behind numerous considerations of other component-centric team types.
Moreover, another claim is that "Team Topologies takes a humanistic approach to building software systems while setting up organizations for strategic adaptability."
Yet, it also contains one of the most dangerous points for Adaptiveness: "Every part of the software system needs to be owned by exactly one team."
This approach does not take into account the worldwide successful experience of applying the shared cross-team code ownership with respective adaptation of Structures, Processes, Rewards Systems, and People practices. As a result, this constrains the concept offered by Team Topologies to reach (by using only one out of four team types) only halfway to the true potential of Adaptiveness.
Finally, even concerning Organizational Adaptiveness, the book clearly and correctly stands for long-living teams and suggests team changes not more often than once a year or so. In other words, when you discover the teams were assigned to components wrongly, you will have to choose between waiting with lower speed or sacrificing the team's effectiveness with (again) lower speed.
A more detailed explanation can be found here: How Adaptive are Team Topologies?
In the beginning, the authors claim that the goal of their concept is to maximize speed. Later on, they mention that actually, their focus is first of all on the speed of change within teams. And this is exactly the optimization goal of the entire concept. However, this is not made clear from the very beginning and is hidden deeply inside - that is misleading.
Customer value is a result of work done in cross-component flows. However, three out of four team types offered by Team Topologies are de facto component-centric. Hence, customer value would have to pass through more than one of such teams.
Here is one of several good points from the book: "Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers." So, if you use those three component-centric team types, you will optimize for their internal flows which will not necessarily help improve your real customer-value flow. Moreover, from the Systems Thinking we know, that with considerable probability local optimizations sub-optimize the whole.
There's a single place within the whole book, where you can find the confirmation: "Generally speaking, we need to optimize for fast flow, so stream-aligned teams are preferred." This can be easily overlooked or forgotten behind numerous considerations of other component-centric team types.
Moreover, another claim is that "Team Topologies takes a humanistic approach to building software systems while setting up organizations for strategic adaptability."
Yet, it also contains one of the most dangerous points for Adaptiveness: "Every part of the software system needs to be owned by exactly one team."
This approach does not take into account the worldwide successful experience of applying the shared cross-team code ownership with respective adaptation of Structures, Processes, Rewards Systems, and People practices. As a result, this constrains the concept offered by Team Topologies to reach (by using only one out of four team types) only halfway to the true potential of Adaptiveness.
Finally, even concerning Organizational Adaptiveness, the book clearly and correctly stands for long-living teams and suggests team changes not more often than once a year or so. In other words, when you discover the teams were assigned to components wrongly, you will have to choose between waiting with lower speed or sacrificing the team's effectiveness with (again) lower speed.
A more detailed explanation can be found here: How Adaptive are Team Topologies?
Designing Agile Organizations
In my courses, I do not just teach but help people truly understand the organization as a system with its natural, context-agnostic laws of organizational behaviors and high-level essential capabilities necessary to deal with the most common challenges of product organizations. Using this understanding, my students can identify the inconsistencies in their own organizational design and undertake a tailor-made re-design of their organizations towards the optimization goals within their specific context.
During the last several years, I predominantly focused on providing courses within my client companies and starting this year, I am giving public courses too.
During the last several years, I predominantly focused on providing courses within my client companies and starting this year, I am giving public courses too.
Learn more
Cookies help us deliver our content and services. By continuing to use the website, you agree to the use of cookies.
OK