Philosophy

An Agile organization is the inverse of a top-down bureaucracy. Continual adaptability is the aim, and it happens through bottom-up growth. Organizations are most adaptable when teams work as value delivery units, considering other teams as the customers to whom they deliver value. You know that you've achieved organizational adaptability when employees initiate and respond directly to each others' attempts to communicate and coordinate the resources they need, when managers nurture direct communication (rather than feel the need to control it to, say, prevent disasters from spreading), and everyone stops complaining about re-orgs and enthusiastically suggests organizational structure changes themselves.

Teams (rather than roles or individuals) are where the magic happens. Teams are better able than individuals (i.e., managers) to absorb challenges and handle information-intensive work; to disseminate relevant information; to converge on standards and ensure their adoption; to develop competencies and complementary strategies for collectively addressing gaps and achieving high performance; and to support effective feedback mechanisms. When people feel they are part of a team with a distinct identity, they are much more willing to adapt their behavior for the common cause. Teams are key to an organization's self-reflection and advancement. Also, working in teams creates more success and more joy.

In practice, this means that managers need to become better coaches and individual contributors need to become better leaders. And all levels of management and all support teams visualize and respect the organization as an interconnected system of constraints and relationships (rather than as a collection of individuals to be allocated and governed). With this shift also comes the recognition that a manager's primary responsibilities are to create alignment, clearly communicate constraints, supply the right people, enable information flow and connectivity between teams, coach their teams, and establish and support feedback cycles (versus creating rules to prevent problems). While no one wants preventable problems slowing things down, controlling deviations from interpretations approved by leadership is not an Agile approach to understanding the organization as a system and understanding how its environment enables or obstructs its stated goals.

Principles for Creating an Agile Org Chart

There is no one-size-fits-all approach to organizational adaptability. The org chart of your Agile organization will reflect management's readiness to empower teams (and to enable freedom of communication across the network) as well as the teams' competencies in both technical and leadership skills. But there are a few principles to follow:

• Let the communication needs guide the definition of team boundaries. Which people need to talk to each other most? Development teams (whether they are developers, testers, BAs, or database analysts) on a common product or project more frequently need to talk with each other than they do their own kind on other products and projects. However, communication among infrastructure administrators is usually more intensive than with specific product or project teams.

• If there is every any question, favor organizing teams around the business (e.g., the customer, products, or projects) rather than by function (developers with developers, testers with testers, etc.). Functional silos have a high interaction penalty.

• Set up functional teams to operate as support teams which service the business-based teams, not control them. The business-based teams are the customers of the functional teams, and the business-based teams decide whether or not the functional teams are delivering value. To counterbalance the tendency for functional teams to (sub)optimize at their own levels, the business-based teams reserve the option to go elsewhere to get their services (e.g., by building that role into their own team).

• To drive competence in areas of specialization, facilitate communication, and coordinate of standards and shared resources across cross-functional team boundaries, create specialization programs or Centers of Excellence for each kind of similar work carried out across cross-functional teams (DevOps, Quality, etc.). The programs and/or CoEs counterbalance the tendency for business-based teams to stagnate and/or (sub)optimize practices locally. Note that business/product/project-based team members do not report to a specialized program or Center of Excellence. (This also goes for a Project Management Office.)

• Provide managers for any area (whether a business team, a functional team, or domain specialty) that needs governance and/or competence building within the organization. Domains where the organization has low-levels of maturity and teams that are more inexperienced in their technical or leadership skills will require more intensive management that can give them greater focus and coaching.

• Do not ask people to spread their loyalty across teams. People cannot act as a team if they don't know what the team is. Such situations lead to task-switching, conflicts of interest, and loss of commitment and motivation. They may occasionally assist other teams and help out on other projects, but each person should have exactly one base team to return to.

• Keep teams intact for as long as possible. It takes a long time for communication paths and rules in a team to grow and pay off and for them to learn which information is important to them and which is not. Also, teams organize themselves to collectively absorb and effectively respond to the demands on them. Reconfigurations of teams destabilize their productivity and motivation in ways that cannot be mitigated by a simple backfill or rewrite of a role description.