I've worked in many organizations which run the gamut of little-to-no organization and very small teams to very large organizations with strictly defined roles and structure.
I'm a personal believer in agile, cross-functional teams comprised of a business owner (e.g. product owner) that manages the work content, a process manager (e.g. scrum manager) that manages the process, a QA lead and a development lead. These would be supplemented as needed and could also interface with other dedicated teams (e.g. systems admin, database, documentation, etc).
Each team should be limited to a reasonable number of people and have a limited scope based on a related feature set.
The teams should be short-lived and members would flow between the teams and their 'parent' functional area when each team is formed and disbanded. This keeps them grounded in their functional areas when off the team and fosters communication between development and the various business areas when the team is working.
Note that here I am using the term 'development' very loosely. This structure could be applied to many business processes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've worked in many organizations which run the gamut of little-to-no organization and very small teams to very large organizations with strictly defined roles and structure.
I'm a personal believer in agile, cross-functional teams comprised of a business owner (e.g. product owner) that manages the work content, a process manager (e.g. scrum manager) that manages the process, a QA lead and a development lead. These would be supplemented as needed and could also interface with other dedicated teams (e.g. systems admin, database, documentation, etc).
Each team should be limited to a reasonable number of people and have a limited scope based on a related feature set.
The teams should be short-lived and members would flow between the teams and their 'parent' functional area when each team is formed and disbanded. This keeps them grounded in their functional areas when off the team and fosters communication between development and the various business areas when the team is working.
Note that here I am using the term 'development' very loosely. This structure could be applied to many business processes.