Effectively scaling any methodology is a problem of establishing, coordinating and controlling the goals of each team that is working together to deliver a project or product. Clearly scaling any type of work is not straightforward. At the very least, every new person and team increases the number of possible communication channels. The formula, n (n – 1) /2, is non-linear; a project with 2 teams has one channel while a project with 10 teams has 45. Many Agile techniques were developed (or, at least, evolved) as team level, and don’t address goal coordination. Scaling Agile requires taking a different tack than just adopting classic plan-driven methods and frameworks and putting them on top of team-level Agile.
Coordination of goals across multiple teams, projects and programs is not a new problem. Classic development techniques have adopted many practices to address goal coordination. The focus of the classic mechanisms has been on assigning responsibility, creating documents and then getting them signed off by all stakeholders. This is followed by having external parties validate that the process was followed and the goals met. Roles in the classic approach include project managers (assigned to be responsible), process and product quality assurance analysts (to enforce the process), independent testers (to assure the team meets goals) and a myriad of others including PMO personnel, architecture review boards and more. The cycle of assigned responsibility, documentation and enforcement keeps the work moving in the right direction, albeit it is easy for the team members not feel a direct responsibility for the top-level goals.
Team-level Agile techniques, for example the ubiquitous Scrum, do not address keeping the goals of multiple teams synchronized with higher-level project or product goals. In Agile, one team will deliver small and uncomplicated projects. I have worked with many large organizations in which projects fit this scenario, but not all projects, in any organization, will be small and uncomplicated.
One of the most important attributes of Agile is to push decision-making down in the organizational hierarchy. Agile teams make decisions closer to the work. In order for teams to make effective decisions, they need to understand a project’s or product’s high-level goals and how they fit together into a whole. Spreading that knowledge to those making decisions the decision-making process is critical. If those making the decision don’t have a handle on the big picture goals someone at a higher level will need to make the decision. Organizations need to take steps make Agile work where everyone understands the overall goals and then to keep team-level goals synchronized.
Use typical Agile techniques such as planning, stand-up meetings, demonstrations at a higher level and combined with program level continuous builds and testing to coordinate goals. When practiced together they can be a tool to make sure everyone is exposed to the big picture and stays synchronized to the big picture.
Regardless of how an organization decides to solve the problem, if they do decide to solve it, the options are stark. You either use the control model from classic project management technique or an upsized version of Agile that includes both project management and technical attributes.