March 4, 2010 at 11:16New way of working in 37signals: two months results
- Transfer
37signals is a small, privately held web application development company based in Chicago. Among their products are collaboration tools and data management systems: Basecamp , Campfire , Highrise .
In early January, I wrote ( translation ) about the introduction of new working methods this year. We decided to unite individual developers into teams of 3 people: two programmers and a designer. The composition of teams will remain unchanged for 2 months. Each two-month module will be divided into 4 consecutive iterations, two weeks each. We set a goal to reduce the list of tasks for each iteration, strictly follow the tight deadlines and improve our product.
February ended and March came, which means that we can take stock of the first two months of work according to the new methodology. So what came of it?
The change in the working method went fine. January and February were the two most productive months in a long time. Despite the fact that not everything was smooth, and we had to make some adjustments, in general, we considered this change to be the right move.
Here are some of the tasks we managed to complete in these two months:
In addition, there were many bug fixes, small updates, improvements to the infrastructure, design and content.
We have learned a lot. Below we give some of the lessons that we had to learn in these two months. Of course, we still have to learn a lot, but already this, we hope, will allow us to go through the next module more successfully.
We believe in the need to start development with an interface, so we decided that in the first week of iteration, on Monday, Wednesday and Friday, while the designer will develop interface solutions for the main task, programmers will perform small tasks and tasks related to bug fixes. Thus, no one will have to sit around waiting for the design to be ready. In the conditions of a two-week iteration, there is simply no time to wait for someone's step to begin their own task.
Release the result of the work as soon as you have it. During the first iteration, we tried to wait until the last Friday to roll out all the updates. This led to unnecessary problems and stress. After that, we chose to proceed with deploying updates as soon as they were ready.
Rolling out updates on Friday is awful. To give the teams maximum time to complete the task, we scheduled it from Monday to Friday, and then deployed the created solution. However, this turned out to be that with the problems that were missed, I had to work on the weekend. We did not like it at all. Instead of Fridays, we started releasing solutions on Thursday: that’s how we got a full day to solve unforeseen difficulties.
In two-week iterations, goals and objectives should be precisely defined no later than by the end of the first week. Several times we had to find ourselves in a tense working environment due to errors in assessing the complexity of the tasks. We decided that in two-week iterations we will revise the list of tasks on the second Monday and next Wednesday; if necessary, we will crop the list of tasks. We are ready to give up part of the work, and not sleep or reason. Frequent "night marathons", the constant need to be heroic to complete tasks are bad signs. Depletion is not divided into iterations. Yes, a new work plan for iteration is drawn up every two weeks, but depletion goes from one to the next. Adjustment and reduction of the task list helps to cope with the "burning" in the workplace.
It was experimentally found that sometimes it makes sense to change the length of the iteration. The experiment was delivered in the last three weeks of our two-month module. The decision was reasonable for one of our upcoming projects, but it definitely added negligence and a waste of time in working on another project. An extra week dampens and makes it possible to say, “We will do this tomorrow” or “I will take care of this next week.” These two phrases already indicate that problems will arise. Without a clear understanding of the deadlines for delivering work (and a period of two weeks is felt much clearer than in three weeks), the goals are blurred, and the fulfillment of tasks is becoming a secondary concern. Next time we want to try with iterations in one, two and three weeks - but the decision on the length of the iteration must be made in advance. You can’t schedule tasks for two weeks, and then extend the iteration. Development teams will have to immediately say: “This is a weekly iteration”, “This is a two-week iteration” and so on.
A new two-month module began yesterday, the first of March. We are pleased to apply the knowledge gained since the beginning of the year to the next two months. Wait for the report in May.
In early January, I wrote ( translation ) about the introduction of new working methods this year. We decided to unite individual developers into teams of 3 people: two programmers and a designer. The composition of teams will remain unchanged for 2 months. Each two-month module will be divided into 4 consecutive iterations, two weeks each. We set a goal to reduce the list of tasks for each iteration, strictly follow the tight deadlines and improve our product.What came of it?
February ended and March came, which means that we can take stock of the first two months of work according to the new methodology. So what came of it?
The change in the working method went fine. January and February were the two most productive months in a long time. Despite the fact that not everything was smooth, and we had to make some adjustments, in general, we considered this change to be the right move.
results
Here are some of the tasks we managed to complete in these two months:
- HIGHRISE: Recycling the "flow of events" in Highrise
- HIGHRISE: Adding a direct jump from a search to a deal or use case record
- HIGHRISE: Adding Company Data Consolidation Functionality
- HIGHRISE: Email notifications, daily reviews, vCard info for dropboxes
- BASECAMP: Design update for e-mail with HTML, comments, task lists and files
- BASECAMP: Sending messages via e-mail
- BASECAMP: Redesigned talk page
- BASECAMP: Responses to task letters are added as comments
- CAMPFIRE: Formatting a Twitter Chat Message
- CAMPFIRE: Preview images in chats, change the design of chat history, add bookmarks to chats
- LAUNCHPAD: Improved navigation between projects and the main page
- 37id: New Help Section
- ANSWERS: Launched 37singnals Answers
In addition, there were many bug fixes, small updates, improvements to the infrastructure, design and content.
What have we learned?
We have learned a lot. Below we give some of the lessons that we had to learn in these two months. Of course, we still have to learn a lot, but already this, we hope, will allow us to go through the next module more successfully.
Lesson: Start with an Interface
We believe in the need to start development with an interface, so we decided that in the first week of iteration, on Monday, Wednesday and Friday, while the designer will develop interface solutions for the main task, programmers will perform small tasks and tasks related to bug fixes. Thus, no one will have to sit around waiting for the design to be ready. In the conditions of a two-week iteration, there is simply no time to wait for someone's step to begin their own task.
Lesson: Roll it out when ready
Release the result of the work as soon as you have it. During the first iteration, we tried to wait until the last Friday to roll out all the updates. This led to unnecessary problems and stress. After that, we chose to proceed with deploying updates as soon as they were ready.
Lesson: Don't Wait Friday
Rolling out updates on Friday is awful. To give the teams maximum time to complete the task, we scheduled it from Monday to Friday, and then deployed the created solution. However, this turned out to be that with the problems that were missed, I had to work on the weekend. We did not like it at all. Instead of Fridays, we started releasing solutions on Thursday: that’s how we got a full day to solve unforeseen difficulties.
Lesson: Correct tasks as early as possible
In two-week iterations, goals and objectives should be precisely defined no later than by the end of the first week. Several times we had to find ourselves in a tense working environment due to errors in assessing the complexity of the tasks. We decided that in two-week iterations we will revise the list of tasks on the second Monday and next Wednesday; if necessary, we will crop the list of tasks. We are ready to give up part of the work, and not sleep or reason. Frequent "night marathons", the constant need to be heroic to complete tasks are bad signs. Depletion is not divided into iterations. Yes, a new work plan for iteration is drawn up every two weeks, but depletion goes from one to the next. Adjustment and reduction of the task list helps to cope with the "burning" in the workplace.
Lesson: One, two, three - firmly decide from the start
It was experimentally found that sometimes it makes sense to change the length of the iteration. The experiment was delivered in the last three weeks of our two-month module. The decision was reasonable for one of our upcoming projects, but it definitely added negligence and a waste of time in working on another project. An extra week dampens and makes it possible to say, “We will do this tomorrow” or “I will take care of this next week.” These two phrases already indicate that problems will arise. Without a clear understanding of the deadlines for delivering work (and a period of two weeks is felt much clearer than in three weeks), the goals are blurred, and the fulfillment of tasks is becoming a secondary concern. Next time we want to try with iterations in one, two and three weeks - but the decision on the length of the iteration must be made in advance. You can’t schedule tasks for two weeks, and then extend the iteration. Development teams will have to immediately say: “This is a weekly iteration”, “This is a two-week iteration” and so on.
What's next?
A new two-month module began yesterday, the first of March. We are pleased to apply the knowledge gained since the beginning of the year to the next two months. Wait for the report in May.