Team structure has a significant impact on PI planning, quality, measurement, and ultimately – delivery. Whether you’ve already adopted Agile or you’re just starting the journey, the way you structure your teams matters.
There are two general ways to structure your teams
There are two basic team structures – skills-based and domain-based. There are benefits and drawbacks to each team structure.
What is a skills-based team?
A skills-based team puts team members with similar skills on one team. For example, all front-end developers are on one team while back-end developers are on a separate team. All graphic designers are on one team, and all QA personnel are on yet another team.
When each team consists of the same skillset, all teams are involved in completing a client’s request. For example, if a client wants to add a monthly subscription option to some of their products, each team would do their part. The front-end developers would edit each product page to add a subscription option and the back-end developers would program the subscription service to function.
What is a domain-based team?
A domain-based team consists of team members with diverse skills who oversee a specific component of a project. Each project has multiple domains. For example, one team would be responsible for the shopping cart system while another team would be responsible for the membership area.
Each domain-based team consists of individuals with the combined skills required to complete any and all requests for changes to their domain. For instance, a membership area team would have both front and back-end developers, a graphic designer, QA, marketing, and people with any other skills required to complete requests related to the membership area.
The main difference between structures is in the delivery
The main difference between the two team structures is really about how the project is eventually delivered to the client. Skills-based teams focus on individual productivity, which delivers maximum lines of code. On the other hand, domain-based teams focus on system productivity, which delivers maximum customer value.
Skills-based teams – the pros and cons
Skills-based teams seem like the logical way to get work done, however, there are significant drawbacks.
The challenge of PI planning with skills-based teams
When it comes to PI planning, using skills-based teams can decrease team members’ confidence in their ability to meet their goals. Collaboration is difficult and becomes complex when multiple teams need to be involved in simple operations. Because of this, skills-based teams end up with far too many dependencies.
Some teams won’t say anything, but a large number of dependencies can undermine their confidence. Dependencies also make it difficult to measure results accurately.
Committed vs. completed – the drawbacks with skills-based teams
Skills-based teams use committed and completed to measure progress, but define a commitment as ‘completed’ when code is functionally complete. Completed code is great, but it still needs to be integrated with other aspects of the project to truly be completed. This can give a false sense of progress.
Team members know completed code isn’t a final product, but the executives observing demonstrations don’t know the difference. It’s possible for a skills-based team to present working code using mock services and have the client believe the product is ready to ship.
PI development with skills-based teams
It’s difficult to manage dependencies with a skills-based team. The main issue is the large number of changes required as work progresses. Some of those changes have a significant and unequal impact on the last team in the chain. When those changes happen late in the development cycle, the final team will usually spend a considerable amount of time completing integrations and rushing to complete their own work.
Whenever work is rushed, quality suffers. If code quality suffers, it will need to be cleaned up.
The main issue with skills-based teams is communication
Skills-based teams create artificial barriers to effective communication. Each team works in isolation; there are fewer opportunities for natural communication between departments. Efforts to communicate require extra meetings, which can slow teams down.
On the other hand, domain-based teams foster organic communication on a regular basis. It’s virtually unavoidable since someone from each area of expertise is already on the team.
Skills-based teams can make clients impatient
The biggest drawback with skills-based teams is brought to life in this article, written by Medium.com blogger Anshul Kapoor. In the article, Kapoor describes what happens when a fictional skills-based team presents a mock UI to a client. The team informs the client that the UI won’t display real data until other teams integrate their part of the project. The fictional client isn’t happy and doesn’t want to provide feedback on the UI – the client wants working data to test.
Domain-based teams – the pros and cons
Domain-based teams are created for one overarching purpose: to quickly and efficiently deliver value in a specific area of an application.
The benefits of PI planning with domain-based teams
Planning with domain-based teams is much easier than with skills-based teams. Workloads are divided according to domain so members of each team can give undivided attention to their area of expertise.
Confidence is also higher in domain-based teams because there are fewer unknowns and uncertainties.
Domain-based teams reduce dependencies so output isn’t interrupted or postponed as often as with skills-based teams.
Measuring progress is easier with domain-based teams
Thanks to a variety of input, domain-based teams are better at creating measurements that accurately indicate when a feature is complete or needs more work.
Committed vs. completed increases success for domain-based teams
Domain-based teams only consider a commitment completed when it’s delivered. Domain-based teams tend to achieve a higher ratio of committed vs. completed. Consequently, this makes project status transparent.
PI development with domain-based teams
Although domain-based teams do end up with dependencies, they’re easier to track and address.
Since domain-based teams are independent, they can produce full features quickly and deliver more of the team’s commitment.
Are you looking for a competent, affordable development team? We can help
Looking for a software development team? Our nearshore software development teams are structured to get results.
At ZAGA, we assemble custom development teams that continually push for quality, measure performance, and optimize based on performance data. We align our objectives with our clients’ goals following clear objectives.
With our nearshore development teams, you won’t have to wake up in the middle of the night to attend an important meeting. Contact us today to find out how we can help with your development goals.