

2010: The year of the products + a new way of working - mrduncan
http://37signals.com/svn/posts/2099-2010-the-year-of-the-products-a-new-way-of-working

======
Tawheed
I hate to break this to all of you, but all thats happening here is the
natural evolutionary process of a small company growing in size. I think
37Signals has shared a lot of concepts/opinions in the past that are
relatively novel and great, but it is inevitable that as they grow in size,
they're going to become what they preached against -- unless ofcourse they
stop hiring.

For every person you bring on, you're going to feel compelled to 'do more'
because surely you don't want an employee sitting idle (even if you only do
work for 37 hours in a week). And as you try to ensure no one sits idle, you
start to introduces ideas about timelines, deadlines, iterations -- all of
which have organically grown in software companies first, and then became
institutionalized.

~~~
alanthonyc
Perhaps, but I hope not.

One big difference is that they _are_ advocates of "a new way of working."
Also, they are being open about it and discussing and sharing their ideas with
the world.

If it fails, so be it. If it succeeds (or more likely, some variation of it
succeeds), then we're all the better off for it.

------
kyro
The teaming system seems interesting. But, I just finished going through their
book 'Getting Real' and a lot of what they're aiming for in the blog post
seems to go somewhat against the principles they outline in the book. In the
book, they encourage you to be conservative with feature releases and to be
moderately stiff when it comes to changing the product, yet here they're
hoping to release at least one feature every two weeks, for one team. Also,
this new system seems to depend too much on time constraints, deadlines, and
logistics, to where I can see a lot of energy being put to making sure
everything runs according to schedule, which could take away from the creative
process, let alone ensuring the product is heading in the right direction. Of
course, this is all speculation and I'm sure they have guidelines set in place
to prevent such things from happening. It all seems interesting anyway, and
I'm all for experimenting, so I wish them good luck.

~~~
run4yourlives
They're growing. This is the part I've been waiting for. :-)

A good number of small companies work the "getting real" way, if not overtly,
at least by default. As companies grow however, they start to change. One of
the most significant part of this change is the formalization of aspects of
business.

37Signals is the first company I've seen to adamantly adhere to small company
principles, not only embracing them, but expanding them into mantras and
guiding principles.

Now that they're growing it's going to be interesting to see how well they can
stick to their original ideas and how much they adapt into methods that are
more similar to what other companies do.

The one thing they have going for them is that they're not afraid to try new
things. I suppose we'll all just have to watch from a far to see how it all
turns out.

------
gcheong
Can I be on the slack team? Slacking is what I do best and as they say you
should always work with your strengths.

~~~
joshu
I'll join you.

~~~
access_denied
Yeah, as a team we can maximize our output.

------
gr366
It will be fascinating to watch how 37signals copes with its growth. If they
can cultivate a corporate culture where people don't mind switching teams
frequently, I'll be impressed. As soon as you get a multitude of personalities
interacting, unless they are very disciplined and/or fully bought into the
company vision, there will be some relationships and interactions that will be
sought out and some that will be avoided. Even small teams have personality
conflicts.

I expect the ideas behind this direction aren't being handed down by Jason and
David from on high, but rather came from employee feedback. They're probably
still small enough to test out some of these ideas without doing damage, so
I'm interested to see what comes out of it and what modifications they make
and what we can learn from this.

------
dugmartin
I tried to do this in the late 90s with a team I lead. The plan was for an A
and B team. The A team (did the theme song spring into your head?) would work
on new features and the B team would do bug fixes in existing code. The teams
would switch roles back and forth each month with the idea that the team that
just released something would be the logical bug fixers when it went into
production. The main problem with it was cross-polination -- ideally you want
the teams to mix up every iteration but that breaks the follow on bug fixing
period.

I think we made it 3 months before it collapsed due to conflicting outside
schedule pressure I couldn't control.

------
bootload
_"... Each team will stay together for two months (a “term”). When two months
are up, the teams split up and form again with different people. ..."_

This is going to hurt. Akio Morita ~
<http://en.wikipedia.org/wiki/Akio_Morita> used this method on his design
teams to build the first Camrecorder. [0] The idea behind this was to build a
better product. The teams despised him for continually breaking them up.

[0] Sony, "Betamovie Beta" <http://www.thehistoryof.net/the-history-of-
camcorders.html>

------
pie
This immediately reminds of what IBM was making noise about doing around 2000:
assigning partners and small teams, changing job focus every few months, and
forcing more employees to work in a shifting open space rather than offices. I
never heard what became of their work environment policies but I assume this
was more a PR and recruiting move than an actual shift in process.

The 37s approach sounds like a formal structure culled from bits and pieces of
Scrum and the always-unfortunately-named Extreme Programming.

------
brown9-2
For what it's worth, this new process sounds like the great parts of Scrum,
just without using the name "Scrum" and all the annoying acronyms and
terminology.

~~~
gcheong
Or the need to pay someone to anoint you as a "Certified Scrum Master".

------
jasonlbaptiste
Before things went south, this is how I had always wanted to grow Publictivity
in terms of software development. I found two devs + a designer working in
teams to make new modules/features would be a good way to get things done. Set
an overall high level vision with everyone, then let the teams build things
that made sense. I kind of saw it as a 3 month long hackathon.

------
andrewcooke
good grief. aren't these the simple software people? if this is their process
how over-designed is their code?!

~~~
blasdel
Very. Rails is extremely overdesigned internally to provide concise magic to
the programmer using it.

It happens to work, usually providing a steady stream of warm fuzzies.

~~~
vegai
Problem with such design is that when it does not work, it's very hard to
figure out why. Douglas Adams comes to mind.

