4 ms·

I am beginning to think that even small teams should be split in two groups: feature and maintenance (even if this means a 3person/1person split). I often see t

by Argorak 15y ago

I am beginning to think that even small teams should be split in two groups: feature and maintenance (even if this means a 3person/1person split). I often see the need for internal tooling and polishing that is never met, because there is no one assigned to it, everyone has to build features. Scrum is a great tool for feature-driven development. Kanban is a great tool for continuous tasks. Why not have one team doing Scrum for features and one Kanban for maintenance? I often see that split in companies that have developers and a separate admin group, why not do that for developers internally? This would eliminate the "optimizing considered harmful" point, because there is group that can work on continuous improvement.

queensnake 15y ago
One place I worked had an explicit 30% dev time for internal improvement. It wasn't Agile, but cleanup work did supposedly get scheduled.
Deestan 15y ago
I'm imagining that will cause unpleasant friction between the two. The Feature group get all the credit and are heroes for solving things quickly, while the Maintenance group have to clean up their bloody mess without getting any recognition.
- Argorak 15y ago
  I think thats a problem in general. I've seen companies where the admin team was highly regarded, although all they did was (good) maintenance work. But they were also good in talking about this in a way of "this and that got better _in general_ because, over the last weeks, we worked on improving this and that". The idea of actually naming the people that have to do maintenance also gives them the possibility of talking about it in context of their work.
adrianhoward 15y ago
"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.)

by Argorak 15y ago

queensnake 15y ago

One place I worked had an explicit 30% dev time for internal improvement. It wasn't Agile, but cleanup work did supposedly get scheduled.

Deestan 15y ago

I'm imagining that will cause unpleasant friction between the two. The Feature group get all the credit and are heroes for solving things quickly, while the Maintenance group have to clean up their bloody mess without getting any recognition.

Argorak 15y ago
I think thats a problem in general. I've seen companies where the admin team was highly regarded, although all they did was (good) maintenance work. But they were also good in talking about this in a way of "this and that got better _in general_ because, over the last weeks, we worked on improving this and that". The idea of actually naming the people that have to do maintenance also gives them the possibility of talking about it in context of their work.

adrianhoward 15y ago

"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.)