Scrum is all about small teams that can adapt and evolve quickly, and the Scrum Guide states that the ideal Scrum size of a team is 11 or fewer people. Large teams are not prescribed by Scrum as teams with more people eventually result in more processes and hierarchies.
But what if you are dealing with a large project and a large budget? What if the scope of your project necessitates a larger team? What does Scrum advise in this case? In this blog, we attempt to take you through the structure of a Scrum team, the differences between a traditional team and an Agile team, and the various roles and responsibilities of scrum team members.
The reason Jeff Sutherland, Ken Schwaber and co-created the Agile Manifesto was because of the rigidity associated with traditional project management methods and teams. Traditional teams follow a top-down approach, are led by a manager and must follow a rigid hierarchical process during the software development lifecycle.
Agile teams on the other hand are small, independent units that are cross-functional, responsive, and self-managing, which means that there is no one leader and decisions such as who does what and when, are taken by the team members. The team has just one focus, and that is to deliver something at the end of a certain timeframe, and all the team members collectively work towards it. This autonomy and self-organization that embody the values of Agile help Scrum and agile teams perform better and keep them motivated.
Traditional teams are based on function and generally one team will be involved in completing the entire project. Alternatively, specialized teams may be involved in completing certain chunks of the project. For example, developers create code, designers are involved with UX, and testers will test functionality.
Agile, on the other hand, has several small teams working on a project with each team being involved in completing a particular section of the project and delivering a particular function. Teams will include members having different skill sets, which are needed to deliver the function that has been assigned to the team. They will collaborate as and when needed. This structure is needed in order to self-organise and ensure better focus for the part of the project that the team is involved in.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required—Scrum Guide
A scrum team is mainly made up of three main roles:
The scrum team often chooses itself. Which is to say; that the Product Owner along with the Scrum Master chooses the developer or the development team; or in more progressive organizations, the Product Owner chooses the development team. These two, in turn, choose the Scrum Master who they think would best be able to perform the duties of a servant leader. The Product Owner is often chosen by the management based on his or her capabilities.
According to the Scrum Guide, the development team consists of five to eleven people including developers, testers, architects, designers etc.
The Scrum team is driven by its common goal, which is to create product value and ensure that all stakeholder requirements are met. In Agile organizations, Scrum teams are required to be self-organized and empowered to take their own decisions.
As described earlier, the scrum team consists of the development team, the scrum master and the product owner
The development team is at the core of the scrum project. The team is made of more than just developers, and comprises UI/UX designers, testers, writers and others who are part of the team due to their skill and ability to contribute to the sprint goal.
Though the product owners own the product backlog and order and prioritise it, they do this with the help of the development team. The development team can give product owners an estimate of the sprint size. The development team maintains utmost transparency and keeps the product owner and the scrum master up to date with progress made. Although they follow the vision put forth by the product owner, they are empowered to take their own decisions, and they do this by being self-organized.
Once the product backlog is defined and the sprints are underway, the development team meets every day in what is a called a daily scrum meeting. These short fifteen-minute meetings help developers define the progress made and set the agenda for the next day's work. They are also able to call out any impediments that may be blocking progress. This ensures transparency through the progress of the project as everyone including the product owner known the progress made in the sprints so far.
The development team strives to meet the sprint goals within each sprint, thus keeping the project on track.
The Product Owner is the owner of the product vision, creating the product backlog and defining the product goal that needs to be achieved. The product owner ensures that the development team is clear on what needs to be achieved in each sprint and there is no ambiguity in understanding the client requirements or the product to be built.
The product owner’s responsibility is to ensure that the product backlog is maintained with the utmost transparency and that the scrum master and the development team are on the same page in terms of understanding the sprint goal for each sprint. He or she maximizes value by prioritizing products that need to be delivered first.
The Product Owner is the bridge between the stakeholders and the development team, facilitating clear communication between the two. This makes this role very crucial as they must earn the trust of both parties by working in the interest of both.
Through product backlog management, stakeholder management and release management, the product owner keeps the project on track, ensures stakeholder satisfaction and with the development team delivers a high-quality product at the end of each sprint.
It’s not an understatement to say the scrum master holds it altogether. From supporting the product owner to acting as a servant leader for the team, the scrum master does it all.
The chief responsibility of the scrum master is to ensure that the team can perform without any distractions or impediments to their work. This would involve solving issues and removing roadblocks that may threaten to hinder progress.
The Scrum Master is also a scrum evangelist and must ensure that the team is working according to Agile and Scrum professionals. This requires them to coach and mentor the team on Scrum processes—and not just the team, but the Scrum Master also has the larger responsibility of promoting Scrum in the whole enterprise.
Their servant leadership style of working helps Scrum Masters to aid the development team in its day-to-day activities while also supporting the Product Owner in maximizing value, managing and ordering the product backlog, sprint planning and in communicating sprint goals effectively to the development team.
The Scrum Master strives to bring in transparency and self-organization and helps the team in following the empirical approach to working.
So, now you know the three main parts to a scrum project. But which role would suit you best? This depends largely on your skills, experience and interest.
If creating, designing, building and delivering is what excites you more, then being on the development team would be your niche. You can deliver value through every sprint and challenge yourself to create, innovate and build new things. As a developer you may often double up as a scrum master for your team, especially if you are well versed with agile.
If promoting agile and scrum in the organization and mentoring folks on processes and practices is your jam, then you will be a great Scrum Master. As a Scrum Master, your servant leadership skills will be put to test. This people-centric role will help you manage teams and help them reach their goals.
If product management, interacting with customers and the business domain is what you like best, then you will do marvellously as a product owner. You must put on your thinking caps and interpret the requirements of the stakeholders to the team. Not just this, you may also be required to help customers understand what else their product can do or provide. You must be at your diplomatic best keeping not just the stakeholders happy but even your development team.
If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner—Scrum Guide
Generally, when the scope and the budget of the project increases, more team members get assigned and there is a need to split the teams for better efficiency.
The keyword here is ‘same product’ which means that even multiple teams need to continue having the same goal and objective and work towards achieving it. Experts emphasize on following the Agile values of collaboration and communication even when multiple teams are involved.
Although each team should have clearly defined goals and there should be separation of work, a high level of collaboration between multiple agile teams must be achieved. This can be achieved through daily stand ups, cross team retrospectives and cross team release planning.
The Scrum Guide suggests having between three and nine team members who are executing the sprint backlog. Scrum works best in smaller teams, so if your team size is increasing then it is time to start creating the second team.
Jeff Sutherland, the co-creator of the Scrum Framework, says that one can create multiple teams of an optimal size that best suits the Scrum operations in the organization.
Jeff Bezos has forever implemented the two-pizza rule in Amazon, which is that every internal team should be small enough that it can be fed with two pizzas. Amazon follows this approach to enhance efficiency and scalability.
While splitting a team, the product manager must make sure that teams continue to remain cross-functional. While there may be a tendency to split teams based on similar types of skills, this will go against the values of Scrum. The split teams must have team members who have a diverse range of skills and should focus on delivering sprint goals together as a team.
Agile teams are cross functional, which means that an agile team brings together people of different expertise who work together to achieve a common goal. This index on cross functional teams is because such teams are said to foster innovation, are highly productive, accountable, adaptable to change, flexible and reach goals faster due to their collaboration and self-organization.
Cross-functional teams are said to work better when the team size is small. This is expected since such teams have people with diverse skills and diverse personalities. In order to achieve success, the onus is on choosing the right team members. The right team should be assembled to get the best out of the cross functional collaboration.
It’s also important that such a team is given the right tasks and assigned the right goals. Though there is a high degree of autonomy in cross functional teams, it is important to give them the right direction so that they know their end goals. If clear goals are not defined there may be a tendency to go beyond allocated resources.
While there is a huge degree of autonomy with the teams, it important that such teams have a common thread that ties them together. A leader can be the common link between all team members. The leader ensures that there is consistent and open communication between the team members, each team member is given the proper tasks, goals are defined, the team is placed above the individual and success is shared by all the team members.
Conflicts and tensions between team members in such a diverse group is natural, but this is where the leader, often the scrum master, steps in and ensures conflict management.
There are several tools available in the market that help cross functional teams perform better. These tools make communication and retrospection easier, a requirement that is more important these days when team members are scattered across geographies, and projects are more intense.
The general rule of thumb is to have a single product backlog for a particular product. Managing a backlog may become cumbersome as more and more sprints get added, and technical debt increases.
This problem arises more when you are working with multiple teams. As a product owner you may be tempted to create multiple backlogs. But keep in mind that Scrum is quite rigid about having only one product backlog for one product as having multiple backlogs can create confusion, reduce collaboration, create more silos and lead to teams getting frustrated.
A single backlog may be difficult to manage, especially when multiple teams are involved but remember that it also helps to ensure that there is a single goal shared by all teams, there is more communication and collaboration, dependencies are reduced and there is lesser confusion
Most teams generally have a single product owner, but if it is a large project with multiple teams then we can consider adding more members to the product team. As a product owner with a large portfolio, you may get overwhelmed with managing the different aspects of the role. In such a case you could consider adding junior product managers who can take on the responsibility of handling every task, like writing user stories, quality assurance, validating new features and more.
The beauty of scrum is that it is value driven. The three core job roles of scrum master, product owner and development team are roles and not titles. But the problem arises when you are mapping titles to roles. A team or an organization has titles such as lead architect or associate tester, while Scrum has roles. How do you as an organization transitioning to agile, map these titles to roles?
A good workaround for this is to map people to roles instead of mapping titles to roles. You need to see which professional, or team member possesses the skills that will help them work better in the Scrum role. Your project manager, for example, may be great at helping team members by solving their problems, negotiating and handling conflict. This person will make a great scrum master.
Understanding what qualities, a particular role needs and then cross referencing it with your resources is the best way to map people with roles. Placing the people with the best characteristics in a particular role is an important aspect of scrum which will ensure happier teams and more productivity.
Your email address will not be published. Required fields are marked *
Systems thinking is a popular buzzword today. We h... Read More