Martin Fowler recently posted PreferFunctionalOrganization. Here, his functional organization means “organize around the business functions,” what management would call a project-based organization and his technical organization means “organize around the technical functions,” what management would call a functional-based (development, test) organization. There's another option, that I didn't see on Martin's site, the matrix organization. In a matrix organization, managers of technical functions assign their people to business-based initiatives (projects).
As Martin says, “Since the whole point of software development is to serve its customers, then the organization should reflect this – yielding teams that are focused on providing business value rather than delving deep into technical esoterica.” One key way to do that, no matter what your organization, is to implement by slice.
Here's an example of implementing by slice: Say you're a bank and you want to take in new customers. For you, speed of intake is important. If you can't take in a customer (create an account) in 10 minutes, your customer will walk out the door and go down the street to your competitor. So, if you were to implement by slice, when you create-a-new-account, you would make sure that the GUI, the middleware, and all that database magic that happens in the back office all occurs in a specific time. Notice that implement by slice says pick one type of an account, implement all that, and then go on to a new account type. Now I'm not a banker, so I'm sure I've simplified this past the state of absurdity. But think about it. Create-a-new-account is a basic service offered by a bank. Just imagine if you had an organization (in Martin's terms, a functional organization) built around the idea of creating new accounts. You could have a small team of GUI designers, middleware people, database experts, testers, writers for the necessary help, all of the necessary skills, only focused on making a particular type of create-a-new-account software valuable to the business.
In Martin's “technical organization,” people focus on increasing their knowledge in their own area of expertise, and loaning that knowledge to the projects as they are assigned. In the create-a-new-account scenario, you'd have DB people organizing all the DB functions and creating just the right schema. But you may never realize the interactions between the different functions. What happens when you change the GUI so that a specific field is available earlier or later? What happens if you need to access a different database earlier or later than the original design specified? And, if you don't implement by slice, if you implement by technical organization (first the GUI, then the middleware, etc), then you're likely to encounter these problems:
- You stop the project because it's time, and you haven't finished something. Most often, the software closer to the customer/buyer (the GUI) is completed, but the back end is incomplete.
- You reinforce the barriers between the teams because you've built up technical debt in the product. People have to work harder to overcome the technical debt.
- You didn't really deliver what the customer wanted.
Martin's suggestion of a project-based organization is a great idea. But if you can't organize that way, make sure you implement that way — implementing features as a slice. Don't try to bunch up feature development (all the GUI, or all the network, or all the anything). Just implement what you need to do for a specific feature and let the design emerge. Since you'll be delivering (even if it's just to the rest of the project team) pieces that work, you won't have a huge investment of time that you'll feel is wasted if you have to redesign something.