"I am beginning to think that even small teams should be split in two groups: feature and maintenance" Noooooooooooooooooo! :-) Seriously though - I'd go as f

"I am beginning to think that even small teams should be split in two groups: feature and maintenance" Noooooooooooooooooo! :-) Seriously though - I'd go as far as saying that it's an organisational anti-pattern. Every time I've seen folk do this it's gone terribly wrong. Some of the behaviours it seems to encourage: * The feature team no longer get to deal with the messes they produce - the maintenance team does. So the feature team suffers a pressure to not worry about those issues so much, which leads to worse code getting released. * The maintenance team gets seen as being less important than the feature team, so product maintenance gets neglected. * You waste a lot of time in pointless arguments over whether something is a feature of maintenance. The distinction often ends up actually being fun vs not-fun. * Feature development is perceived as being "harder" than maintenance - so all of the best coders end up in the feature team * Once the previous point gets into play and you have the "good" devs on the feature team and the "bad" devs on the maintenance team you suddenly get being assigned to the latter as a being seen as an insult/punishment (in one particularly egregious case I saw being assigned to the maintenance team being actually used as a punishment! Gack!) Seriously - total suckage. Don't go there. (Also curious to know why you don't think a kanban approach is a good one for feature development - since I use it that way myself, and know a bunch of other folk who have that approach too.)