What is a feature team?
Throughout my experience, I have heard many different definitions/descriptions of what makes a feature team. For example, a feature team is:
- Developers and a tester (QA)
- UX, developers, and QA
- Architect, QA, developers
- A component team
It wasn’t until attending a class by Craig Larman a couple years ago on LeSS (Large Scale Scrum) that I really understood the definition of a feature team and their extreme value in organizational agility. So many organizations struggle with this concept due to standard corporate structures as well as a lack of education and knowledge on the topic.
In Craig’s and Bas Vodde’s book Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, they define a feature team as,
“A proper Scrum team is by definition a feature team, able to do all the work to complete a Product Backlog item (a customer feature). Note that Scrum team (feature team) members have no special title other than “team member.” There is not emphasis on `developer’ versus `tester’ titles. The goal is to encourage multi-skilled workers and “whole team does whole feature.” Naturally people have primary specialties, yet may sometimes be able to help in less familiar areas to get the job done, such as an `analyst’ helping out with automated testing.”
There are two key points in the above that I like to stress:
- Team member is the only title
- Whole team does whole feature
This means that all team members are not restricted by the psychological factors of a title. Combined, all team members have the skills that are used to get the job done. Also, there aren’t team members outside the team that are responsible for getting the feature done. The team owns the whole feature. This concept may greatly reduce waste in software delivery using lean thinking. This also provides whole product focus vs. project focus.
As an example, let’s say currently your organization has the following teams for a project:
- Team A – Engineering Team
- Team B – DevOps Team
- Team C – Data Team
- Team D – Reporting Team
- Team E – Architecture Team
- Team F – UX Team
- Team G – Business Analyst Team
- Team H – Infrastructure Team
- Team I – Release Team
- Team J – QA Team
In the scenario above, how much waste is in this process? How much customer focus is there? How much collaboration and trust is there? How is the culture?
Now imagine if you took the perspective of all of the teams have skills that are needed to get a project done. What if all teams looked like this:
- Team A – (the following skills are on the same team):
- Engineering, DevOps, Data Analysis, Reporting, Architecture, UX, Business Analysis, Infrastructure, Release, Testing
Would waste be reduced? Would there be more customer focus? How much more trust and collaboration would there be? Do you think your culture would be different and improved?
Craig poses the following question in regards to studying feature teams, “Why study the following in-depth analysis?” You may read the excerpt from his book here.
His answer, “Because feature teams are a key to accelerating time-to-market and to scaling agile development, but a major organizational change for most–changing team structure is slow work, involving learning, many stakeholders, and policy and mindset issues. If you’re a change agent for large-scale agility, you need to really grasp the issues.”
Three key points that resonate with me:
- Accelerating time-to-market
- Scaling agile development
- Changing team structure is slow work
Accelerating time to market is critical for all organizations wanting to stay ahead of their competition and increase revenue growth. Also, scaling agile development is difficult due to corporate constraints and policy, however, feature teams may greatly reduce the pain in a quickly growing organization. It also takes time as there is a lot of thought and changes that go into organizational structure improvements.
Not having feature teams may result in a lot of common problems including:
- Poor communication
- Too many meetings
- Increase in hiring of silos and new silos of people
- Code that is built on complex communication structures resulting in complex systems and poor quality
- Delayed releases
- Major increased costs throughout an organization
- Increased waste and complex processes slowing time to market
- Poor culture
- Lack of emphasis on the customer
Some of the first steps I recommend in moving toward feature teams is to:
- Build relationships in the organization including at the executive board and respect the current roles
- Start to show the problems through a light framework with a quick feedback loop such as something similar to Scrum or Kanban
- Have a retrospective to show the problem and get feedback on the topic with leaders from across the organization
- Gather data from processes on wait time, quality issues, bottlenecks, etc. to make transparent to the organization
What has been your experience with feature teams? What problems have you faced with not having feature teams?