Anyway, it is very common that software company is having a organization structure following the Conway's Law. I have been part of these companies and seen them trying to implement Scrum. Here's what happens according to my experience:
- One team is chosen to be a pilot team for Scrum, this team is a "architectural layer" in the product, usually something like "core" or "platform" team (as they are usually most experienced engineers in the house)
- Team tries to implement Scrum, they wonder why their velocity is not getting stable (even the Book says that it should after few sprints).
- The team realizes that the velocity is not getting stable cause they are not in full control - they are impeded a lot by other teams (like database team that is underlying in their architecture, or client team which is on top of them).
- They raise the issues to the organization as they feel that fixing all the dependencies is out of their hands and should be handled by the organization instead. Usually a issue is that other teams are doing waterfall and do not have enough information (as their project is in "requirement gathering phase") to support the one and only Scrum team.
- The organization follows the Book and wonders "what happened to the self-organizing team". The organization rejects to lead and facilitate and tells the team to "go and figure it out". Cross-functionality is not approved as the original goal was to do "pilot first" to see if Scrum works. (Yeah yeah, they are breaking one of the rules of Scrum: cross-functional teams... but hey, they started from Conway's Law, what do you expect)
- One of the following happens:
- Team turns to anti-Scrum, they do not like it as it just brings all the problems to them and makes them endless problem-solving task force
- Organization drops Scrum - "It does not work for us"
- Team starts hating organization - "Organization does not support us"
One more note, as a manager do not ask the team to go and figure everything out - they may do it, but you will not have transparency anymore as the team does everything under the hood. Impediment should be raised when team faces problems that are created by organizational boundaries. I have seen teams applying "Go and See" (Toyota Way) and fixing everything ... and over a time totally lost their focus as they do not know anymore what is their responsibility and thus not raising anymore impediments. This may or may not be real life example:
Development team was asked to develop a piece of software and "put it in production". The team maintaining the production system was not involved and they were "too busy" to support the development team so the development team (as result of self-organizing) bought their own hardware, setup "production like" environment and started operating that as "production environment". All this, without the "production system team" knowing anything about it.
Imagine what would be the result of doing this with several development teams - you would have as many "production systems" as you have development teams. Ouch.
Anyway, pay attention to your Scrummers ... till next time.