"Experience, Empiricism, Excellence"
Please share with your colleagues and friends

Organization Structure refers to the way people in a business or department are organized. Organization Structure significantly affects culture, ways of working and decision making.

As businesses grow beyond single isolated teams they tend to seek ways to structure themselves in an attempt to make work and people more "manageable". This is based on the mistaken belief that structure is organization, whereas structure is only one part of organization. Structure can be useful when it reflects desired cultural models and isolates truly separate concerns (e.g. ethical divides in different parts of a business such as tax advice vs. audit assurance) or completely separate brands/business lines. However, by its nature, structure can be divisive.

Every team boundary, or other structural boundary, typically causes a team inbox, backlog or other form of work queue adding to the total Lead Time for work unnecessarily. As a result, structure increases the impedance in the organization to doing a piece of work.

 

The People View looks at the "soft-practices" involved in communication techniques, team building, decision making, leadership and team forming. 

There are a number of ways of forming teams:
 Discipline Teams
Discipline Teams are formed by making teams around technical specialists.
This approach leads to requirements teams, testing teams, development teams, management teams etc. We strongly recommend against this approach as there is significant cross-team coordination required to deliver anything. We’ve observed that most integration problems are caused by team-of-teams working, and this approach forces team of teams working. Typical problems include:
  • Cross-team conflicts caused by abdication of responsibility for quality
  • Cross-team conflicts caused by unclear Definitions of Done
  • Discipline teams begin to care more about discipline maturity than business value delivery
  • Discipline teams begin a process scope-creep to other areas (e.g. test teams trying to control defect lifecycles within development teams)
  • Discipline teams become increasingly abstract talking shops, they don’t actually deliver anything
Component/Service Teams
Component/Service Teams are formed by making teams around architectural components.
This approach leads to GUI teams, middleware teams, database teams etc. We generally recommend against his approach for entire systems as user facing changes require the coordination of multiple teams. Along with many of the problems of Discipline Teams we also see Component Teams caring more about the purity and architectural separation of their component more than Business Value delivery.
Feature Teams
Feature Teams are formed by making teams around significant areas of user facing functionality. Feature teams are cross-functional in the sense that they can work across the entire architecture, and all components or services to deliver an end to end user requirement.
This approach can be implemented in 2 ways:
  • Requirements based – Feature teams are created to deliver a particular end to end requirement (e.g. an Integration Scenario)
  • Stable team – Feature teams are created to be enduring. The teams then pick end to end requirements, such as Integration Scenarios, off a backlog one by one
Feature teams also have disadvantages in that there is often overlap between Integration level requirements within system architecture and delivery, and so a mechanism for conflict resolution needs to be put in place (e.g. a Product Forum). This approach can also lead to no one team doing the “common good” work that’s general enough to not be considered part of an end to end requirements but still necessary to achieve good quality.
Platform vs. Application Teams
A mix of Component and Feature approaches is to build:
  • Platform teams that are organized around an enabling architecture, common services and APIs. A platform team is essentially a multi-component team that is focused on “common good” work at all times.
  • Application teams that are organized around end to end requirements, building applications or services on top of a Platform. The work of various Application teams will drive priorities on Platform teams.
Although this model provides the best of both worlds it frequently leads to conflict between application/service teams and platform teams and so we recommend using the Product Forum practice to coordinate.
Holistic Teams
We recommend that teams include a mix of people with all of the skills needed to take a business requirement from an initial problem, through candidate approaches and eventually to a deployed live product.  In tune with DevOps philosophy Holistic Product teams support what they make, incentivizing to make high quality products and foster good relationships with their customers.
Every case is different but in the general case we’ve had significant success with a combination of Holistic Product teams for single products and Holistic Platform & Application Teams for Product Family development.

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn