Of course, you can also implement by feature even if your teams are laid out in terms of technical specialities. It just means that some people from each team are collaborating on a feature for a while. They will all be expected to show that the feature works, is complete, etc.
Cross-functional teams aren't a pre-requisite for implmementing by feature. To indulge briefly in a straw-man argument, if you define cross-functional teams to be teams without technology specialisations, you have an organisation that won't scale in some directions.
So, of course, we don't define them like that. Some religiously-agilist people might attempt it, but presumably such people are already working on projects that don't need to scale across technologies.
We are in the interesting situation where we are re-evaluating some core architecture choices for a new module (that could be seen as an application by itself). So far our main product has been based on our own home-grown framework.
We are now looking at 'community' frameworks for web based applications (Zope, Rails, Seaside,...).
If we implement by feature this new module, I am not sure when the architectural R&D work will take place. Right now I am thinking of 'burning' one or maybe two iterations to explore our architectural alternatives; but this means not working on the features. Or maybe we could identify a small feature that we would implement with the different alternatives and then compare. This could be expensive!
What do you think?
Thierry
This reference to set-based design may be helpful. Having several 'spikes' may be cheaper than choosing an inadequate approach too early.
Credit to Bill Wake.
Commenting by HaloScan
