Team Structure #0: The biased thesis… or dogma.
I’ve been hearing/reading through years a lot of biased opinions about management, quality and structures that make absolutely no sense. When I question what are the bases of the falseability, I hardly (if ever) get a strong, convincing argument – mostly, it comes to:
I’m not sure a defined processes lead to quality.
If you’re not sure, read more, get in contact with people that worked in both environments (and filter their opinion), hear more, read more, get experience on that area (and spend some time on serious context-based criticism – including self-criticism), read more. Even the mos proeminent authors that discuss themes like Lean and Agile don’t argue that – they explore the organizational culture and how the misconceptions that often put by-product in the focus, instead of the product itself, or how to deliver and assess quality fast (small chunks, hipothesis validation, variability of product experience…);
Individual specialization leads to dumbification of the organization.
It’s one of the bumbest pseudo-neo-marxist thing I’ve heard. Forget about Marx a while and think objectively if there’s only one meaning to specialization… Is there a way you can optimize investment, have great expertise in multiple areas and still have people with an hollistic view? Yes! But we need to improve communications, create a information diffusion model, and understand and take situational leadership into account – a lot of stuff that IT people are not interested in studying;
Person/Project X did this and did/didn’t work.
Little is said about cause-effect relationship in these cases… Context is not taken into account, people’s competences background and – maybe the most imoprtant “forgotten” aspect – there’s absolutelly no comparison to a zillion other cases that used the same paradigm and came to an absolutelly different result. Therefore, a case is an important alert that we need further investigation, it doesn’t immediatelly refute or prove an hipothesis;
Theory doesn’t work.
Sorry, I don’t work with prejudice. This affirmation can be used in a church, but we don’t live in a dogmatic paradigm. Theories are built in a scientific framework that’s been working and evolving for centuries. Such statements are extremelly arrogant because it puts an individual opinion over all progress made by many in the scientific community. If you work in a dogmatic enterprise, all I can say is: RUN TO THE HILLS!
Well, in the end, I took more time than I expected… But still far from explaining the vast knowledge landscape that each affirmation are immersed. This post was intended to launch a series of other ones where I’ll try to elucidate what I’ve learned and how I think different software developing team structures work (or doesn’t) in a multi-product scenario: their strengths and weaknesses and how to deal with knowledge/competence specializations. Single-product companies may have different approaches… Although I’ve read some articles about them, I feel some more investigation is needed.