Component Teams vs Feature Teams
27 Feb 2018
There’s nearly always too much work. Certainly there is often too much work for one team. Considering the optimum team size (in Scrum) is between 5 and 9 people, it doesn’t take much of a backlog to require us to have multiple teams. When this is the case, it introduces the problem of how to divide the work up between the teams. The two most common ways I’ve seen teams organised are as Component Teams and Feature Teams – but which is the best way of organising your company? This is an area that is often debated. They are contrasting approaches to software delivery and I’ve heard many arguments in favour of each. Let’s have look at them. Component Teams Component Teams are considered to be made up of experts that specialise in a specific domain and they are focused only on the knowledge and technology related to their domain. It ’stands to reason’ that if there is an area of complexity needing work performed on it on a regular basis, we should have a team dedicated to it. Common examples are the user interface (UI) or the database (DB), we may well have a team for each of those. […]
Scrum is by far the most popular Agile approach. Indeed the terms Scrum and Agile are often used interchangeably and many people are not even aware that there are alternatives to Scrum. Scrum is very simple in its structure and very focused in its scope.
The agil8 Approach
The agil8 approach focuses not only on effective application of Scrum itself, but also integration with essential technical and management practices that it doesn’t cover. These essential technical practices include techniques such as continuous integration, refactoring, test automation and test driven development. Essential management practices include governance, architecture, programme and DevOps portfolio management.
The Scrum Framework
The Scrum framework itself organises work into short iterative Sprint cycles of no more than one month each. Each Sprint should have an agreed Sprint Goal to create an Increment of functionality to production quality, so that it could, if desired, be released.
Scrum Teams are small, cross functional and highly collaborative. The Scrum Framework defines 3 roles which together make up a Scrum Team
- Product Owner
- Development Team members
The Product Owner
The Product Owner works with relevant stakeholders to define the vision for the team, and the Product Backlog of requirements and other work items that will be put to the team. Typically it is a customer or business representative, or a business analyst acting as their proxy.
The Development Team
The Development Team consists of all those people who will do the necessary work to deliver the Product Increment at the end of the Sprint – this includes all necessary activities such as analysis, design build, testing, etc. The ScrumMaster and Product Owner may be Development Team members themselves if they are doing such work as well. The Development Team members determine what work they can do, and how they will do it. They work with the Product Owner to prepare or ‘groom’ the Product Backlog Items that are candidates for each Sprint in advance, and then have a timeboxed Sprint Planning meeting at the start of each Sprint to agree the Sprint Goal and the Sprint Backlog of tasks for the Sprint.
The ScrumMaster facilitates this process, and the other timeboxed Sprint meetings that are part of the Scrum framework. These include:
- a short, daily Scrum Meeting between all Development Team members to synchronise work (the Product Owner may participate in this as well)
- a Sprint Review meeting between the entire Scrum Team and relevant stakeholders at the end of the Sprint, to review the Product Increment and identify candidate Items for inclusion in the next Sprint
- a Sprint Retrospective meeting between Development Team members at the end of the Sprint, to determine what potential improvements to the process will be incorporated into the next Sprint (the Product Owner may participate in this as well)
The ScrumMaster is also responsible for coaching the rest of the Scrum Team in the use of Scrum, encouraging cross-functional collaborative team-working and self-organisation, dealing with impediments to progress that the other members of the Scrum Team cannot deal with themselves and promoting effective use of Scrum across the wider environment.