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. […]
David Hicks is a Founder of the Agile Alliance and, with over 25 years’ experience in the field, he is one of the most qualified and experienced Agile consultants and trainers in the world. In 2015 David was voted ‘Most Popular Scrum Professional’ in an online poll for the annual international Agile Awards which recognise outstanding contributions in the field.
David’s journey into Agile began in 1987, through his MSc thesis on iterative development which was published by the British Computer Society. He started his professional career in 1988 as an analyst‐programmer, team leader and ultimately project manager with LBMS, the originators of the PRINCE and SSADM methods. David was responsible for defining LBMS’s first iterative SDLC and worked with early 4GLs and client‐server applications doing iterative development in the early 1990s.
David established himself as an independent consultant in the mid 1990’s and became a key figure in the DSDM Agile community in the UK. From 1997‐2001 David was hired by British Airways to manage the World’s first Enterprise Agile Transformation as it transitioned its entire 5,000‐strong IT organisation from Waterfall to DSDM. He managed the team of agile consultants, trainers and coaches on this programme for 4 years, during which time he provided consulting advice on the Heathrow Terminal 5 project, which in 1998 is where he first started using Scrum.
Since then David has founded and been the CEO of two agile consulting companies and has managed Agile Transformation teams on some of the largest and most complex Agile implementations in the world. He has expert level and practical experience in the complete range of today’s methods and has personally Certified in excess of 10,000 people in agile as a Certified Scrum Trainer (CST), Accredited Kanban Trainer, Certified AgilePM/DSDM Trainer and a SAFe Program Consultant.
David holds the following Agile qualifications:
- Certified Scrum Trainer
- Certified ScrumMaster, Product Owner and Professional
- Certified Kanban Trainer and Coach
- Certified SAFe (Scaled Agile Framework) Program Consultant
- Certified APMG Agile Project Management Trainer
- Certified Lean IT Trainer
- PMI Agile Certified Practitioner
- Certified DSDM Agile Trainer
- Certified DSDM Agile Advanced Practitioner
- Certified Agile Leadership Practitioner
- Training from the Back of the Room (TBR) Certified Trainer
David is also an Institute of Directors (IOD) Certified Company Director with 15 years experience as an Executive Director in the IT Services sector.
“David’s training style provides a fantastic mix of lecture, discussion, questioning, practicals and fun techniques which keeps everybody alert and interested throughout 2 days.”
Rick Donohoe, Technical Project Manager, Microserve – Certified Scrum Master.
To connect with David on social media, simply click on the Twitter and LinkedIn buttons below.