"Owning the launch too" and "The 2-week plan"

"Owning the launch too" and "The 2-week plan" 37signals May 22

28 comments Latest by JF

A couple of new internal rules at 37signals that we thought we’d share:

Owning the launch too
Lately we’ve had a couple of features, fixes, and tweak lately that have been sitting idly done waiting either for deployment or for input from someone else like design.

So we’re establishing a ground rule: If you’re working on the feature, you own the feature. You’re responsible for involving everyone that needs involving. And do it forcefully.

If you’re a developer and you need input from design, grab a designer and tell them that the feature won’t launch until they deliver X. That’ll get ‘em fired up to get it done!

If you need to have the feature deployed and you’re not confident doing it on your own, book a specific time with Mark to make it happen, so you both can be around.

It feels great to be done with something on the programming side and then feeling free to move on to the next thing. We all do that at times. But it’s not really real until our users are able to enjoy it.

The 2-week plan
We’re also worried that we’re keeping our heads down too long on projects. We’re not stopping, looking around, and deciding where to go next early enough. Things are lingering too long without reality checks.

So here’s the rule moving forward: If someone is working on something for two weeks, stop. Then post a message to the Basecamp project. Use one of three choices (you can also pitch multiple options):

1. Provide an ETA on completing the project and create corresponding milestones in BC for the phases/completion.
2. If you don’t see an end in sight, ask for judo help to get it done sooner. Always consider that there’s a significantly simpler solution than the one you are working on.
3. Suggest abandoning/shelving the project.

The goal here is to not let weeks and weeks and weeks pass before deciding to either judo something or kill it. We’re not using our time efficiently if we’re tangled up and not asking for help. There’s no pride in pushing through something without being able to see the end.

Looking for a job? Got a position to fill? Check out the Job Board.

Over 1 million people use 37signals' simple web-based software to collaborate on projects, track contacts, and organize their business with an intranet.

28 comments so far

software_developer 22 May 08

thank you for sharing new thoughts .. we always glad to find some new ideas from you.

also I want to note that your book is very good and ideas behind it are splendid ..

qwerty 22 May 08

Is the cool wearing off? Posts about 37s’ culture used to stress that there are no rules, everybody was encourage to think for themselves and to act accordingly. (Example: signing up for conferences and buying books.) This sounds different and at least for me it feels like 37s is moving a little close to the culture of more regular companies that acted as counter examples when emphasizing the “less is more” mantra and Getting Real. I actually believe such rules are useful but you quickly might be less special than you used to be or, at least, sounded.

Morgan Aldridge 22 May 08

Having recently emerged from an extremely late, and thus over budget, project I greatly appreciate these “rules”. I’ll definitely be suggesting that we adopt them as well.

Regarding qwerty’s comments: these sound like simple guidelines to encourage people ask for help and let others know what’s going on, not rules that are holding people back from, “think[ing] for themselves and act[ing] accordingly.”

sunchin 22 May 08

qwerty,

that is silly.

this is completely in line with an agile or “getting real” methodology. it’s all about making sure nobody is wasting their time.

good post.

leethal 22 May 08

Who is the author ‘37signals’? Stuff written by.. all of you peeps? Weird.

David 22 May 08

“So we’re establishing a ground rule: If you’re working on the feature, you own the feature. You’re responsible for involving everyone that needs involving.”

What a novel idea. Next thing you know you’ll think of something realluy ground breaking like to-do lists.

Nicholas Henry 22 May 08

[sunchin] I agree, the rules described are all about “getting real”. [qwerty] They not detailed procedures mean to hinder, they are guiding principles that keep you on the right track, moving forward. They keep you sane.

Great stuff.

Don Schenck 22 May 08

So 37 Signals has a built-in structure whereby you help people to not get lost in the slog.

I like.

ML 22 May 08

Who is the author ‘37signals’?

Typically, posts that show up authored by “37signals” include content from multiple authors.

Ben 22 May 08

Sounds like 37signals is having some growing pains. Its gets harder and harder to be lightweight and agile with all those projects and employees.

JF 22 May 08

Ben: We’re just open to change. If something isn’t working, we try something new. If that doesn’t work we try something else. We’re always looking for new and better ways to work together. We’re far from perfect — there’s lots of room for improvement.

None of the ideas we posted on have anything to do with size. If we had three people we could still be working too long without looking up. If we had 5 people we could still be almost finishing things without taking the initiative to prep it for launch.

