>It sounds like the teams they ended up with just weren't cross-functional teams.
You are exactly right! And yet everyone thought they were organized by functions/objectives/OKRs or whatever. The blind spot is what I want to highlight here.
"Data-Delivery" is an anonymization. The team shipped a specific data set that I did not want to name.
That is well put, and I'm going steal some of those words in the follow-up I'm writing. I essentially feel that teams should grow when tech and process initiatives have led to creation of a whole new problem space that can be explored independently.
Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
Thanks! Indeed, it's the interfaces that are hardest to define. I don't know a good heuristic to determine it I'm afraid - everything I've ever done was on intuition.
That is correct. Wen I am wrote about "communication overhead" I meant having to talk to other teams to get the work done. Talking within the team (including PM, stakeholders etc.) is, IMO, desirable to set the overall team vision and to keep everyone on the same page.
I feel that once two teams, no matter how closely related, get the feeling of two different "mandates" (often personified by two managers, sometimes not), it becomes very expensive to keep them aligned. It is probably faster(wrt achieving the end goal) to go with fewer people in one team.
At least when the approach works, I think the goal is to not have to have the teams aligned, instead giving them independent mandates that lead to the emergent behavior being what the business needs.
I agree. Looking at the "final practices" of a well-oiled team and just picking them up without any of the context about "why" they work "for that team" is half the reason no good idea (Agile, microservices, Jira) stays that way in software industry.
As an anecdote of this, I'm in an R&D department of a small company. I'm basically a team of one with an intern (which is its own challenge because he likes to be somewhat micromanaged). My manager just recently was finally convinced to shift from a waterfall module to something agile, except now it's just becoming a micromanagement tool... for a team of essentially 1.5.
We had a conversation the other day in which I was given to understand that if we thought some documentation was finished, but had to go back and make a tweak with no more than 15 minutes spent on it, we should be creating a ticket in Jira to do so. I'm currently cursing all the people who've sold agile because this is insanity (imo).
Feels good to get that off my chest haha.
That's literally not how it works too. Agile has a robust and rigid structure that you then pull from and adapt to make your team and processes better. Few teams have the same implementation. It's important to understand the full scale of agile practices and tools but do not try to do it 100%, that's not the idea at all.
This is a deceptively simple rule engine that I built for some side projects but has has since been picked up for many things that the big guns would have been overkill for. Clobbered the first version together in less than 5 days too!
I'd take some trade-off between between crazy optimization and maintainability, but I'd definitely rather do this than slap on any number of frameworks because they are the new 'standard'.
Of course, the guy who has to maintain my code usually ends up crying like a little girl.
