I've been thinking a lot lately about how to build a lean development team.  Ultimately, I'd like to open up my own little software house with a small number of like-minded people.  The goal won't be to become rich, but rather to have a healthy work environment.So far, I'm defining a lean team as the following:Small;Self-organizing;All members must have QA in mind;Members must be capable of performing multiple rolesThe last point is where I'm worried a bit because, as the mantra goes...Developers make bad testers.While I understand that, often, developers are too close to their code or their colleague's code to make higher-level assessments of quality, I'm not convinced they are de-facto bad testers.  On the contrary, I'm of the opinion that the qualities of a good developer overlap greatly with the qualities of a good tester.Assuming this is correct, I've been thinking of different ways of getting around the dev/tester problem and I believe I have come up with a viable model.My model requires:A small software house with 2+ projectsAn Agile (iterative) approach to development and delivery1 team per projectAll team members will be Software DevelopersTheir job description will clearly state Development, Quality Assurance, Testing, and Delivery as responsibilitiesIf all these preconditions have been met, then the projects can be organized in the following fashion (this example will refer to two projects, A and B):Every team member will alternate between Developer role and Tester roleIf a team member is a Developer on project A, they will be a Tester on project BMembers will work on only 1 project at a time, and therefore are expected to be acting as either a Dev or a Tester.A Role Cycle consists of 3 iterations as a Dev and 2 iteration as a Tester (again, on two different projects)Project teams would have 3 Devs and 2 Testers at all times.Member Role Cycles should be out of phase by 1 iteration.This minimizes the abruptness of the team changes.  For each iteration, 2 Devs and 1 Tester will remain the same as the previous iteration.Given the above, I see the following Pros and Cons:ProsDistributes project knowledge throughout the company.Ensures team members aren't testing the code they helped write.Out-of-phase role cycles means no project ever has a 100% member switch.Alternating roles breaks the monotony of boring projects.ConsThe iterations of both projects are tightly coupled.  If one project were to cancel an iteration halfway through and start again, then the two projects would be out of sync.  This would make the role-cycle difficult to manage.Hinges on hiring Developers open working as Testers as well.I've received mixed reviews when discussing this approach with friends and colleagues.  Some believe that few developers would ever want to alternate roles like this, while others tell me they personally would love to try it.So my question is:  Could such a model work in practice?  If not, could it be tweaked into a working model?Note:  For the sake of brevity I have only focused on the Dev and Tester roles.  I'll expand on other roles if needed.
Viability of a Development Team with no *dedicated* Tester role
agile;testing;organization