Organizing our team

In January, I left Google to work with my friend Curtis at a startup in Ann Arbor called Ploria. My role is Chief Technology Officer, which frankly didn’t mean squat when I joined because there were only two of us working full time and leading a team of one developer doesn’t take a heck of a lot.

However, we’ve since added a few more full-time developers and now have a team of around 5 ½ working on our product. We noticed as we added more developers that miscommunication became more frequent and people no longer knew what each other were working on.

We’ve tried a number of things to fix these problems and I thought it would be useful to quickly document what each was and how it worked.

Two week sprints

Date: April 13

The first thing that we put in place was two week sprints with a kick-off meeting on Monday. A sprint is just a period of time over which you commit to finishing a set of tasks. At the kick-off meeting, we discuss how much work we think each task planned for the sprint will be and then take turns claiming work that we’d like to do.

The following Wednesday, we gather again to show off what we accomplished. We also talk about what went well during the sprint and what we can do better in future sprints.

As the CTO, my primary responsibility is to take people’s feedback about what we can do better seriously. Taking the feedback seriously - especially when it’s inconvenient to do so - encourages people to give feedback in the future, creating a virtuous cycle.

Status Hero

Date: April 16

In order to better understand what each other are doing, we added Status Hero to our Slack. Status Hero asks people at the end of each day what they accomplished and how they’re feeling.

Ultimately, we ended up ditching Status Hero in favor of frequently updating Slack statuses: more on that later.

Zenhub

Date: April 17

Soon after installing sprints, we found that using Github project boards to manage them was getting unwieldy. Github lacks first class support for Story Points. Additionally, we felt that we needed a better understanding of how much work we had left until launch.

Zenhub acts as a Github project management tool, integrating into Github through a Chrome extension that adds UI elements to it. These UI elements include “Release”, “Epic”, and “Story point” fields on each issue.

Overall, we’ve found Zenhub really helpful in organizing our work, although sometimes its burndown charts are less than useful due to scope changes for a given release or milestone.

CrushingIt

Date: May 29

Even with all of the previous tools, we found it difficult to keep track of whether we were actually hitting the goals we set for ourselves each sprint. We were certainly getting lots done each sprint, but a lot of it was “scope creep” that we added after the sprint’s start.

Additionally, we felt that Zenhub’s board was demoralizing because it buried the things that you got done and showed you only what you had left to do.

To solve this, we created “CrushingIt” bot. CrushingIt is basically a Google Sheet that’s hooked up to our Slack through Google App Script. At the start of each sprint, we add the tasks that we’ve committed to finishing and, every time that someone marks one of their tasks as done, CrushingIt announces the completion to Slack and gives an overview of what’s left.

We’ve found this has three great side-effects:

• People have a better idea of what others are working on
• It creates a public occasion to celebrate the completion of a task
• Because the task list doesn’t include scope creep tasks, we have a much better sense of when we finish the tasks we commit to each sprint

Overall, the CrushingIt bot has been a tremendous success in improving our team’s productivity.

Slack statuses

Date: June 17

Eventually, we decided that Status Hero was more burden than help and we ditched it. To fill the gap that it left, we’re trying to update our Slack statuses more often - sort of like the old AOL Instant Messenger away messages - to keep teammates up to date on what we’re working on.

So far, it’s working pretty well, although the jury’s still out as to whether people will continue to be so diligent in updating these messages. Strangely enough, I think the fun of picking an emoji for your current work is a big plus and may help this stick.

Future

We still have lots of work left to do in the future. I fully expect that what works now for 5 ½ people won’t work well for 10, 20, or 100 people.

Probably the biggest three pain points that I feel are:

• We don’t have a clear enough accounting of how much work is left until important business milestones
• We need better processes to ensure clean hand-offs between product/design and engineers
• We need a way to quickly and thoroughly give story point estimates for issues. Doing it at the sprint kick-off takes too long and there’s too much pressure to “move on to the next task”

With that being said, I’m optimistic that we can find ways to tackle these problems too!