Yes, much of the methodology can still work. This is like multiplayer Extreme Hacking (http://www.c2.com/cgi/wiki?ExtremeHacking http://www.c2.com/cgi/wiki?Ext

Yes, much of the methodology can still work. This is like multiplayer Extreme Hacking (http://www.c2.com/cgi/wiki?ExtremeHacking http://www.c2.com/cgi/wiki?ExtremeHacking). The full-on testing, DRY code, tight iterations, and frequent releases to the user all still apply. Each user feature probably requires spiking through the expertise of all 4 devs. If people don't work together, APIs and workflows can diverge and then integration becomes horrible. So everyone (+client) has to get together to build acceptance tests and integration tests between different layers of the framework. And I think the article is wrong - pair programming does work here, but not on domain-specific issues. The most useful way is to pair program the interfaces between layers/silos. The database guy and the kernel guy should pair program the kernel module that spits data out, and the DB module that loads its up. This gives each person a feel for the other's assumptions, and lets them lay out a smarter interface that takes advantage of both devs' silo'd domain knowledge. Also, even if you don't do cross-silo pair programming, code reviews are still useful. This can be totally informal, but saying "Hey can I walk you through my code?" discovers a lot of bugs, stupid misunderstandings, etc. Doing it frequently (daily) is useful because it makes you code with the understanding that you'll have to show it off later to someone who won't get it unless it's really clear - so the code stays clean, thus (hopefully) better. Once again, the bonus is that a common metaphor emerges even among more disparate members of the team. The point of Agile is that it's agile. As in, nimble. Flexible. Suited to your requirements. Subject to your needs and intelligent application.