Back in January, we began working in teams.

A team is made of three people: One designer and two programmers. A system administrator will also assist the team when necessary…

Each team will stay together for two months (a “term”). When two months are up, the teams split up and form again with different people. This way everyone gets to work with everyone else…

During the two month term, there will be four iterations. An iteration lasts for two weeks. An iteration can tackle one feature, a variety of smaller features, or part of a bigger feature that will require multiple iterations to complete.

It went well and we’ve stuck to this model while also evolving it along the way. This two-month recap offered up the results of the first term and some lessons learned. For example:

Lesson: Get out the scope hammer early and often
For two week iterations, true scope should be nailed down no later than half-way through. We found ourselves up against the wall a few times because we didn’t cut scope early enough. So we decided that on Monday of the second week we’ll review the work done during the previous week and the work remaining to complete the iteration. Since humans are notoriously bad estimators, we’ll be extra conservative with scope. We’ll bring out the hammer and beat down the scope. And then we’ll do it again on Wednesday, two days before the end of the iteration.

It’s now nine months later, so let’s check in again and see what else we’ve learned since then.

Lesson: Deploy is not the finish line
After an iteration is deployed, teams now go into a cooldown phase — something we didn’t have originally. This means team members go into support mode and deal with issues related to the deploy and any general concerns coming back from the Support team. That means fixing bugs, revising copy in the help section and/or email responses, and responding to queries at our Answers forum.

There’s no set length for this phase since you can’t plot exactly how it will play out. So we wait and see. We only assume the latest deploy is good to go once Support is in the clear for 6-12 hours. Then, and only then, is it time to move on to a new iteration.

Worth noting: It’s usually not a full court press on Support in this phase so this period also serves as a general cooldown and cleanup period. If one of the programmers is chasing an on-call issue, the other can refactor some code from the iteration that could be a general plugin. Meanwhile, the designer can help someone else explore an idea.

Lesson: Get away from calendar mode
We originally thought it best to have teams work strictly in two week iterations. But we’ve realized mapping iterations to calendar days causes problems. If you go from this Monday (the 1st) to that Monday (the 14th), you ignore vacations, holidays, summer schedules with 4-day workweeks, etc.

So we now measure iterations in number of working days. We’ll estimate how long it will take a team to finish a unit of work. If it’s seven working days and it’s during the summer, that means we’ll work on it Monday-Thursday (4 days) and Monday-Wednesday (3 days). We’ll then deploy on Wednesday night.

If something pops up that distracts the team for a day — say a major emergency or the need to help some other team out — everything just shifts forward a day. The deploy that was scheduled on Wednesday moves to Thursday. This means that iterations can end on any day of the week and start on any day of the week.

We noticed a similar issue with the length of team terms. It can be hard for a team to gel if it’s two-month term is during heavy vacation times (say, August or December). We’re now trying three-month terms to give teams more time to work together.

Lesson: Track your iterations
It’s important to stop and take a look back at how the time was spent. A term time card for a two-month term might look something like this:

Iteration 1: Estimated 7 days, actual days 7, quiet period 2 days
Iteration 2: Estimated 5 days, actual days 6, quiet period 1 days
Iteration 3: Estimated 10 days, actual days 9, quiet period 3 days
Iteration 4: Estimated 4 days, actual days 5, quiet period 3 days

When we look back at this time card, we see that Iteration 4 had the most problems. It was off a day and it had the longest quiet period relative to its duration. At that point, we know to dive in for closer review and see what caused issues with that iteration.

Lesson: Have a project “scribe”
At our last meetup, one of our Sys Admins expressed feeling out of the loop with the teams. Of course, we’re now at 20 people so no matter how we try, it’s going to be harder to keep the same intimate vibe we had when we were half that size. But we are taking steps to keep that tight-team feel whenever we can.

For one thing, we plan on meeting in person more often. The new office has helped spur more face-to-face meetings and trips to HQ for out-of-towners.

Also, we’ve added a role for project “scribe.” There’s one on each team and that person’s responsibility is to keep everyone else informed of what’s happening. The scribe posts a summary at the beginning and end of each iteration explaining what’s being tackled, what we got done, what issues arose, what delays occurred, etc. When everyone knows what’s going on with everyone else, the company feels more connected.

move gamma
In this post, Sam takes on the role of scribe and describes not only the motivation for the feature but also the design considerations and what’s not in scope.

Lesson: Put together Support documentation ahead of launch
With teams racing to deploy, Support docs related to a new feature can easily wind up an afterthought. But launching without Help content can create major headaches for Support and leave customers scratching their heads.

So we now have a “final stages” phase where the team shares any necessary info that will be helpful for email responses to customers, the Help section, Answers, and the Product Blog. The more this stuff is ready to go, the smoother we can handle the deploy and its aftermath.

faq
Scribe summary gets turned into a FAQ page at the Help section.

Lesson: Let people work on what they want to work on
Finding the right balance between mixing up teams/projects and letting people work on what they want to work on is a delicate balance. Originally, we tried to ensure everyone got to work with everyone else while also alternating people between the Support, Slack, and Iteration teams.

As for what to work on, the original idea was that Jason and David would pitch ideas and the team would pitch ideas and together we’d come up with a concensus of what to work on. It’s happened where Jason or David propose something, but the team already had another idea that they felt passionate about and they did it. And that’s great.

But there are also certain projects, like a big infrastructure project, that are important enough to the business that we need to get them done — even if doesn’t originate as an idea from the team itself. That’s reasonable too.

Despite the efforts to be inclusive, the old structure left some people feeling like the decision-making was left in the hands of just a few. They worried about feeling more like consultants or outside “the core” of decision making.

So that led to our new Iterations app. It’s a teamwork app that we built and use internally where everyone can post ideas, share them, have a permalink, leave comments, and let rough ideas ripen.


Jeremy suggests a project and gets +1s from others. This item has since been completed and deployed.

We’ll post more on this separately.

Lesson: Allow for brainstorming upfront
When you’re iterating fast, it’s tempting to go into 100% dive-in mode right away. But that comes at a price. We’ve realized there’s a need to dedicate more time to examing the problem space before getting started. It might take an extra day or two, but if it prevents a rush down the wrong path then it’s worth it.

We also realized that we handled this brainstorming phase better during our in-person meetup. We got to look at a UI, write things on a chalkboard, hash out ideas, etc. When it’s just a phone call, you have more illusion of agreement and then hang up.

So we’re trying to replicate this “gather round the document” mode at the beginning of each iteration. We’re still experimenting with the best way to do this. (Should we use SubEthaEdit for sharing docs? Screen share with WebEx? Seek other ways to reproduce the brainstorming environment we have when we’re all in the same office?)

Lesson: Don’t forget about bugs
Bugs were getting short shrift in the old setup. The Slack team, which should be tackling bugs, wound up doing product development instead. We’re putting a moratorium on giving Slack anything that isn’t working on bugs.

Lesson: Keep the conversation going
Even when we don’t have a meetup, we want to keep opinions out in the open. A lot of the issues discussed in this post emerged spontaneously during Campfire chats or project calls. And we’re thankful they did. Even if we’re meeting up soon, we encourage people to not “save up” complaints/issues for later. Gripes don’t marinate well. Just because we’re meeting in the near future doesn’t mean we can’t try things out right now.