Back in early January I posted about our new way of working in 2010. Instead of working individually in isolation as we had in the past, we’re breaking into small teams of three (two programmers, one designer). We’re keeping the teams intact for two months at a time. During those two months, the teams will work on four separate iterations, two weeks each. The goal is to drastically cut down scope, set short fixed deadlines, and focus on improving our products.
How’d it go?
Now that January and February are behind us, and March is upon us, we can reflect on the first two month term. So how’d it go?
It went incredibly well. It was the most productive two month period we’ve had in a long time. It wasn’t all perfect, and some adjustments were required, but all in all we definitely feel like we made the right call switching to this new way of working.
The results
Here’s some of what we accomplished:
- HIGHRISE: A major redesign of the “stream” in Highrise.
- HIGHRISE: Jump to a case or deal from the sidebar search.
- HIGHRISE: Merge companies to help deal with duplicates.
- HIGHRISE: Email notifications, daily digests, and vCards for your Highrise Dropboxes.
- BASECAMP: Stylized HTML email notifications for messages, comments, to-dos, files, and milestones.
- BASECAMP: Post new messages via email.
- BASECAMP: Redesigned message section with active threads highlighted.
- BASECAMP: Replies to assignment emails are posted as comments.
- CAMPFIRE: Formatted tweets in Campfire chats.
- CAMPFIRE: Image thumbnails in chat transcripts, redesigned transcript view, starring chat highlights for easy future access.
- LAUNCHPAD: Jump deep inside an app right from the Launchpad.
- 37id: New help section.
- ANSWERS: Launched 37signals Answers.
Plus a variety of bug fixes, minor updates, infrastructure improvements, and design and language tweaks.
What did we learn?
A lot. Here are some of the lessons we learned along with some of the adjustments we made along the way. We have a lot more to learn, but we think these early discoveries are going to make the next two-month term even better than the first.
Lesson: Design needs a head start
Since we believe in designing the interface first, we ultimately found it made sense for the programmers to take on a few small tasks or bug fixes on the first Monday, Tuesday, and Wednesday of an iteration while the designer was working on the UI for the first big feature of the iteration. This way no one was sitting around waiting for design to be ready before they could begin. With short two-week iterations there’s no time for anyone to sit around waiting for step one before they can start on step two.
Lesson: Deploy along the way
If something’s done, get it out now. For the first iteration we waited to launch everything together on the last Friday of the iteration. That causes unnecessary stress and problems. So instead we started deploying every time a new feature was ready, whenever that was.
Lesson: Friday deploys suck
Friday deploys suck. We wanted to maximize work time over two weeks so we typically worked on a project from the first Monday to the last Friday, and then deployed that Friday night. The problem was that any problems we missed had to be dealt with over the weekend. And that’s no good. We don’t want people working on the weekends. So we decided that final deploys should happen on the last Thursday of an iteration. This way we had a full Friday to deal with any lingering issues we missed or problems that popped up.
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. We want to throw work overboard, not our sanity or our sleep. Late nights are a sign of scope failure. Hero mode is a sign of scope failure. You can’t compartmentalize burnout. Yes, we start new iterations every two weeks, but burnout carries over. The scope hammer helps eliminate burnout.
Lesson: Pick one, two, or three up front
We also discovered that sometimes one week or three week iterations are better than two week iterations. We experimented with a three week iteration for the last iteration of the two month term. It made sense for one of the projects (to be released soon), but it definitely contributed to sloppiness and missing the deadline on another project. With more time it was easy to say “We’ll deal with that tomorrow” or “We can worry about that next week.” Turns out when you start saying that you’re often already in trouble. Without a looming deadline you can feel (you can feel the pressure two weeks a lot more than three weeks), scope creeps and things get pushed off. So we decided that next time around we’ll experiment with one week, two week, and three week iterations — but that call needs to be made up front. You can’t start with one week and turn it into two or three. A team will say “This is a one weeker” or “This is a two weeker” etc.
Here we go
The next two-month term started yesterday, March 1. We’re excited to take what we learned in the first two-month term and apply it to this next term. We’ll report back in early May.
TechSlam
on 02 Mar 10I was expecting a post on this and here it comes. I was eagerly waiting to know how things went with the company with this new way of working.
Cheerz to 37Signals Team
Chris
on 02 Mar 10Friday deploys suck – How true, we always schedule launches not to fall on Fridays. Scoping is good when done blind – each developer involved estimating blind of the others, pull the estimates together – discuss anomalies and find settle in the middle.
Greg DeVore
on 02 Mar 10We have found the same thing with Friday night deploys/big deploys. Things go so much smoother when you don’t deploy on the weekend and when you bite off little chunks at a time with small deploys.
Question though, with this new way of working, how do you feel it affects your overall “product vision”? I see products as having two types of feature enhancements:
1. Small improvements that make the product more enjoyable to use.
2. Small improvements that move the product along to a much larger goal.
What are you doing to make sure that small focussed iterations don’t actually move the product in a direction that isn’t in keeping with long term goals? Or is that not an issue?
Chris
on 02 Mar 10estimation of scope – done blind
JF
on 02 Mar 10What are you doing to make sure that small focussed iterations don’t actually move the product in a direction that isn’t in keeping with long term goals? Or is that not an issue?
By keeping them short and focused we’re actually sticking closer to the vision. Longer projects end up taking on more scope and that’s where you can lose sight of the original vision.
cooljaz124
on 02 Mar 10Love the point by point explanation. Hope we will practise the same at our office as well.
Raymond Brigleb
on 02 Mar 10Very interesting, Jason. Thanks for sharing your insights about this experiment.
David
on 02 Mar 10This is why I keep showing up and buying the t-shirts and action figures. Amen, amen.
Matt Henderson
on 02 Mar 10@JF, just curious, did you compile the list of what got accomplished from Basecamp milestones, or do you track accomplishments separately?
JF
on 02 Mar 10Matt: I compiled this particular list by looking at the posts for Jan and Feb on our Product Blog. I just wanted to report on the big picture items which we post on the blog.
Philippe Creux
on 02 Mar 10You’re experimenting some Agile methods: work as part as a team, scope work in 1-3 weeks iteration and do continuous deployment. I’m happy it works fine for you. :)
Brian
on 02 Mar 10Do you guys have a running product backlog of features that you can choose from? If you don’t, have you considered having one to help choosing features for an iteration?
JF
on 02 Mar 10Brian: We have a short list of some of the things we want to do, but we don’t maintain a global mega list. Long lists just collect dust.
DL Redden
on 02 Mar 10Thanks for the review. I find it interesting to note your reference to the looming deadline. I noticed the correlation between deadlines and scope with our most recent project but failed to recognize why we were being so much more productive until I read this.
It’s simply astonishing how forcing a smaller scope and a tighter time frame can not only result in getting more done but it also requires less time to do. We found ourselves actually having more free time to spend with our families, our business is still a second job for us, but we were knocking out milestones left and right.
Matt Henderson
on 02 Mar 10@JF, just looking at what you’ve done in two months, it occurs to me that Basecamp today is so more than it was when you first launched it. All the little changes you’ve made haven’t felt like “feature creep” to me, but I guess when you step back, one realizes the product has evolved a lot.
Again, just out of curiosity, as time goes along, and as a software product like Basecamp becomes increasingly complex, do you find yourself increasingly concerned about further enhancing it? Is that reconcilable with your position against feature-creep and simplicity? Could a day come when you’d say, “That’s it. No more.”
Anonymous Coward
on 02 Mar 10@Jason
Who’s responsible for bug fixes once the 2 weeks are over?
Andrew Wicklander
on 02 Mar 10This is such a great post, and highlights exactly why strict interpretations of SCRUM can be problematic. One might even call this, dare I say, a little tiny waterfall.
One question: did you find you were spending any time laying out specific dependencies other than the design – and did you have to target any specific dates if so?
JF
on 02 Mar 10Re: bug fixes. It depends on the severity of it, but we have a programmer dedicated to support for the two-month term that is focused on bug fixes and other issues that pop up. The support programmer changes every two months just like the teams change every two months.
NateG
on 02 Mar 10Excellent write up. One thought: deploy on Monday after an iteration. This creates a consistent deployment schedule, reduces the chances of weekend work and gives devs something to do while the design is completed for the next iteration.
Anonymous Coward
on 02 Mar 10@Jason
Is there any internal things that only particular people will ever touch?
For example, your internal QueenBeen/payment system. Can anyone work on QueenBee or only a select few given if something major goes wrong with it – it could have a devastating financial impact on the business.
Anonymous Coward
on 02 Mar 10@Jason
As a follow-up, does the Two Month project only apply to customer facing products or also internal backend systems as well?
David
on 02 Mar 10A while back, you mentioned having 4-day work weeks. Is that now gone? I’d love to hear why.
Fred
on 02 Mar 10No more 4 day weeks?
Fred
on 02 Mar 10^beaten by second! bah.
JF
on 02 Mar 10One thought: deploy on Monday after an iteration. This creates a consistent deployment schedule, reduces the chances of weekend work and gives devs something to do while the design is completed for the next iteration.
That doesn’t work for us, b/c there will enviably be some problems and we don’t want to start the next iteration by dealing with problems from the previous iteration.
Deploying last on a Thursday gives us a full Friday of the iteration to deal with any issues that pop up. This way we can start as fresh as possible on the next iteration the following week.
JF
on 02 Mar 10A while back, you mentioned having 4-day work weeks. Is that now gone? I’d love to hear why.
We’re doing 4-day in the summer. That’s the plan for now. We found that they weren’t as valuable in the winter.
JF
on 02 Mar 10Is there any internal things that only particular people will ever touch? For example, your internal QueenBeen/payment system. Can anyone work on QueenBee or only a select few given if something major goes wrong with it – it could have a devastating financial impact on the business.
We don’t like these specialities which is one reason why we mix up the teams every two months. People can spread their experience around.
NateG
on 02 Mar 10Good point. It’s a pretty good weekend indeed if people are using the cool thing you made last week and you are excited about the cool thing to be made next week.
Ben Bodien
on 02 Mar 10Are you guys still operating a 4 day working week? Just curious as you mention working through bugs post release on Fridays.
John W. Long
on 02 Mar 10Great stuff Jason! Looking forward to the recap and lessons learned from the next two months.
Pat
on 02 Mar 10Why not rearrange your iterations? Starting iterations on a Wednesday would give you Monday to launch, Tuesday to deal with issues, and then your 3 days (Wed, Thurs, Fri) for your designers to design and your developers to bug fix at the beginning of your iterations.
Just a thought. Love hearing what you’ve learned from your experience!
Fredde
on 02 Mar 10Never change a running system in particular on a Friday unless you want to be in trouble. Old sysadmin wisdom. Have been working with this in mind since the 90s. Very effective when dealing with upper management and their unrealistic picture of what should be done.
Rich
on 02 Mar 10It was the most productive two month period we’ve had in a long time.
How are you measuring productivity?
John P
on 02 Mar 10You may be interested in using Pivotal Tracker (www.pivotaltracker.com) to keep track of short iterations. It’s a pretty valuable tool for tracking user stories, chores, bugs and releases. It’s very much in the spirit of Agile/XP, which appears to be the direction you’re headed in. Disclaimer: I’m an employee of Pivotal Labs, which produces Pivotal Tracker.
It’s free to sign up and use; hope you enjoy it – we’d love to see a post with feedback on how you find it.
Berserk
on 02 Mar 10@Pat: Exactly, and in addition you get two weekends instead of one on which to think inactively about the current development.
As others, I’m a bit surprised by the thinking of releasing on friday night, but that’s a lesson easily learned :).
Agree on the 4-day work week. An extra day of is much more valuable in summer.
Matt Henderson
on 02 Mar 10@JF, one final question: Has it been an issue at all during these two months to maintain a consistent sense of urgency, among all the team members, in hitting the objectives of the iterations? Is there any source of pressure beyond self-motivation and, maybe, peer-pressure? (Any consequences to missing the goals?)
john
on 02 Mar 10This is so interesting. At a previous gig, we experimented with 1 to 3 week iterations and team composition, and came to very similar conclusions after a lot of experimentation and self-monitoring (chiefly through comparisons of estimates and actuals): That Friday deploys such, that iteration length has to be determined up front, that scope reduction is key, that designers need a head start. The only part we couldn’t manage was frequency of deploys: We had to wait until the close of the iteration.
Great post.
Andrew
on 02 Mar 10Nice post.
Deploy when there will be the least impact on your users.
If you have an app used for business; the majority of your user base will be in your application during standard business hours. The friday deployments might suck for the developers, but not the client. Deploy on friday, and if you miss something, work the weekend before it impacts the majority of your user base.
it's me.
on 02 Mar 10I think if it really really works, you will see after a long time, like 6 months or a year. I think that as it is some new way of working, everybody is exited and motivated. Interesting to see, if this “wow-effect” and “productivity” keeps that high through time.
It is a very very interesting method, though, thanks for sharing. I love experiments with alternative working-schedules and am always curious to read about.
JF
on 02 Mar 10Andrew: We still do major deploys (ones that require database migrations and downtime) on Saturday nights so we impact the fewest number of people.
John
on 03 Mar 10I notice you mentioned deploying on Fridays. Does that mean you moved back to an official 5 day work week?
zakiwarfel
on 03 Mar 10I’m curious how you guys are handling/managing your list of things you want to tackle (e.g. backlog, excel file, writeboard). How do you determine who’s responsible and pass it on to the next person?
Chris
on 03 Mar 10I’m curious though with the rather arbitrary one week, two week, or even three week deadlines if you might actually be hurting the long term direction of the company. Your goals are focused so much on the short term how are you able to plan for the future?
Marko
on 03 Mar 10Once I coached a team just starting out with agile, they messed up their first friday release(s) as well. They also came up with the “Don’t release on Friday” rule.
Six months later they abandoned the rule again – should the need appear they were perfectly happy to deploy on Friday 5 minutes to 5.
Why?
First of all they removed the need to release on Fridays by running iterations Wednesday to Wednesday. (also suggested by Pat) So scope was clearly a reason Friday releases failed.
Second reason was confidence. Because of their new way of working (much like you describe but they also started with unit and acceptance testing and continuous integration) the teams skill levels soared. Even though they were reluctant to completely embrace the process, it boosted their confidence into something close to arrogance. :) It actually was very nice to observe.
Of course there are valid reasons not to release on a Friday, but they should be outside of development. Minimize impact on your customers is a good one as posted by Andrew. (sorry, I hate the word users, only drug dealers and software developers have users for customers) Another reason might be the absence of sufficient customer support during weekends. You want to make sure when you launch a new feature or some changes to n existing workflow it’s properly supported.
So in short, it’s kind of a balance, sometime you do release on Fridays, sometimes you don’t. The trick is to get your release right in the first place.
I’m very impressed by the lessons learned in your first two months and I’m also very appreciative that you’re flying this by yourselves. No coaches or other external observers, that means you’re confident of your own objectivity and rationale. As such it is again a demonstration of your ability to “Get Real”
Cheers, Marko
JF
on 03 Mar 10I’m curious though with the rather arbitrary one week, two week, or even three week deadlines if you might actually be hurting the long term direction of the company. Your goals are focused so much on the short term how are you able to plan for the future?
They aren’t arbitrary, they are human. Humans are good at estimating short periods of time and pretty terrible with long stretches of time.
Re: planning for the future: Get today right and you’ve got a chance at tomorrow. Guess tomorrow right, but get today wrong, and tomorrow never comes. Worry about now and later takes care of itself.
Santiago
on 03 Mar 10I’m not in the technology field but do admire the different work methodologies that developers use to get work done. In this plan, there is 1 one designer and 2 developers. What is the designer’s role in the iteration after it has been handed off to the developers? Should the designer start working on the next iteration?
JF
on 03 Mar 10Santiago: Design is never handed off at 37signals. All our work is shared. It’s constantly tweaked, adjusted, and changed.
Jordan Harper
on 04 Mar 10I’m surprised you guys fell for the Friday deployment thing in the first place! We schedule all deploys on a Wednesday as a matter of course, and on a Thursday if we absolutely have to in order to be sure that we don’t end up dealing with issues over weekends.
We’ve been operating like this for a couple of years now and it’s been a life/sanity-saver!
Rich Thornett
on 07 Mar 10Great post, Jason, thank you for sharing these details. I like what you’ve come up with.
I second the comment of Andrew Wicklander (above) about strict interpretations of Scrum being problematic / waterfall. My organization has recently adopted Scrum and I’ve been baffled by its language of “contracts” and “commitments”. I realize the idea of Scrum is to narrow estimation to smaller iterations, but even in this context we’ve found our estimations to be quite error prone.
My preference is to acknowledge our humanity and replace “contract” with “conversation” about when and where to wield the scope hammer. Though perhaps I just don’t “Get It”™.
This discussion is closed.