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. […]
SAFe Scaled Agile Framework
SAFe™ – the Scaled Agile Framework® – is an increasingly popular approach for implementing Agile practices at enterprise scale. Initially outlined in several books by Dean Leffingwell, the approach draws upon and combines elements of Lean thinking, Agile development techniques and concepts of Product Development Flow. Through field experience at enterprise scale in many organisations, SAFe has evolved into a broad and deep framework of guidance, which can be accessed on-line at www.scaledagileframework.com.
The approach is structured into a three level pattern, which is designed to be tailored and adapted with additional or fewer levels as required for each implementation. The first of these is the Agile Team level, which is based on Scrum and eXtreme Programming (XP) with multiple teams delivering User Stories. Beyond the Team level, SAFe is aimed at programmes involving around 50 people or more. The Programme level serves to help the Agile Teams co-ordinate their collaboration on Features through Release ‘Train’ planning and the advance definition and creation of Architectural ‘Runway’. At the overall Portfolio level, a Kanban based approach is used for the definition and management of both Business and Architectural Epics against Investment Themes and their Vision and Roadmap.
The Portfolio Level
At the top level in SAFe the Portfolio Management function turns the organisation’s strategy into a set of Investment Themes, typically for the next 6-12 months. Percentage allocation of budget and resource is agreed to ensure each theme receives appropriate focus as planning commences and lightweight Business Cases are produced. Business and Architectural Epics to support each Investment Theme are defined on a Portfolio Backlog of large scale development programmes which will span multiple releases. A Kanban-based pull system is used to manage the flow of Epics and ensure that the economic basis for decision making is quantitative and transparent.
The Programme Level
The Programme level provides the essential glue to ensure that the work of the Agile teams is aligned with the organisation’s strategic Vision and Roadmap for each Investment Theme. Programme level Product and Release Management is designed to help prevent the work of multiple Agile teams becoming mis-aligned and difficult to integrate. SAFe provides a number of tools and techniques to address the typical challenges of focussing the efforts of large programmes to deliver maximum return on investment (ROI).
At the Programme level business and architectural Features are defined and ordered in a Programme Backlog. Release ‘Train’ Planning is performed by teams together on a regular cadence, typically every 2-3 months. Potential Shippable Increments (PSIs) of business functionality are used for planning with Hardening/Innovation/Planning Sprints used as necessary to ensure delivery on demand. The evolving architecture necessary to support new business functionality is also planned and developed ahead of the business functionality as an Architecture ‘Runway’ that it can ‘land’ on. In addition, a System Team is often established to create initial infrastructure and then support and share the Agile teams’ system-level continuous integration and end-to-end testing efforts.
The Team Level
At the Team level, SAFe recommends use of Scrum plus XP technical practices to ensure high quality. Each Agile Team has a Product Owner and Scrum Master and works in Sprints to deliver new architecture and User Story functionality. In addition, Agile Teams collaborate in Release Train Planning and each has its own Team Backlog and PSI Objectives. Thus whereas Scrum focuses on the Agile process for a single team and has little to say about multi-team environments, SAFe goes far beyond concepts like Scrum-of-Scrums to ensure that large programmes can see the wood for the trees and deliver maximum ROI in line with their Vision, Roadmap and Portfolio Investment Themes.