New method of working in 37signals: two months results
37signals is a small privately held Chicago based company specializing in web application development. Their products include collaboration tools and data management systems: Basecamp , Campfire , Highrise .
In early January, I wrote ( translation ) about the introduction of new methods of work this year. We decided to unite individual developers into teams of 3 people: two programmers and a designer. The composition of the 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 achieve a reduction in the list of tasks for each iteration, strict adherence to tight deadlines and improvement of our product.
')
February is over and March is over, which means we can sum up the first two months of work using a new methodology. So what came of it?
Changing the way we worked was great. 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 a good move.
Here are some tasks that we managed to accomplish in these two months:
In addition, there were a lot of bug fixes, small updates, improvements in infrastructure, design and content.
We learned a lot. Below we give some lessons from those that we had to learn in these two months. Of course, we will have to learn a lot more, but already, we hope, this will allow the next module to pass even more successfully.
We believe in the need to start development from the interface, so we decided that in the first week of the iteration, on Monday, Wednesday and Friday, while the designer will be engaged in the development of interface solutions for the main task, programmers will perform small tasks and tasks related to fix bugs. Thus, no one will have to sit in anticipation of design readiness. In the conditions of a two-week iteration, there is simply no time to wait for someone's step to start their own task.
Release the result of the work as soon as you have it. During the first iteration, we tried to wait for the last Friday to roll out all the updates. This led to unnecessary problems and stress. After that, we chose to proceed to deploying updates directly as they are ready.
Rolling out updates on Friday is terrible. To give the teams maximum time to complete the task, we painted it from Monday to Friday, and then deployed the created solution. However, it turned out that with the problems that were missed, we had to work on weekends. We didn’t like it at all. Instead of Fridays, we began to issue solutions on Thursday: this is how we got a full working day to solve unforeseen difficulties.
In two-week iterations, goals and objectives should be precisely defined no later than 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 review the task list on the second Monday and the next Wednesday; if necessary, we will trim the task list. We are ready to sacrifice part of the work, not a dream or a mind. Frequent "night marathons", the constant need to make a hero to perform tasks are bad signs. Depletion is not divided into iterations. Yes, a new work plan for the iteration is drawn up every two weeks, but exhaustion moves 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 performed in the last three weeks of our two-month module. The decision was reasonable for one of our projects being prepared for release, but definitely added carelessness and time wastage in working on another project. An additional week reassures 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 the work (and a period of two weeks can be felt much more clearly than in three weeks) the goals are blurred, the fulfillment of tasks goes by the wayside. Next time we want to try with iterations of one, two and three weeks - but the decision on the length of the iteration must be made in advance. You cannot schedule tasks for two weeks and then extend the iteration. Development teams will immediately have to say: “This is a weekly iteration,” “This is a two-week iteration,” and so on.
The new two-month module began yesterday, the first of March. We are pleased to apply the knowledge gained from 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 methods of work this year. We decided to unite individual developers into teams of 3 people: two programmers and a designer. The composition of the 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 achieve a reduction in the list of tasks for each iteration, strict adherence to tight deadlines and improvement of our product.What came of it?
')
February is over and March is over, which means we can sum up the first two months of work using a new methodology. So what came of it?
Changing the way we worked was great. 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 a good move.
results
Here are some tasks that we managed to accomplish in these two months:
- HIGHRISE: Recycling "event flow" into Highrise
- HIGHRISE: Adding a direct transition from search to a transaction or use case record
- HIGHRISE: Adding company data aggregation functionality
- HIGHRISE: Email notifications, daily reviews, vCard information for dropboxes
- BASECAMP: Design update for e-mail with HTML, comments, task lists and files
- BASECAMP: Sending messages via e-mail
- BASECAMP: Redesigned discussion page design
- BASECAMP: Answers to task emails are added as comments.
- CAMPFIRE: Formatting a message from Twitter in chat rooms
- CAMPFIRE: Preview images in chat rooms, change chat history design, add bookmarks in chat rooms.
- LAUNCHPAD: Improved navigation between projects and home page
- 37id: New Help Section
- ANSWERS: Launched 37singnals Answers
In addition, there were a lot of bug fixes, small updates, improvements in infrastructure, design and content.
What have we learned?
We learned a lot. Below we give some lessons from those that we had to learn in these two months. Of course, we will have to learn a lot more, but already, we hope, this will allow the next module to pass even more successfully.
Lesson: Start from the interface
We believe in the need to start development from the interface, so we decided that in the first week of the iteration, on Monday, Wednesday and Friday, while the designer will be engaged in the development of interface solutions for the main task, programmers will perform small tasks and tasks related to fix bugs. Thus, no one will have to sit in anticipation of design readiness. In the conditions of a two-week iteration, there is simply no time to wait for someone's step to start their own task.
Lesson: Roll out done as soon as you are ready.
Release the result of the work as soon as you have it. During the first iteration, we tried to wait for the last Friday to roll out all the updates. This led to unnecessary problems and stress. After that, we chose to proceed to deploying updates directly as they are ready.
Lesson: Don't wait for Friday
Rolling out updates on Friday is terrible. To give the teams maximum time to complete the task, we painted it from Monday to Friday, and then deployed the created solution. However, it turned out that with the problems that were missed, we had to work on weekends. We didn’t like it at all. Instead of Fridays, we began to issue solutions on Thursday: this is how we got a full working 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 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 review the task list on the second Monday and the next Wednesday; if necessary, we will trim the task list. We are ready to sacrifice part of the work, not a dream or a mind. Frequent "night marathons", the constant need to make a hero to perform tasks are bad signs. Depletion is not divided into iterations. Yes, a new work plan for the iteration is drawn up every two weeks, but exhaustion moves 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 performed in the last three weeks of our two-month module. The decision was reasonable for one of our projects being prepared for release, but definitely added carelessness and time wastage in working on another project. An additional week reassures 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 the work (and a period of two weeks can be felt much more clearly than in three weeks) the goals are blurred, the fulfillment of tasks goes by the wayside. Next time we want to try with iterations of one, two and three weeks - but the decision on the length of the iteration must be made in advance. You cannot schedule tasks for two weeks and then extend the iteration. Development teams will immediately have to say: “This is a weekly iteration,” “This is a two-week iteration,” and so on.
What's next?
The new two-month module began yesterday, the first of March. We are pleased to apply the knowledge gained from the beginning of the year to the next two months. Wait for the report in May.
Source: https://habr.com/ru/post/86286/
All Articles