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. […]
As well as being a popular term for the big visible wall charts and boards that Agile teams use, Kanban (literally translated from Japanese as ‘visual card’ or ‘sign’) is also the name of an evolving, and increasingly popular Lean Agile method in its own right.
However, the method is neither a development process nor a management framework. Rather it is a method for gradual evolutionary change driven by ‘pull systems’. Instead of planning what work will be done in advance, a limit is placed on work-in-progress based on capacity. New work is pulled from the queue only when something is finished – Just-in-Time – in order to create a continuous flow of delivery.
The Principles of Kanban
The Principles of Kanban are:
- Start with what you do now
- Pursue incremental, evolutionary change (unless there is real appetite for revolution!)
- Initially, respect and do not seek to change current roles, responsibilities & job titles
- Encourage acts of leadership at all levels
Suitability of Kanban
The agil8 approach is to recommend the overall Kanban method for organisational change where there is no appetite for the revolutionary introduction of new roles and practices that come with other Agile approaches.
This method is particularly suitable for those teams who find it difficult to plan their work in advance such as those doing support, maintenance and operations. Pull systems work very natutrally for such teams. However, the faster flow of value to the customer which Kanban promotes is clearly something that could benefit any team – even those already using another Agile method. Thus it can be used to great effect with Scrum, an approach often referred to as Scrumban.
Achieving Faster Flow
To get faster flow, Kanban focuses on driving down lead time by applying queueing theory. One way to reduce the lead time of delivery to the customer is to speed the rate at which each piece of work is completed. The other way, which is usually easier in software development, is to limit the amount of work in progress. With a team of fixed capacity, the more items there are in progress, the longer the customer will have to wait for each one. Switching tasks and context between multiple items also takes time.
Kanban limits the number of items to capacity rather than having work pushed onto the team. It also encourages the team to split work into smaller pieces that can be delivered incrementally. It encourages teams to reduce re-work by building quality in, and reduce waiting because of hand-offs, gold plating or impediments. Having to wait is particularly dangerous as the temptation is always to start another piece of work which will of course increase the lead time of everything else in progress. Thus identifying and removing bottlenecks and working as a cross functional team to help each other finish work is particularly important in Kanban.
The Core Practices of Kanban
The core practices are:
- Visualize the workflow on a Kanban Board to understand it
- Limit work-in-progress to expose impediments and waste
- Manage the work to flow effectively by removing impediments and wasteful practices
- Make process policies explicit (e.g., queues, work item and service types, Definitions of Done, etc.)
- Improve collaboratively, guiding the evolution using models and a ‘scientific’ method
- Implement feedback loops between team members in the workflow, between teams, and via the manager coaching team members
Kanban with Scrum and Other Agile Methods
Many Kanban concepts are present in other Agile methods. Sprints effectively limit work in progress, and the breakdown of work into small potentially releasable increments with cross functional teams help minimise waiting and smooth flow. However, this goes beyond the regular Sprint cycles of Scrum and all other Agile methods. It allows planning, delivery, review and retrospective to happen at any time to suit the team independently of each other. Thus Kanban has found popularity amongst experienced Agile teams who find their existing Agile process too restrictive.