[Updated with other links to Basecamp-related articles at the end.]
I attended the Building of Basecamp workshop in Seattle (just up the street from my house) a couple of months ago, and I’m finally getting around to commenting on it.
I found the workshop to be valuable experience. All of what they said was thought-provoking, and some of the methods and techniques discussed I put into use immediately. But, anyone going to workshops like this needs to know that no method or system is a magic bullet. You’re not going to be able to do a “copy ‘n paste” from what you’ve heard into your organization. Most of the folks at the workshop, I’d guess, weren’t coming from a similar situation as the 37Signals team (building a product in a small firm), so not everything will fit cleanly. Indeed, I’ll point out some of the ill-fitting pieces later. But, you should be able to apply some of the methods you’ve learned in specific situations.
By way of background, the 37Signals team spent the day talking about the principles and practices they used in developing and running the Basecamp project management web application. In short, a small team (3 people) created a very nice web application that has turned out to be very popular, and quite useful, too.
I’ll start with the principles. They discussed their “mantras” – I think I prefer the term “shared values” (even though that makes me sound like a management dweeb). These were phrases or concepts that the team used to guide their decision-making throughout development. The two most important ones were “Less Software” and “Say No By Default.” The team made a conscious effort to write only as much code as was needed to get the job done. They—wisely, I might add—realize that every line every feature has a cascading string of implications. While writing the code for a feature might be easy, it needs to be tested, maintained, and integrated into the rest of the system (does the feature require other supporting features?). They get to the point of writing less software by saying “no” to feature requests. They really worked to make each feature prove it’s worth. They would slow down, and not take action on an idea for a week, and make sure it was truly a good idea before implementing it.
Next, they explained their development process. In my mind, this process looks like a simplified and quite functional iteration of the “extreme programming” or “agile programming” concepts. The main idea, as they put it, is to get to “real” as quickly as possible. This means not spending time writing long functional specifications, but rather focusing on creating paper prototypes, then HTML mockups. This idea I like a great deal, and have been using it more and more at work. It really gives everyone, from designers to programmers to clients or other stakeholders, a common ground to work from. Words in specs can (and are) misunderstood. HTML mockups are much more concrete. Then they move to prototyping, where they program in just the functionality needed to make the mockups come alive, and finally launch and maintenance.
I’m really just scratching the surface of what they said. I really do encourage you to go to the workshop, as they have a lot of good ideas about each of the things I’ve mentioned and more. But, I’d like to spend a little time critiquing the methodology. Most of my critiques apply to attempting to take their system and apply it a dissimilar situation. You might find these more or less of an issue than I did.
A team’s shared values (“mantras”) must truly be shared amongst all the team members. I didn’t really hear much about how 37Signals developed their mantras, but I’d imagine that they just arose out of many conversations and time spent working together. Concepts like these won’t work if applied to a team in a top-down manner; at least, they wouldn’t be nearly as effective in that situation. And heaven forbid if not all the team members buy into the values. Disagreements about indentation or some other minutia of code style are bad enough, but if not everyone bought into, say, the concept of saying “no” by default…well, I imagine the results wouldn’t be pretty. So, how do you get a team to coalesce around some set of values? Well…that’s what a good manager is for, I guess. Still, I’d caution anyone against trying to unilaterally apply 37Signals’ mantras in their team.
You may have noticed in my high-level fly-by of their process, I didn’t mention anything about testing. I’ve been schooled in the church of user-centered designed and methodologies that rely heavily on user testing. These guys, by their own admission, didn’t really test at all. But, they got away with it, in fairly spectacular fashion. How? Clearly, much of credit goes to the team that built the product. They all had a great deal of skill and tons of experience. They were focused on created a usable product, even if they didn’t employ traditional usability practices. Skill and experience can, I think, make up for testing to a degree. At some point, you know what the UI trouble spots are, and you can create designs that avoid the common traps. Plus, they were willing to iterate the design aggressively to address problems as they arose. But, for teams without incredible designers on hand, I think the tried and true UCD processes can be very effective.
The 37Signals guys had a couple of other natural advantages. Because they were, in effect, their own clients on this project, they didn’t have to deal with many of the issues that can arrive when working with either internal or external clients. For example, in a client situation, you’d want to be sure the client understood your team’s shared values and was willing to work with them. If your team fully bought into the “less software” mantra, and you were working with a client that wanted lots of extra bells and whistles, then, well, you’ve got problems. Not everyone has the luxury of choosing to work only with people who “get it,” so I see this as a potentially problematic area.
Finally, they were able to put a fairly tight scope on their problem domain (communication and project management). They were able to focus on three aspects (messages, to-dos, and milestones), and abstract the concepts so they could apply to many different situations. Many people face problem domains that, for any number of reasons, are quite specific and are imposed upon the development team. Sometimes, the complexity and messiness of the real world can’t be easily abstracted or simplified. And the “say no by default” mantra isn’t going to help you here, either (but the other parts of their process quite likely could help).
So, if you go, take good notes (I wish I had taken better notes, and I never got the promised slides in the email) and put some thought into how their learnings can be put into use in your situation.
Posted by Karl
March 13, 2005 05:32 PM