The twelve principles of the Agile Manifesto provide the basis for interpreting and implementing any Agile technique. One of the hardest principles for many organizations to adopt is:

Business people and developers must work together daily throughout the project.

Many implementation approaches have been designed to minimize the organizational inconvenience of this principal, such as  using proxies for the business or abandoning the principle altogether. The goal is to involve the business users (also know as the product owner in Scrum), so they can act as voice of the product. Fully embedding business personnel into the project team is often considered the most radical approach. However, is embedding radical or just not a one-size-fits-all solution? Embedding is a powerful tool, therefore it can be perceived as radical. Because of the perception of this technique and the power it is not a one-size-fits-all solution.

Embedding removes the product owner from their normal job and makes them part of a project team. This has an organizational cost, which includes the cost of replacement even if replacement just means that other colleagues have to pick up the slack. A second and more personal cost occurs on long-term projects. Embedded business personnel need a return path back to the business, or a path into the more technical world (the path I took once upon a time), or they risk career failure.

The costs of embedding are can be high. But, the benefits are generally equally large. The benefits, as we have discussed before, include intimacy of communication and reduction of project risk.

Should every project have a plaque memorializing embedded business personnel?  No, not every project requires embedded business personnel. Striking the balance between cost and value is part of the art of implementation. While this technique should be part of your Agile toolkit, I would not suggest that it should be a one-size-fits-all solution.