After more than 10 years working in, leading, and managing development teams at Say that ranged from 3 to 100, I've seen a lot of different capital-P Processes. We've experimented with every version of agile, implemented scrums, stand-ups, kanban, pair programming, planning poker, Fibonacci story points, and iterative waterfall...

But just in the last year or so, we've finally settled into a process that really works. I'm a firm believer that the process needs to be crafted around the particular company, people and work, so I'm certainly not advocating this as the Right Way for anyone but us. But it sometimes feel like Silicon Valley gets stuck in its current way of working (everyone I know currently follows some version of Scrum-Light) -- so I thought it could be useful to describe another option.

The Old Way

Before we moved to our current process, we were a fairly standard Scrum shop. Engineers worked in teams of 3-6 alongside a dedicated product manager, with a team representing each major technology area (CMS, sites, ads, data, ops...). Teams worked in two week sprints.

While we were reasonably good at this process and getting stuff done, there were a lot of small frustrations:

Cross functional work was a pain in the ass. Almost every business initiative spanned multiple teams, so in order to build a feature we'd need to carve that up across multiple product managers and multiple sprint teams. Dependency management slowed everyone down.
People were spending more time planning work than doing it. Every two weeks there was a sprint planning meeting, a retrospective, a demo, and a sprint pre-planning meeting. Every quarter we had a long series of planning meetings, which usually took half the quarter to complete.
Engineers were working ticket-to-ticket instead of solving business problems. We have amazing engineers who actually care about the space and want to solve problems, but they ended spending most of their time working down a list of tickets.

These problems are certainly all solvable within Scrum, but we wanted to look a little farther afield for a structure that fit our culture better. We identified a number of goals for our new process:

Focus on people instead of process. It's tempting to solve every organizational challenge by adding new policies and procedures -- but we wanted to focus more on empowering people to solve problems. The process should put the right people in the room, make it clear who's responsible for what, and then get out of the way.
Choose velocity over predictability. We were spending a huge amount of time predicting when something would ship, despite the fact that most of our projects had no external date commitments. By letting go of the need to know exactly when something would be done, we could focus our energy instead on moving faster.
Eliminate dependencies. The biggest thing limiting our velocity was cross-team dependencies. We wanted a process where a small team could take a business problem and solve it, without asking for permission or having to coordinate across other groups.

Enter Project Based Development

We based our new process on Yammer's. Kris Gale gave a great conference talk about leveraging small cross-functional teams to solve business problems. The process immediately appealed to me, because it so naturally maps to how most of the engineers I know wish they could work. Give me a business problem, give me a team with all the skills we need to solve it, and then get out of the way and let us solve it.

The process works like this:

All our work is broken down into projects. A project has 2-6 people, lasts 1-8 weeks, is self-contained, and delivers clear business value. A project is staffed cross-functionally with all the resources it needs to finish the work on its own with no external dependencies. Larger initiatives are broken down by product managers and architects into smaller projects.
Engineers work on a single project at a time to let people focus and avoid context switching. Product managers, designers and architects will typically work on multiple projects at a time.
Every project has a lead who is responsible for overall project execution, a product manager who defines the business value and success criteria, and an architect who makes sure the technical solution fits into our broader architecture. The lead role varies per project, so a lead is a temporary assignment, not a job title.
The entire org gets together every two weeks to introduce new projects and demo any that finished. Otherwise, there is minimal ceremony; project teams are left on their own to execute the work however they see fit.
A shared Google Doc lists every projects along with its staffing and end date, so everyone has full transparency into what's coming. Managers meet once a week to figure out what projects are next and staff them based on people's skills and interests.

Maintenance

While this works great for new features, an obvious question was who maintains and iterates on those features. We again followed Yammer's lead: when an engineer isn't staffed on a project, they're on a special team called Small Wins [this was originally called Maintenance, but who wants to work on the Maintenance Team??].

The Small Wins team works on anything smaller than a project. This includes any urgent bug fixes, smaller customer requests, technical debt, or smaller features. I find this is a nice break after a long project; you get to knock off a bunch of quick tickets and make some customers happy.

This was actually the most contentious point when we we first introduced the process. People worried that they'd suddenly be on the hook to support applications they didn't know, or that project teams would leave buggy code that Small Wins would then have to clean up.

In reality, it's worked out well. Small Wins gives people a natural opportunity to cross-train; when you're forced to fix a bug in someone else's code base, it gives you a natural way to learn that code. As more people learn more of the platform, people can work on more types of projects, and bring learnings and best practices from one codebase to another. And when you know someone else will be on the hook to support your code, you're much more likely to write good tests and documentation.

Quarterly Theming

When we originally rolled the process out, we were trying to eliminate our quarterly planning process altogether, and instead maintain a continuously prioritized backlog of projects. However, we found that we lost something important in that change: with no quarterly planning, there was no obvious time to step back as a team and think strategically about whether we were building the right things.

We decided to bring back a quarterly process, but with a different goal. Instead of wasting weeks trying to plan out exactly what work we'd get done in the quarter, we'd focus on getting everyone aligned on what business problems we wanted to solve.

Once a quarter, we now do what we call Quarterly Theming. The goal is to produce a roughly ordered list of business problems (Themes) that are most important to the business to address. We don't worry about how we'll solve them or how much progress we'll make against them; we just try to articulate what's most important. Product managers and architects then use those themes throughout the quarter to create and prioritize projects.

Circles

As part of the new process, a key goal was to decentralize decision making and empower more people. To get there, we borrowed a few concepts from Holacracy. [Side note: I'm a big Holacracy fan (and a Certified Practitioner!) -- but to be clear, we aren't practicing anything remotely like Holacracy at Say. We've just stolen a few terms and bastardized some of their concepts.]

We rolled out two kinds of "Circles": Culture Circles and Code Circles. Each Circle meets once or twice a month and has a Lead responsible for running the group.

The Code Circles bring together all the people who work on a given codebase to talk about architecture and technical direction. With engineers working primarily on cross-functional business initiatives, this gives people a place to come together around a technology area and discuss purely technical topics, do design reviews, and suggest technical projects.

Our four Culture Circles focus on the culture and effectiveness of our organization, taking responsibilities that traditionally belong to management and opening them up to more people.

The How We Work Circle owns our development process, taking feedback on what's working and what isn't and iterating to improve it.
The Recruiting Circle is responsible for how we hire, how we source and interview, and defining what we're looking for in the team.
The Professional Development Circle focuses on how we can develop our skills and our careers through things like brown bags, conferences, speakers, and cross-training.
And finally, the Social Circle looks for ways to bring people together through non-work activities like happy hours, sports clubs, book groups, offsites and hackathons.

What I've Learned

This experiment in moving to our own development methodology has been incredibly rewarding. I've been continuously amazed by what happens when you give people a problem and let them solve it. Whether it's a project team finding a great product solution, or someone unexpected stepping up and killing it leading a Circle, when you give people ownership and space, they will always impress.

I've also learned not to stress too much about process. Find something that works for you, course correct when necessary, and don't stress the small stuff. Give people as much context as possible, empower them to make decisions, and get out of their way; the rest is just details.