Championship in practice (at Stack Overflow)
This is a follow-on to my introductory post on championship, please give that a read for background.
So! Championship sounds nice, but how to put it into practice? Here’s how we did it on the Talent team at Stack Overflow.
This system developed as a collaboration between Product Managers Puneet Mulchandani & Des Darilek, and myself as Engineering Manager.
Set up for crisp decisions
The Talent team keeps two main Trello boards: “backstage” and “the sprint board” (aka front stage).
The sprint board is “the reality board”. It strictly contains items that are being actively worked, to be delivered this sprint.
It should be accurate enough we are comfortable sharing it publicly.
Pre-sprint: pitching and socialization
Product managers organize and queue ideas that might be delivered in the upcoming sprint. Deliverables need not be implemented features; they can just as easily be specs, designs, or research.
Pitching and socialization are encouraged! Actually not just encouraged, but obligatory: managers champion projects in the hope that others will join. (Pro tip: projects that are clear in scope are more likely to get a champion.)
This phase happens asynchronously, usually in the form of a Google Docs with open comments.
The sprint
The team gathers synchronously (usually a Hangout) to champion projects for the next sprint. Candidate projects appear in a “Proposed” column in Trello, on the reality board.
As preamble, each contributor reviews their current projects, to ensure that the board reflects reality. Then, we go through each proposed project, and ask who, if anyone, would like to champion it.
If we get one, great! Move the card to the right. In the absence of a clear champion, a proposed project returns to backstage.
Hewing to reality
Choosing to champion a project is not solely about intentions: it necessarily includes making realistic promises.
While on one hand we are recruiting champions for new projects, on the other hand we emphasize the ability to deliver. If a contributor is overbooked, or a proposal is underspecified, then it’s not ready for a champion. Saying no is often the right thing.
Right-sized sprints
Our team’s sprints are bi-monthly (approximately two weeks). We found that we can reasonably predict outcomes on that time scale.
Deferred projects don’t fall into a hole: if a project isn’t championed on this sprint, we can re-propose it for the next one, which will arrive soon enough. This allows us to say no without being discouraged.
How it turned out
It’s easy to assume that developers will only choose “sexy”, technically interesting projects. This rarely happened in my observation.
Culture has a lot to do with it. A surprising number of developers will sign up for unglamorous work, if they believe in the outcome. From PM Puneet:
“Team culture plays a huge role here, I think.
In order for this to work smoothly, the team needs to be bought in on a common high-level goal or objective.
Without a common end-goal, it’s hard to argue about what projects should be chosen. In our case at Stack when we put this into effect, we had an explicit push towards refocusing on the user, empathizing with them, and addressing their pain points however small they may be.
And, of course, a team that actually cares helps too :)”
This gets back to managers: when we do a good job championing projects, individual contributors will do the same.