Scaling Your Agile Organization
If you work in a growing, Agile organization, you will sooner or later face the challenge of trying to keep your multiple, autonomous, Scrum teams rowing in the same direction. I work at Appian where the Engineering team builds a low-code platform for rapidly creating Web/Mobile Enterprise apps. Appian Engineering has grown from a few dozen people to over two hundred over the past few years! Like many software product companies, Appian Engineering has staff with the following core competencies:
As we started growing, we quickly realized that we would have to make way more decisions than could be handled in a timely manner by a centralized management team. Additionally, our staff had to be aligned with departmental goals and we had to draw boundaries to clarify ownership of features and bug fixes. We knew we needed to bring some order to the chaos, while still preserving the independence and speed of our teams.
We came across the Spotify model that promised both alignment and autonomy by adding Scrum teams called Squads to a Group (Spotify called this a Tribe), with Chapters and Guilds to connect people across the department that have related skills or common interests.
We have built internal applications to plan and execute our work by dogfooding Appian. We manage our priorities via a Product Annual Plan of initiatives, loosely projected over the next 4–6 quarters. Longer term priorities are maintained in a Product Portfolio Backlog.
Our investment areas map naturally to Engineering Groups. Each Group owns a multi-year mission. Group-level decisions are made quickly by senior staff such as the Group Development Lead (all Software Engineers report through him/her), the Group Product Lead (all Product Owners report through him/her), and Group Quality Lead (all Quality Engineers report though him/her).
Each Squad focuses on one of its Group’s missions and takes anywhere from a few quarters to a few years to complete. For example, one of our Squads is working on Mobile Push notifications. As Squads finish their missions, they may re-form around new missions. Squads also allocate up to 20% of their time to maintain code health.
A few Infrastructure Pods (small teams) work on build and deployment tools. For example, they may help streamline CI (continuous integration) testing to speed up our release delivery pipeline.
Chapters are groups of 3–9 people within a Group focused on professional growth. We set aside 5% of our work hours for “learning time” which may be via Chapters or other less-structured means, ranging from group discussions, spiking, building tools, and getting certifications to consuming or creating training content.
Guilds form around areas of common interests or needs, such as the Education Guild, which my colleague Dale wrote about recently. One fun Guild is our Community Guild, which focuses on ensuring that we retain our sense of community as we grow; they organize team events (picture below) and outings that encourage people to mix and bond, helping keep Appian one of the “best places to work.”
One gap we noticed in the Spotify model was that as we added more teams, we needed a way to keep them aligned along common dimensions of strategy, people, process, and technology. To close this gap, we invented the concept of Councils. Think of a Council as a Guild with mandatory attendance. The Councils below help us manage a rapidly growing department:
Councils drive cross-departmental improvements and communications. Councils have representation from each Group and departmental function. The diagram below depicts our matrixed leadership model:
Each Council is led by a Vice President in the department and convenes on a monthly basis. Councils have to be adept at influencing teams and driving organizational change. For example, read how we encourage collaboration around the investigation and choice of technologies.
Council leaders:
- Systematically identify issues and solutions with multiplicative impact
- Exert broad influence, inspire initiative, and spark collaboration
- Organize activities, define processes/artifacts, and measure outcomes
- Relentlessly rally support around strategic initiatives
- Mediate conflict and drive prompt resolution
We’ve had Councils in Appian Engineering for the last couple of years and continue to refine what they focus on and how they operate. So far, our Councils have played a prominent role in managing departmental strategy/capacity, improving staff management, streamlining our processes, and in formalizing design reviews/debriefings. Could Councils help your organization? We’d love to hear your thoughts!