3 ms·

This is very interesting. Can you elaborate more on such organizational structure or know of anyone implementing in real life? To me it totally makes sense. In

This is very interesting. Can you elaborate more on such organizational structure or know of anyone implementing in real life? To me it totally makes sense. Instead of the inevitable interdependency that arises through the component model, I can see that if teams were building features on their own than it could be completed at their leisure (in the budget & time affordable) without the multi-directional multi-disciplinary communication shitshow. I wonder if there is an official name for this feature teams model or more guide on how to implement it.

nradov 10y ago
Scaled Agile Framework features and components: http://www.scaledagileframework.com/features-and-components/ http://www.scaledagileframework.com/features-and-components/ "Scaling with Feature vs. Component Teams" by Ken Rubin: http://www.innolution.com/resources/presentations/svaln-2015-scaling-with-feature-vs.-component-teams http://www.innolution.com/resources/presentations/svaln-2015...
- brilliantcode 10y ago
  This is gold. Thank you for posting that.
pcsanwald 10y ago
The more general term for these two structures are Functional vs Divisional structures. In the case of software engineering, a feature based team is a functional structure, and a "database team" (or "API team", or any other specific technical concern) is a divisional structure.
- brilliantcode 10y ago
  so why aren't more shops implementing a functional organization? It's still divided into front-end and back-end. What is the hindering factor and what tools would be a good fit for functional organization? AWS Lambda where people push their own backend along with the front-end thereby managing the full stack?
  - pcsanwald 10y ago
    I have no idea why many engineering organizations insist on maintaining the artificial distinctions of "front end" and "back end". I think we do ourselves a disservice by labelling ourselves with those distinctions, but the entire industry seems to disagree with me.

nradov 10y ago

Scaled Agile Framework features and components: http://www.scaledagileframework.com/features-and-components/ http://www.scaledagileframework.com/features-and-components/ "Scaling with Feature vs. Component Teams" by Ken Rubin: http://www.innolution.com/resources/presentations/svaln-2015-scaling-with-feature-vs.-component-teams http://www.innolution.com/resources/presentations/svaln-2015...

brilliantcode 10y ago
This is gold. Thank you for posting that.

pcsanwald 10y ago

The more general term for these two structures are Functional vs Divisional structures. In the case of software engineering, a feature based team is a functional structure, and a "database team" (or "API team", or any other specific technical concern) is a divisional structure.

brilliantcode 10y ago
so why aren't more shops implementing a functional organization? It's still divided into front-end and back-end. What is the hindering factor and what tools would be a good fit for functional organization? AWS Lambda where people push their own backend along with the front-end thereby managing the full stack?
- pcsanwald 10y ago
  I have no idea why many engineering organizations insist on maintaining the artificial distinctions of "front end" and "back end". I think we do ourselves a disservice by labelling ourselves with those distinctions, but the entire industry seems to disagree with me.