We’ve dabbled in a variety of work methods over the years and will continue to refine through experience.

Peter Urban 22 May 08

I think it’s great that you guys share what works for you and what doesn’t even if the cult that comes with your success sometimes bites you in the back with sarcastic comments. Keep it up, there are plenty of people that see it for what it is.

Robin Chauhan 22 May 08

Can someone enlighten me as to what “judo” means in this context?

Robin: We use “Judo” when we mean “How can we chop this big problem down into a bunch of small simple problems.” The Judo solution is the simplest solution we can come up with that solves enough of the problem to move forward.

Ahhhh!

I just got owned by JF.

Richard 22 May 08

We have met the unending time line challenge by implementing a 5 week (actually 4 week read on) cycle. This works for us on an existing product we are adding to. It may not work in a pure R&D phase.

Week 1 – Planning low hanging fruit work. Plan out the two week dev cycle, support any new production issues from previous release and pick any low hanging fruit opportunities. NOTE : All planned work must fit into the two week cycle otherwise it is too big.

Week 2&3 – Develop

Week 4 – QA and Debug.

Week 5 – Beta with select customers and production launch after successful beta. This week overlaps with week one.

By having week five overlap with week one we can actually extend a week for contingencies. Our whole company has subscribed to this management, sales, support, training, etc. Even our customers are now starting to talk in this form and are comfortable knowing how things progress. This also allows us to publish the new features that will be release at the end of the dev cycle with everyone having confidence they will be there.

Steffen Hiller 22 May 08

Nice Post. I think that “owning a feature” is an important rule. How long does someone actually own a feature in your team? Forever? I would think forever would be a good “rule”. That also would increase quality of that feature, because the one working on it will have to face user feedback and possible bug fixes and changes himself, so he better makes it right now, instead of coding quick but dirty solution. On the other hand, I’m not sure if “quality of code” is a problem in your team, since you have the privilege (which you earned yourself, of course) to have very good people. But I guess even the best people can get tempted to finish something fast with 90% instead of 100% of their effort if they don’t own the feature and therefore are not fully responsible for it’s quality.

Pavel Pichardo 22 May 08

We have implemented that first rule you post, and it works great. I think that the best way to get things done, you need someone to worry for it and press a little the other involved in the project.

tyler 22 May 08

“If you’re working on the feature, you own the feature. You’re responsible for involving everyone that needs involving. And do it forcefully.”

Amazon basically used the same idea and I think it’s a good rule. If you are the owner then you own it all: building, deploying, and operating. That said, if every time you want to get something done you have an uphill fight (whether that be technology or people) then it can get quite demoralizing.

Wilfried 22 May 08

If you’re a developer and you need input from design, grab a designer and tell them that the feature won’t launch until they deliver X. That’ll get ‘em fired up to get it done!
A good idea, it works great with many designers who need to be worried to finish projects; but I think too that some of them doesn’t want to be worried…

J Lane 22 May 08

Great post.

I love posts like this because they can apply everywhere, they’re as much true for a team as they are for an individual. Owning the launch would have helped me immensely in a past life—now as an “army of one”, I have no choice but to own the launch.

I love the 2 week concept though. I think that you had written previously that things that take longer than 2 weeks are probably too complicated and should be further broken down. Good call here.

Matt Radel 22 May 08

I agree that the 2 week concept is swell. Very refreshing…long projects can be a friggin’ drain at times.

eric 22 May 08

eh, yes and no. I worked at shop as the sole designer/UI guy and the 6 developers all came to me on Fridays (push day) to make their stuff ‘pretty’.

Usually I tried to get ahead of the curve by providing mockups/templates before the guys started coding (isnt’ that what 37 does?)

Brian Scates 22 May 08

So you’ve basically adopted SCRUM without the daily meetings?

Clay Johnson 22 May 08

There are a lot of new names in that Who are 37signals box. Who are these folks? Congratulations regardless!

Jeff 22 May 08

Sounds like a couple of policies, to me.

Clay, that folks has been there a while, they add them one at a time,

but,

Jason, I would love to see a timeline who started when, and what they actually do, (and how I’d fit in your team). ;-)

Yup, that’s how we do it. But there are always tweaks and adjustments required prior to launch. Usually a string of little things. That’s why the designer comes back in near the end.

This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Visit the Product Blog for more information on our products.

Jobs: