This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Maybe a bit of a controversial and/or naive question, but why is it that I see many agile practitioners that are seemingly fundamentally against the idea of explicitly designing teams and their interaction modes (according to, for example, the four fundamental topologies and three interaction modes recommended in the book)? Many agile practitioners’ go-to sentiment in this regard is always something like “flatter is always better than hierarchical” or “collaboration is always a good idea” or “teams should always be feature teams”. I for example personally know some people who would balk at the idea of research: https://www.pnas.org/content/115/35/8734 (referenced in the book).
Maybe a bit of a controversial and/or naive question, but why is it that I see many agile practitioners that are seemingly fundamentally against the idea of explicitly designing teams and their interaction modes (according to, for example, the four fundamental topologies and three interaction modes recommended in the book)? Many agile practitioners’ go-to sentiment in this regard is always something like “flatter is always better than hierarchical” or “collaboration is always a good idea” or “teams should always be feature teams”. I for example personally know some people who would balk at the idea of research: https://www.pnas.org/content/115/35/8734 (referenced in the book).
I was reading through Conway's original paper this morning and had an AHA moment (I believe). I don't do software development or work directly with software developers. I'm an architect (Cloud, Azure) and in my organization I work with other architects across other business divisions (IE: Silos) to come up with solutions (statements of work) for customers. I believe I understand now why the more engineers and architects from different areas are involved, the more complex and complicated the "solution" becomes because each "silo" is incentivized to make sure they contribute something to the solution so they get compensated and show their value. Am i overthinking this or completely off base here?
I was reading through Conway's original paper this morning and had an AHA moment (I believe). I don't do software development or work directly with software developers. I'm an architect (Cloud, Azure) and in my organization I work with other architects across other business divisions (IE: Silos) to come up with solutions (statements of work) for customers. I believe I understand now why the more engineers and architects from different areas are involved, the more complex and complicated the "solution" becomes because each "silo" is incentivized to make sure they contribute something to the solution so they get compensated and show their value. Am i overthinking this or completely off base here?
Reading this book and having these discussions has been a revelation for me. The past five years has been one dysfunctional org after the next with a lot of well-meaning people having no idea how to realize the things 'devops' promises. Unfortunately in each case I have been an IC with no real influence over the process so I end up having to move on to the next gig, where I hear the same dreams and promises and experience the same or slightly varied anti-patterns in play. I'm optimistic that my current leadership gets it and will benefit from the suggestions I take from here, but if not I'll just have to look for another gig where I can build the team myself!
Reading this book and having these discussions has been a revelation for me. The past five years has been one dysfunctional org after the next with a lot of well-meaning people having no idea how to realize the things 'devops' promises. Unfortunately in each case I have been an IC with no real influence over the process so I end up having to move on to the next gig, where I hear the same dreams and promises and experience the same or slightly varied anti-patterns in play. I'm optimistic that my current leadership gets it and will benefit from the suggestions I take from here, but if not I'll just have to look for another gig where I can build the team myself!
I'm definitely rating this book up there with TPP and Accelerate for anyone who wants to understand the why AND the how of devops.
I'm definitely rating this book up there with TPP and Accelerate for anyone who wants to understand the why AND the how of devops.
<!here> Chapter 7 discussion question as well as an additional resource link from the authors.