Back in the previous section, How an Agile approach will organically flatten an organizational structure, we looked at one way that Agile teams will impact on an organization with a hierarchy.

Just to recap, because we're a self-organizing group of just do it people, when an impediment, such as our organizational structure, gets in the way, we tend to push on through. By recruiting our wider stakeholder group to this cause, they will connect us with the people who can help us.

That's the way we work; if we need the knowledge of a specialist in the marketing department to get our job done, we'll collaborate with them—we just need to find out who they are first.

Over time, we'll start to experience an informal shift in our organizational structure, so even though we might still look like a hierarchy on paper, functionally we operate more like a network.

Eventually, our organization may catch up with us and we'll formally restructure to take into account the way the orgnization works. That structure may look a little like the following, where the network has formalized around key products:

Here we see teams which were in the divisions called Product, Marketing, and Sales, now working in cross-functional collaboration in three different groups. The teams within each product group will be co-located at this point.

It's likely that this structure will continue to follow the same communication pattern; as you can see with Product 3, the Sales and Marketing teams have already merged. Over time, as the teams continue to hone their collaboration and communication network, they are likely to merge further.

If we do little else other than encourage it, the informal communication/collaboration structure will happen organically. If we want to influence the outcome, then we probably need to do some thinking about how our products are built, and more to the point, how we want them to be built.

The following are a few possible patterns:

• Completely separate (no interaction)
• Separate but of the same family, for example, interacting via an API
• The same product but different platforms, for example, split by device—web or mobile
• Different parts of the same product, for example, the search strategy across all devices, the membership strategy across all devices

Either way, we're likely to see the team's communications with each other follow the architectural patterns that we lay down.

The key takeaway from this is that if we let the people who are part of the system self-organize, they will find the path of least resistance to getting their jobs done. They're smart, capable, and resourceful people who want to be successful. If we set the right boundaries, they will find the right way.

When we talk about scaling our approach, there are three aspects:

1. How we break down the work to be completed by multiple teams (architecture).
2. Co-ordination, communication, and collaboration (team structure and culture).
3. Closing the feedback loops: Have we built the right thing? Are we building it right? (The instigator of change and improvement in our approach).