Scaling Agile at Gilt
With teams, ingredients, initiatives and KPIs
Spotify recently documented their progressive approach to scaling Agile development with a fairly large team. Gilt’s approach has many similarities, but since some Spotify best practices are Gilt anti-patterns, it’s worth a closer look.
The Gilt tech team is about 100 strong. Most of our development is done in Manhattan. We’ve also got a small team in Portland, Oregon and a larger one in Dublin, Ireland.
The cornerstone of the Gilt process is the initiative. We define an initiative as “a project we expect to work on for the foreseeable future.” Our foreseeable future is typically 3-12 months, depending on the area. An initiative might be to increase organic search traffic to the site.
We work on the order of 10 initiatives in parallel. The decision to green light an initiative depends on a number of factors. The most significant factor is a mathematical model of how we expect the initiative to perform, but we also consider softer factors like direct customer happiness and innovation.
Prioritizing a set of initiatives focuses the technology group on an initiative portfolio. This portfolio makes a clear statement on what is important, and indirectly, what is not. This has had a profound effect, halting our previously unending feature level prioritization discussions. This change has made not only our team happier and more productive, but also our stakeholders.
Unlike Spotify, we don’t maintain a roadmap document. Our roadmap is simply the sum of active initiatives. We revisit the set of prioritised initiatives every few months.
Initiatives are defined in terms of the key performance indicators (KPIs) used to measure them. We define two types of KPIs. Strategic KPIs measure the success of the initiative’s strategy and last as long as the initiative. Tactical KPIs measure the performance of the initiative’s tactics and come and go as tactics evolve. All tactical KPIs must drive a strategic KPI.
For example, our SEO initiative might be defined by the strategic KPI: “Number of organic visitors in the last 30 days.” If current tactics involve stimulating inbound link creation a tactical KPI might be: “New inbound links in the last 30 days.” That tactical KPI would be abandoned when the initiative no longer employed that tactic, either because the team no longer thought they could get more out of that tactic or the team discovered a new tactic that could drive their strategic kpi faster.
We consider initiative mission statements an anti-pattern. “To be great at Organic search!” is simply a more subjective, and less useful denormalization of the strategic KPI.
We organize ourselves into teams (Squads in Spotify parlance) of around 4-10 cross functional members who sit together. Teams focus on a single initiative but may own others that are less active. Team members have a lot of input in selecting the initiatives their team works on.
Team dynamics take a while to form and stabilize. Consequently we favor long running teams, surviving generations of initiatives. However mobility between teams is encouraged and takes two forms. Teams self-organize to swap engineers periodically to manage skills deficits or unexpected workloads, in a practice affectionately called “horse trading.” When teams take on new initiatives it’s not unusual for an engineer with a particular interest to permanently switch teams to work on that initiative.
Unlike Spotify Squads, teams are not tied to Initiatives. We anticipate teams outliving initiatives, and being able to handle concurrent initiatives. This doesn’t preclude a team having a single initiative for it’s lifetime.
Like Spotify, we strive to make a team operate and feel like a startup. Our teams have a strong identity and are empowered and independent. Teams are self organizing and self prioritizing.
Teams select their own development methodology. Agile methodologies are strongly encouraged and most teams have backlogs, stand-ups, sprints and retrospectives. Some adopt more rigorous Agile methodologies.
Strong team code stewardship is encouraged. We use stewardship to describe an ownership model where one team owns repositories of code and takes responsibility to encourage, review and approve modifications made by other teams. Gerrit is used to facilitate the review process.
Unlike Spotify, teams have no product owners or business owners. Some teams include business partners. Ownership is considered an anti-pattern since it implies disempowerment of the team members who are not owners. KPIs and collaboration are king. Also unlike Spotify, we don’t appoint different individuals to the doing and prioritizing of work, believing these concepts are fundamentally indivisible. Prioritization happens by the team vigorously debating hypotheses and coming to agreement on the next hypotheses to test, factoring in both impact and feasibility.
Teams release early and often. “Minimum Viable Product” is a Gilt mantra.
Teams are encouraged to be highly analytical. We a/b test almost everything and discourage making decisions based on gut instinct. However, we respect intuition and encourage broad hypothesising to ensure we optimize towards global rather than local maximas.
Teams are organizationally flat and cross functional. To increase the likelihood they’ll execute successfully on their initiatives we use a palette of team ingredients as a guide to ensuring the team is appropriately staffed.
For a team to be successful at Gilt they need some combination of the ingredients: product visionary, coder, presenter, visual designer, business thinker, organizer, motivator, quality manager, coach, analyst, architect, writer, visual designer and ux specialist.
Rather than filling a narrow role, team members add a set of ingredients. This expectation both pushes and nurtures each team member. We don’t consider “It’s not my job to …” an acceptable way to start a sentence.
Depending on each team’s initiative, a different blend of these ingredients is optimal. One person might provide several ingredients, for example, a member who conducts tests, writes feature code and collects and analyses data.
Teams lacking key ingredients are assisted either by adding additional members or by external coaching.
A bi-weekly check-in gives each team a regular opportunity to provide an update on their results and seek guidance on their current direction. In addition to the team, attendees to this meeting alternate between a panel of technical managers and a panel of senior executives from across the company.
All check-in meetings have the same agenda. (1) a presentation of KPIs and their history (2) a presentation of recent a/b tests or other recent data and the associated learnings and insights (3) the story: a quick overview of tactics for the next few weeks.
The prescriptiveness of this agenda is to encourage teams to go deep on the strategy and the data supporting it and avoid discussing feature and UX nuances. Unchecked, these discussions historically tended towards feature debate at the expense of discussing results.
To allow teams to operate as autonomously we encourage the decentralization of almost everything.
Decentralization minimizes the dependencies teams have on other teams or systems, allowing them to develop code and release it to production with minimal external interaction.
Recently we’ve made a large investment in the tools and automation to enable this decentralization. We’re well on our way to fully automated system provisioning and configuration.
We’ve made a similar investment in our application architecture, moving away from monoliths and towards lots of small independent applications and lots of small independent services. This in combination with our continuous delivery pipeline allows teams to take complete control over delivering software to production. Although we’ve made a big investment here, it’s a work in progress.
In addition to the bi-weekly check-in meetings, we encourage the use of several other mechanisms for cross team communication and collaboration.
- Tech Bytes: Monthly, each team sends out an email to a broad distribution, outlining the recent achievements of the team, framed by their KPIs.
- Lightning Presentations: Teams self-organize to run a meeting with quick-fire presentations on notable pieces of technology or features that have been developed or deployed recently. Everyone is welcome at the meeting and pizza and beer serve as bait to attract a wide audience.
- Hack sessions: techies are encouraged to periodically take a break from their initiatives and join forces with other teams to work on things they care deeply about. Projects run the gamut from architectural changes, tools, bug squashes, a/b test infrastructure to user facing features.
- Stakeholder Communication: Teams self organize to communicate regularly with and get input from their various stakeholders.
- Guilds: Gilt has a fairly loose implementation of the Guild concept, defined by Spotify as an “organic and wide-reaching ‘community of interest’, a group of people who want to share knowledge, tools, code, and practices.” We have fairly active groups that self organize around areas including front end engineering and architecture.
Does this Process Work and Will it Work for You?
Over the years we’ve used several different approaches for managing and organizing the Gilt development team. The one described above has been in active use for about 15 months.
The current approach embraces technology as a key differentiator for Gilt and serves to establish our technology department as a leadership organization rather than a service organization.
Being a leadership organization sounds great, but it’s not a panacea. It creates additional demands on teams, and requires them to have a deep understanding of our business and a strong point of view, clear vision and driving ambition. We need entrepreneurs to make this model succeed.
Not all technologists want to take this on. If you do, this approach might work for you.