Org chart worship happens when Agile teams are created in a way that fits with the org chart, rather than a way that fits with what is needed for Agile.
So if the org chart says 'our testers are a part of department Q under Mr V. Model', and therefore department Q is structured into 'Agile' teams full of testers, then we may have a missed point error, because there's no way a team of testers ( or architects, or coders, or requirements engineers ) can take a story and turn it into working code.
Sometimes organisations will juggle with semantics in order to rationalise such an arrangement. Perhaps the backlog becomes a list of things needing system test, and 'working code' becomes 'a tested iteration'. This sort of thing is at the heart of the thorny problem of 'scaling Agile'. One particularly disingenuous wriggle is to label the entire software development function, which may be comprised of far more people than the 10 that the Scrum Guide refers to, as 'the team'.
This does not mean that Agile organisations shall have no org chart. It just means being careful to recognise that the org chart is a management artefact, and Agile strongly emphasises cross functional teams, which will often need to be composed of individuals from different parts of a functionally oriented org chart.
There can be tremendous resistance to making this happen, because it alters the job description of an entire layer of middle management, as the teams to which 'their people' actually belong are no longer teams under their control.
Not all org charts are strictly functional. Often there's a division structure that reflects product types for example. Ultimately, where exactly the members of Agile teams come from in organisational terms is a question for the business, but whenever the organisation interferes with the formation of cross functional teams then Agile will struggle to deliver significant benefit.
A particular problem here is that large organisations will always want to do as much of the work as possible in the cheapest possible location. There's nothing fundamentally wrong with reducing costs by spreading the work around the world. But if it results in a situation where team members are spread over an array of time zones, then even in our highly connected world it creates problems for forming effective cross functional teams.
I'm not saying it can't be done, but if you wish to do Agile development in these circumstances then it's a problem you must face up to. There's a limit to the amount of time zone shifting that people can reasonably be expected to do, and although opinions differ, the productivity hit of working via collaboration tools in an Agile context may be significant ( such tools were not around when the Agile Principles were formulated ! ).
There's a very loud strand of Agile thought which argues that an Agile team must work in the same room. I'm not going to pursue this argument here, but Agile expects very close cooperation between team members ( see Principle 6 ), and anything that interferes with that is bad news from an Agile perspective. One of the primary responsibilities of Scrum masters is to ensure that impediments to communication are minimised.
© Mark de Roussier 2021, all rights reserved.