I was in traditional project development, where I played the role of a developer. When the organization started to transition to Agile and the structure was revamped, I took up the role of a Scrum team member and then a ScrumMaster. We had initial training in Agile and Scrum. I heard a few terms such as “cross-functional,” “cross-component,” “feature team,” etc. I was taken by surprise and had no clue about how all this would work. I was very skeptical about all these characteristics of an “ideal Scrum development team.” I’m sure many of us go through these situations when we transition from one way of working to another, as we have to unlearn so many things that we have been doing from so many years.

Here are some of the preferred traits of a Scrum team:

  • Scrum teams are self-organized and self-directing. It means that the teams can design, plan, code, and test their own code; in short, they decide how to work, what’s the best way; they create their own working agreements; they make their own decisions about the best choices, alternatives, etc. They are told what the work is, then they take complete ownership regarding how to do the work. For the teams to collaborate and understand each other, it really takes a bit of time, as they need to cross through the various stages of the Tuckman Ladder: forming, storming, norming, and performing. So it is recommended that teams be as long-lived as possible. The preference is to rotate the backlogs among the teams, not the team members around the backlogs.
  • It’s recommended that Scrum teams work as feature teamsLet us first see what a feature team is. A feature team is one that can work on any of the components in the feature. Feature teams stay together for a long time. This enables them to jell. Feature teams are supposed to be cross-functional and cross-component. They can work on any component that cuts across that feature, end to end.
  • Feature teams need to be cross-functionalOne myth about cross-functionality is that everyone should know everything. But this is not true; it really means that as a team they need to have all the skills (building architecture, programming, testing, documentation, UI, etc.) that are required to complete the project from beginning to end.
  • Feature teams are empowered. They own that complete feature and can make changes to any of the components in that feature.

The journey

The journey to operate as a feature team is long. What I have seen and experienced practically, when I was part of the transformation using the LeSS framework, is that generally, teams embark on the journey to become feature teams in a phased manner. However, this approach may not be suitable to all teams and organizations; much depends on the nature of the work, as well as some other factors.

Teams organized by function


Step 1. Cross-functional team: Teams invest time in every sprint so that they are self-sufficient to complete the work end to end within the sprints. Initially, there could be a slowdown due to the learning curve, but it would yield to a faster rate in later iterations.

Own one component, end to end.

Step 2. Merge teams that work on different components that coordinate closely and have a lot of interdependencies, and make them into two or three feature teams.


Step 3: Reshuffle the teams such that they own all components of that feature gradually.


Feature teams are like generalized specialists in the sense that there are specialists in one area who, at the same time, develop secondary skills in other functions and components over time so that they are self-sufficient. To get to this stage, the team needs to invest some time in developing its secondary skills and cross-component knowledge during the sprints.

One of the main advantages of a feature team

Planning is easy as the team can work on any feature, fewer dependencies and coordination problems arise, and there is no major hand-off between teams as the team owns the complete feature.

A few elements that help Scrum teams in a scaled environment

  1. Component guardian: In feature teams, the ownership of code moves from individual teams to all teams. In such cases, there is the concept of the component guardian or component lead. These people are custodians of their components. Anyone on any of the teams who would like to make any changes in any of the components needs to talk to the component guardian, whose work is to safeguard everyone’s components so that any change made does not break the existing functionality.
  2. Collaborative design: If there is any common design that needs to be worked out, representatives from the different component teams get together and do a quick design so that everyone has a common understanding.
  3. Communities of practice: Equal importance is given to honing functional skills along with technical skills. For this there is a concept of communities of practice that is initiated across the organization, such as ScrumMaster COP, Testing COP, Architecture COP, etc., where those fulfilling the roles meet and enhance their skills in their respective areas, sharing best practices and resolving common issues.
  4. Continuous attention to technical excellence: The focus shifts from individual team accountability to a shared ownership of code and design, robust CI, CD, automation, TDD, refactoring, etc., which helps in building reliable increments in every iteration.
  5. Self-designing exercise: One practice that we found very effective for forming the teams was the “self-designing exercise.” This is a concept proposed by Craig Larman, and I will describe it very briefly here. This exercise was handled by very senior Agile coaches, for new teams that were about to start their sprints.The self-designing teams exercise is a unique and effective method of forming self-organizing teams without any external influences. This is one of the ways to empower teams, by giving them complete freedom to form themselves and choose their own ScrumMaster. This technique can shorten the transition cycle from the forming to the norming stages, as the team forms itself.
    • Goal: Form Scrum teams with a good blend of the required technical and domain skills.
    • Preparation work: Identify the team members, their skills, and the combination of skills needed so the team can operate as a true Scrum team and, if possible, as a feature team.
    • Duration: 1 day
    • Actual run: The product team articulates the vision to the teams. The team members are given predefined printed sheets, on which they do a self-assessment in terms of the number of years of experience they have in both the technical and domain areas. For a group of 35-40 members, the goal would be to form about 5 teams in a day. There would be a corner of the room designated for each team, where their skills in terms of technical and business domain, number of developers, testers, architects, and any other required functions would be listed on a board. Each team would do a visual radiator on the board after every round, similar to the one shown below, which indicates the team balance.
    • T5.png
    • In the first round, teams self-organize based on their skill sets. Once this is done, the facilitators go to each team and run an assessment in terms of the balance of the number of people and of technical and business domain skills. The facilitators note any feedback in terms of the positives and negatives. This is repeated in the second round, the teams again reshuffling themselves based on the feedback from the first round and trying to strike a balance of skills. In about three iterations, our team formation was complete. At the end of this exercise, the teams formed usually are quite balanced, though there could be a few shortcomings in terms of some technical skills and domain skills, for which the team plans to initiate knowledge-sharing sessions. Then each team picks its own ScrumMaster and comes up with a team name. The session generally ends with a retrospective.Preferably, all managers and stakeholders are absent so that the teams have complete autonomy to choose their own members.

    I would like to conclude by saying that self-organization and self-directing attributes are preferred for any Scrum team, but it is a bit difficult to really start right from there. Teams initially need some support/hand-holding. During this period, the ScrumMaster or someone else in the leadership role needs to exhibit adaptive leadership by coaching and guiding the teams as they pass through the stages of forming, storming, norming, and performing.

    Let us take the metaphor of our family team. Every day we do different things — cooking, taking care of kids, gardening, office work, laundry, studying, playing, listening to music, etc. — and not everyone is good at everything. But we help each other so that we are self-sufficient as a team. So maybe we could call our family team a Scrum team.

Originally Posted by Madhavi Ledalla @ Scrum Alliance on 3 February 2015