5 ms·

Generalizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on elimi

by huherto 10y ago

Generalizing this idea. Interdependences are big source of problems and delays in projects. Many people don't realize it, but you have to actively work on eliminating them. You see it in the form people waiting for other people. Every team should be organized in a way that they can we do their work without waiting for other teams.

nradov 10y ago
Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams. In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.
- brilliantcode 10y ago
  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.
- sytse 10y ago
  Feature teams make a lot of sense, but one of the problems is that you tend to end up with two bosses, one team boss and one functional boss. At GitLab we're trying to see if we can do component teams with handoffs (UX => front end => back end). This is hard and we might have to reconsider. I've detailed the reasons in https://about.gitlab.com/handbook/leadership/#no-matrix-organization https://about.gitlab.com/handbook/leadership/#no-matrix-orga...
  - nradov 10y ago
    In any large engineering organization with a bunch of products each of which are large enough to need multiple teams, multiple bosses are inevitable. The issues and technology are just too complex for any single boss to manage everything. A typical agile team member might be accountable to a resource manager for HR type stuff, a Scrum Master for team tasks, a Product Owner for team priorities and requirements, and multiple component stewards for component technical integrity. The key is to align everyone to a common set of program goals and clearly delineate responsibilities between those various "bosses" to prevent conflicts and avoid excessive communication overhead. A "no-matrix" structure might work in a small organization which has basically only a single product. In that case it's actually possible for a single competent boss to understand the customer, product, employees, and technology well enough to make good decisions.
    - sytse 10y ago
      As far as I know a matrix organization normally means a two dimensional one, with two bosses. You're totally right that all those functions exist and influence your work, but I don't think it is normal to call them bosses.
      - nradov 10y ago
        In most matrix organizations regardless of dimensionality each employee still has only one formal manager who deals with raises, career development, and disciplinary actions. The other "bosses" such as project managers aren't officially considered managers in that sense, although the employee may be accountable to them for certain things.
- YZF 10y ago
  That's not a silver bullet though. In a large software system you can't expect any individual to be as effective working in any area of the system. So you're winning on the blocking front but you're losing on the productivity front as people ramp in on different pieces and you're also potentially losing a sense of ownership from the developers and instead giving them a sense they're cogs in a machine... To me a better compromise is to ensure you have enough of a backlog that you can always pick something that is the right combination of expertise/interest/lock-free at any given time. If you plan properly and you have sized your teams properly things should move along better than trying to get everyone to work everywhere on some random feature. That's not to say you can't occasionally do that if something important comes along but to me feature teams in large scale software is to be avoided. [EDIT: realizing this is maybe too strong of a statement, a team can definitely work across multiple pieces and will ideally implement complete features, but those features need to be a match to the capabilities of the team as opposed to just looking a "feature team" as some sort of unit of production for any random feature] There's another part to this which is that it can be difficult to see the inter-dependencies between features. So modelling your software development as a bunch of teams that can just pull the next feature from the queue and work on it may actually not solve the locking problem at all but create more subtle dependencies and less efficiency.
  - nradov 10y ago
    If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay. For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate your thinking in multiple areas.) For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams". http://www.innolution.com/resources/presentations/svaln-2015-scaling-with-feature-vs.-component-teams http://www.innolution.com/resources/presentations/svaln-2015... No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.

by huherto 10y ago

nradov 10y ago

Yes this is one reason why with large software development programs it's generally best to organize around feature teams instead of component teams. In other words, a single agile team should be able to build an entire feature on their own through the full stack instead of having one team for the database, one team for the back end, one team for the service layer, one team for the UI, etc.

brilliantcode 10y ago
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.
sytse 10y ago
Feature teams make a lot of sense, but one of the problems is that you tend to end up with two bosses, one team boss and one functional boss. At GitLab we're trying to see if we can do component teams with handoffs (UX => front end => back end). This is hard and we might have to reconsider. I've detailed the reasons in https://about.gitlab.com/handbook/leadership/#no-matrix-organization https://about.gitlab.com/handbook/leadership/#no-matrix-orga...
- nradov 10y ago
  In any large engineering organization with a bunch of products each of which are large enough to need multiple teams, multiple bosses are inevitable. The issues and technology are just too complex for any single boss to manage everything. A typical agile team member might be accountable to a resource manager for HR type stuff, a Scrum Master for team tasks, a Product Owner for team priorities and requirements, and multiple component stewards for component technical integrity. The key is to align everyone to a common set of program goals and clearly delineate responsibilities between those various "bosses" to prevent conflicts and avoid excessive communication overhead. A "no-matrix" structure might work in a small organization which has basically only a single product. In that case it's actually possible for a single competent boss to understand the customer, product, employees, and technology well enough to make good decisions.
  - sytse 10y ago
    As far as I know a matrix organization normally means a two dimensional one, with two bosses. You're totally right that all those functions exist and influence your work, but I don't think it is normal to call them bosses.
    - nradov 10y ago
      In most matrix organizations regardless of dimensionality each employee still has only one formal manager who deals with raises, career development, and disciplinary actions. The other "bosses" such as project managers aren't officially considered managers in that sense, although the employee may be accountable to them for certain things.
YZF 10y ago
That's not a silver bullet though. In a large software system you can't expect any individual to be as effective working in any area of the system. So you're winning on the blocking front but you're losing on the productivity front as people ramp in on different pieces and you're also potentially losing a sense of ownership from the developers and instead giving them a sense they're cogs in a machine... To me a better compromise is to ensure you have enough of a backlog that you can always pick something that is the right combination of expertise/interest/lock-free at any given time. If you plan properly and you have sized your teams properly things should move along better than trying to get everyone to work everywhere on some random feature. That's not to say you can't occasionally do that if something important comes along but to me feature teams in large scale software is to be avoided. [EDIT: realizing this is maybe too strong of a statement, a team can definitely work across multiple pieces and will ideally implement complete features, but those features need to be a match to the capabilities of the team as opposed to just looking a "feature team" as some sort of unit of production for any random feature] There's another part to this which is that it can be difficult to see the inter-dependencies between features. So modelling your software development as a bunch of teams that can just pull the next feature from the queue and work on it may actually not solve the locking problem at all but create more subtle dependencies and less efficiency.
- nradov 10y ago
  If you're optimizing for productivity then you're focusing on the wrong metric. In order to deliver more customer value faster focus instead on driving down the cost of delay. For a detailed quantitative economic analysis of why this works please read "The Principles of Product Development Flow" by Donald G. Reinertsen. (Trust me it's one of the 10 best books on practical software management and will recalibrate your thinking in multiple areas.) For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams". http://www.innolution.com/resources/presentations/svaln-2015-scaling-with-feature-vs.-component-teams http://www.innolution.com/resources/presentations/svaln-2015... No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.