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.
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.
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.
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.
They are just experimenting. What they wrote in the book is what they used to build the products they currently have. If they are going to discover a better way of working, I think that's awesome, even if they are doing the opposite of what they were preaching before.
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.
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.
"... 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.
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.
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.
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.
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.