I started thinking about this recently because there was an Agile Austin QA SIG meeting that I sadly couldn’t attend entitled “How does a QA manager fit into an Agile organization?” which wondered about how to fit members of other disciplines (in this case QA) in with agile teams. Over the last couple years I’ve tried this, and seen it tried, in several ways with DevOps, QA, Product Management, and other disciplines, and I thought I’d elaborate on the pros and cons of some of these approaches.
Two Fundamental Discoveries
There are two things I’ve learned from this process that are pretty universal in terms of their truth.
1. Conway’s Law is true. To summarize, it states that a product will tend to reflect the structure of the organization that produces it. The corollary is that if your organization has divisions which are of no practical value to the product’s consumer, you will be creating striations within your product that impact client satisfaction. Hence basic ITSM and Agile doctrines on creating teams around owning a service/product.
2. People want to form teams and stay with them. This should be obvious from basic psychology/sociology, but if you set up an organization that is too flexible it strongly degrades the morale of your workers. In my previous role we conducted frequent engineer satisfaction surveys and the most prominent truth drawn from them is the more frequently people are asked to change roles, reorg, move to different teams, the less happy they are. Even people that want to move around to new challenges frequently are happier if they are moving to those new challenges with a team they’ve had an opportunity to move through Tuckman’s stages of group development with.
I have seen enough real-world quantified proof of both of these assertions that I will treat them as assumptions going forward.
Organizational Options
We tried out all four of these models within the same organization of high performing engineers and thus had a great opportunity to compare their results.
Separate Teams
When we started, we had the traditional model of separate teams which would hand off work to each other. “Dev,” “Ops,” “QA,” “Product” were all under separate management up through several levels and operated as independent teams; individual affinities with specific products were emergent and simply matters of convenience (e.g. “Oh, he knows a lot about that BI stuff, let him handle that request”) and not a matter of being dedicated to specific product(s).
Embedded Crossfunctional Service Teams
Our first step away from the pure separate team model was to take those separate teams and embed specific members from them into service oriented teams, while still having them report to a manager or director representing their discipline. In some cases, the disciplinary teams would reserve some number of staff for tool development or other cross-cutting concerns. So QA, for example, had several engineers assigned to each product team, even though they were regarded as part of the permanent QA org primarily.
We (very loosely) considered our approach to be decentralized and microservice based; Martin Fowler is doing a good article in installments on Microservice Architecture if you want more on that topic.
Fully Integrated Service Teams
With our operations staff we went one step farther and simply permanently assigned them to product teams and removed the separate layer of management entirely. Dev and “DevOps” engineers reported to the same engineering manager and were a permanent part of a given product team. Any common tooling needed was created by a separate “platform” engineering team which was similarly integrated.
Project Based Organization
Due to the need to surge effort at times, we also had some organizations that were project, not product, based. Engineers would be pulled either from existing teams or entire teams would additionally be pulled into a short term (1, 2, 3 month) effort to try to make significant headway across multiple products, and then dissolve afterwards.
Hmm, this looks like it’s getting big (and I need to do some diagrams). I’ll break it up into separate articles for each type of org and its pros and cons, and then a conclusion.
the agile admin 
I seriously need to sit down with you one of these days and try and cross pollinate much of what you speak about with here on projects I’m working on with enterprise IT systems.
Sure, be happy to. In fact, it’s a somewhat opportune time; I’ve left my previous gig and am taking a little time to write and get caught up on side stuff before starting something new, so I’d have more bandwidth than usual to give it some thought.
I’d love to join that chat, as we’re developing Kumolus around much of what you speak of here.
Thanks for writing about this topic and for the links to the other resources and ideas, especally Martin Fowler’s writing. I’m an agile coach — not a developer, though I work with/for them — at a comparatively small company ( 500 employees). I came to your blog trying to find some advice and process tips for services or data teams made of individuals who each have subject matter expertise for two or more systems / operational areas with little to no overlap. Assuming that there are good reasons for this set-up right now (e.g. company size, legacy and maintenance, and organization transitions) and that increased shared discipline strength among all teammembers isn’t necessarily a high priority, do you have any suggestions for planning work, pairing, awareness of and reaction to issues, and general process and/or team set-up optimization? (Turning stand-ups into a “walk the wall” format as well as making time during the sprint demo to briefly explain stories, lessons learned, and any “gotchas” to the rest of the team are two of the ideas I had for the short-term.) Thanks.
Hello – Very helpful & interesting analysis. I’m having trouble locating the remaining 3 articles discussing pros and cons of each, plus the summary. Can you point me to these? Thanks!
Ah, never quite got around to it I’m afraid, but since you asked maybe I’ll dust it off!
That’s what I was afraid of 😦 Would love to see more! Thanks.
Eagerly awaiting your next article in this series
Hi
Thanks for taking you time to write these articles. I believe they “hit the nail on the head” for the discussions and challenges we face in my current company.
I have read the whole series, however i can’t seem to find the last article which assumably should be the “Combos and conclusions”. I may have overlooked in the archive but i hope it is written, and It’s there somewhere 🙂
Ah good point. Maybe I’ll write it soon; Karthik and I are working on a DevOps Fundamentals: Lean and Agile course for lynda.com so it’s at top of mind.
Have you post your conclusions finally (Combos and Conclusion section)?
I haven’t; I’m naughty… I still hope to get to it, since then I’ve worked in a lot of different org structures trying to accomplish agile and have seen a lot of options. The TL;DR is that I find the embedded crossfunctional model works best but requires you to really be committed to Agile and doing things right and committed to management maturity, and the nature of a company being “project driven” or whatever is usually made at a high enough level that you really just have to “make do” within those constraints.