Team Structure and the Impact it Has on Delivery
Team structure and team measurement can dramatically influence how much value teams provide during a Sprint or product increment (PI). It can also influence how smoothly the software development process operates for the teams in your organization. Generally, teams can be organized into two structures, a skills-based structure with similar skills on a single team or a domain-based structure where a team has all the skills needed to deliver value in one area of the application. We’ve found that a skills-based team structure causes a large number of dependencies, makes measuring team delivery challenging and increases challenges with code integration. The domain-based team structure reduces the number of dependencies, ensures measurements for feature completeness are understandable and accurate and gives the team more time to ensure high quality. For this article, we’ll review in detail how the different structures affected PI Planning, development, quality, and measurement.
Skills Structured Teams vs Domain Structured Teams
Before diving into the differences in how the teams operate, it’s worth setting up the differences in the team structure and why you’d want to structure teams that way.
Skills-Based Team
A skills-based team collects matching skills onto the same team. Front-end developers are on a single team. Back-end developers, the ones working on services used by the front end, are on the same team. QA is on a single team and so on. Skills-based teams allow managers to have more visibility into the exact processes the teams use. Another advantage is that managers usually have a specialty in certain areas such as development or QA. This structure helps ensure a similar process across teams. If a business partner wants to add a new category to the items being sold on the website, each team would be involved in the completion of that request. Databases would be updated by the database teams, services by the services team, and User Interfaces by the respective teams.
Domain or Feature-Based Team
A domain or feature-based team focuses on an area of an application. For example, one team would focus on the shopping cart, another team would focus on products. Of course, teams can handle more than one area of an application if needed. The people on that team would have the skills to fully complete any features requested by the business team. If we wanted to add a category to the items being sold on the website, the team could update the database, services, and web pages without needing any help from other teams.
Now that we understand the differences in the structure of the teams, here’s how the teams operate through PI Planning, development, and delivery.
PI Planning
PI Planning with Skill Based Teams
At a previous company, I managed a mobile development team. The mobile development team was just one team in an entire release train. Many other teams were part of this release train and configured based on their skills. The team I managed was responsible for mobile development, as well as developing services specifically for those mobile applications. Other teams in the release train were database teams, a web development team (strictly User Interface), ETL-based teams, and a team for internal services. As we went through the quarterly product increment planning, each team wrote their own user stories and determined the dependencies across teams. As the planning session progressed, more dependencies were identified across multiple teams. At the tail end of each dependency was the mobile development team.
At the end of the PI Planning session, we used the Fist of Five method to determine the team’s comfort level in meeting the plan. Due to executive visibility and pressure in the product increment planning session, most team members voted with a three. They “could live with the plan”. I later found out that a large number of dependencies made teams uncomfortable with the chances for success. Despite the high number of dependencies, we moved on to the development of the application.
PI Planning with Domain-Based Teams
In my current organization, teams are organized to deliver business value. For example, one team is responsible for orders, another team is responsible for quotes, and another team is responsible for security. There are three other teams that handle additional domains. Embedded in each team is user interface design, front-end development, and back-end development. The back-end developers are familiar with NoSQL databases and can deliver their own work without the need of a database team. We have an architecture team and a DevOps team that supports the six development teams.
For our planning sessions, we divide the work by domain, which allows teams to focus on their area of expertise and ensures that we can deliver value for our users. This structure allows us to do our quarterly planning and subsequent work without running into a large number of dependencies.
During the PI Planning session, each team took their Epics, broke the work down into User Stories, and in some cases, even created tasks for individual team members. Because the front-end, back-end, and QA efforts were within the same team, we didn’t need to add dependencies to the planning board. There were a few dependencies across teams—significantly fewer than the number of dependencies in the skills-based planning session.
When we used the Fist of Five method for these planning sessions, the team was significantly more confident in their ability to deliver. Even after encouraging honest scoring and trying a few arguments myself against the plan, the team gave the plan fours and even a few fives on the scores for success.
Measuring Success During the Product Increment
Committed vs Completed
Measuring delivery value can be quite difficult for teams. In Agile, velocity is considered a good way to measure delivery. Velocity alone, however, doesn’t provide a full picture of consistency. Measuring committed and completed shows a team how accurate and consistent they are on their delivery estimates. It also helps executives understand expectations for the teams’ deliveries.
Committed and completed is a fairly straightforward measurement of how many story points the team committed to at the beginning of the Sprint in relation to the number of story points actually completed at the end of the Sprint. The nuance is in the difference between what a skills team calls completed and what a domain-based team calls completed.
Skills-Based Committed vs Completed
Although the skills-based teams used committed and completed, what was considered completed was the code being functionally complete. The problem is that it was not integrated with the other layers. At the end of every Sprint, the mobile development team was able to demonstrate their working code but only with mock services. Despite explaining mock services, executives left the demonstrations with a false impression of the work being production-ready.
Domain-Based Teams with Committed vs Completed
For the domain-based teams, we also used committed vs completed. This time, however, the stories were only considered completed when they were delivered to production. When the project started, our committed versus completed ratio was only 30%. We were only able to complete 30% of what we committed to. As the team got more and more comfortable with their own velocity and the software development techniques we were using, the committed versus completed rose to 90%. That measurement alone gave the teams some comfort in ensuring they committed to the right amount and did not feel any undue pressure into over-committing. Because the code was delivered to production, the measurement was more valuable and understandable since stakeholders knew the exact status of the work in progress.
Now that we had a plan and a way to measure that plan for the product increment, the teams began to develop the features prioritized by the product managers and product owners.
PI Development: Development with Skills-Based Teams
Dependency Management
To begin development with the skills-based teams, we had several meetings to determine the services contracts and the data needed to implement the features. This allowed the teams to develop to a contract defined across teams. The mobile development team built out mock services based on those contracts. Those mock services allowed the team to continue working while the team responsible for those services began development. As the Sprints progressed the teams did their best to continue communication. However, as the database work progressed, the services needed to change to accommodate what was learned. Those changes caused delays. As the services changed and were delayed, not all information was relayed to the mobile development team. Because the mobile development team was the final team in the chain, it was impacted very late in the development cycle. Consequently, the mobile development team ended up spending 60 to 80 hours per week completing the integrations and scrambling to get their work done.
Quality and Measurement
Because of the scramble over the last two Sprints, we ended up developing low-quality code. It had to be cleaned up at the beginning of the next planning cycle. The business teams were also unable to use what was delivered until the very end of the PI. The team’s committed and completed numbers were very low due to unexpected changes upstream from their work. Last, but not least, we had to restate multiple times that the work wasn’t completed through to production due to upstream dependencies.
Obviously, some of the confusion could have been addressed with more meetings, more documentation, and more communication. Alternatively, a different approach to team structure prevents the need for additional meetings and more documentation because more communication happens organically.
PI Development: Development with Domain-Based Teams
Dependency Management
The dependencies identified by domain-based teams in PI Planning were more easily tracked and addressed through the Scrum of Scrums because there were significantly fewer inter-team dependencies.
Complete Delivery
With the domain-based teams, each team was able to complete full features. We were able to deploy the developed features to production to be used by customers. Because the teams were independent, they were able to deliver higher-quality code throughout the Sprints since integration happened during the Sprint. At the end of the product increment, we were able to deliver 90% of what we had committed to.
Quality and Measurement
The committed and completed measurement became more valuable because the code was actually pushed to production and not mocked up. This was a far easier message to deliver to stakeholders.
End Result
Domain-based development with cross-functional teams progressed more smoothly than with teams divided up into their respective skills. We were able to more accurately measure business value and delivery. To ensure good communication within skill sets, we set up guilds for the different areas of development. Each style of organizing teams has their benefits and drawbacks. As I’ve learned through experience, organizing with domain-based or cross-functional teams makes for a smoother development process and higher business value throughout the entire Sprint delivery cycle.
