How we changed a developer team to work more productively
“You should think of your company as a product” - Jason Fried, CEO, Basecamp
A company is like a software. It has to be useful and also has some bugs. You have to maintain it, fix the bugs in it, and refactor it. It is the same as true as to a team.
I’m a software engineer and an engineering manager, too. When our team was small and we had a small number of projects, things were very simple and straightforward. However, as the team became big, things got much more complicated and we lost productivity.
To solve the bugs in the team and work more productively, we made a couple of changes on how we work. In this post, I’ll tell you the three changes we made and how our productivity increased. The key of our changes is “small” — small team, small iteration, and small project.
Small team
As of September 2018, there was only one team with six developers, and two new members joined the following month. You might not think it’s a big team, yet it was big enough for us to lose our productivity.
In one team, we had many responsibilities such as e-commerce site, shopping cart, UI and API for admin system, WordPress customization, technical support for non-developer staff, and so on. It’s like violating “Separation of Concerns” in programming world.
So, we divided the team into two teams, three developers for each. Each team has its own responsibilities. As a result, it has become clearer for developers which part of the system they have to take care of.
In addition, it reduced communication costs. Before dividing the team, we used to spend a lot of time for meetings such as daily stand up, planning and retrospective. It took a long time to listen to everyone's opinion in the meeting. On the contrary, we now spend much less time since there are only three participants in the meetings.
If you divide a team, you might wonder how you share information between teams. However, you don’t need to know everything in your company. You don’t have to broadcast every single event that happened in your team. When you need to know something in another team, just ask them.
Small iteration
In agile development, we work in one to four weeks of sprints. Previously, we used to work in two weeks of sprints, but it was hard for us to estimate the tasks that we can achieve in two weeks. We couldn’t always finish the planned tasks in the sprint. Humans are terribly bad at estimation. I cannot correctly estimate tasks for more than five days.
So, we switched to one week sprint. Every week, we plan tasks that can be done in three days. Why three days? It’s because we cannot spend all the working hours for development. We have some meetings, researches for new technologies and so on.
We break down tasks into small ones that can be done in three to four hours. It’s much easier to pick up a couple of tasks that are suitable for three days. You can feel much sense of accomplishment if you finish something every day. It’s a sign of having too big task if you say “I’m still working on this” every day.
Small project
In many companies, they work on big projects that take more than six months. Way back, we also had big projects that took a year to release. As we worked on the projects, I noticed some disadvantages of those.
- It’s impossible to estimate a large project, so it always takes much longer than expected.
- Feel less sense of progress. Feel more exhausted and bored.
- It’s hard to keep ourselves motivated for a long period of time.
- A big release has more risk of breaking something and hard to identify the root cause because of too many lines of changed code.
As we experienced a couple of big projects, we decided to make a project as small as possible. Now, we don’t have any projects that take more than three months. If we can’t finish a project in three months, we cut scope by putting off some features and work on those later. It’s definitely better to have a small bunch of releases than having a small number of big releases. While each release might be a small change, wouldn’t it be nice if you can feel a sense of success/progress/win every week?
When I was thinking about how we should change the way we work, I got inspired of the book “Getting Real” by 37signals, currently called Basecamp. And these days, I’ve been reading their new book called “It Doesn’t Have to Be Crazy at Work”. I really recommend these books if you want to work more creatively, productively and happily.
