Applying Scrum Principles for Greater Efficiency

The Scrum framework is widely used in software development, but it can be applied to other industries as well. The Scrum Guide 2020 defines a Scrum Team as a small team of people consisting of a Scrum Master, a Product Owner, and Developers, with no sub-teams or hierarchies. The team's focus is on one objective at a time, the Product Goal, this is one of the fundamental scrum principles. However, becoming a high-performing Scrum Team requires effort and improvement in specific areas that vary depending on the team's proficiency in using Scrum.

In this post, we discuss how we can apply Scrum Principles to Team Composition. Following the foundational techniques at different stages of your learning journey, you can ensure to learn about the best strategies to bring back to the team. However, Team Composition is just one part of the big picture, if you want a holistic view of your team's current process status, take advantage of our free agile assessment for Team Agility.

Team Composition and The Learning Journey

At Lean Agile Intelligence, we recognize Team Composition as the overall size, durability, and cross-functionality of the team. We divided the learning journey into 4 different stages: Developing, Emerging, Adapting, and Optimizing. In the following sections, we will discuss each stage in detail as well as provide practical tips and techniques to help you strengthen your skills in this area.

Source - Lego Scrum

Developing

Teams “developing” an understanding of the value of a Team Composition and adopting the foundational techniques should focus on the following improvements:

• The What: The team has the minimal functional skills (i.e., Dev, QA ) to create a potentially shippable product at the end of an iteration (i.e., sprint)

  • The How: Building a team with the right skills is essential for creating a shippable product. Here are some tips to ensure you have a team with the necessary skills:

    1. Define clear roles and responsibilities: Clearly define the roles and responsibilities of each team member based on their expertise and skills. This will help avoid overlaps or gaps in skills and ensure that everyone understands their specific contributions to the product.

    2. Identify required skills: Identify the specific skills required to create a shippable product based on the product requirements and project scope. This could include technical skills, domain expertise, communication skills, project management skills, etc. Make sure to have a comprehensive understanding of the skills needed for the project.

    3. Hire the right talent: Based on the skills identified, hire team members who possess the necessary expertise. Look for candidates with a proven track record of relevant skills and experience. Consider conducting technical interviews, coding tests, or other assessments to ensure that new hires have the skills required to contribute to the product.

    4. Provide training and development opportunities: Invest in training and development programs to upskill your team members. This can include workshops, seminars, online courses, certifications, or mentoring. Providing opportunities for professional growth will enhance the skill set of your team and increase their ability to deliver a shippable product.

     

• The What: The team is a long-lived, durable team that is rarely disbanded

  • The How: To build a high-performing Scrum team, the first fundamental aspect of the team should be team stability. In order for the team to establish successful and predictable results, the team should be long-lived in order to learn and grow. Teams often go through different stages of development. In 1965 Bruce Tuckman published his research titled “Developmental Sequence in small groups.” In that paper, he detailed the stages of group development including Forming, Storming, Norming, and Performing. More details can be found here. Since then more research has been done on team performance. One model that we recommend that’s aided by team stability is the Drexler/Sibbit Team Performance Model

Teams “emerging” beyond the foundational techniques of a Team Iteration Review and embracing it as they become more proficient should focus on the following improvements:

• The What: The team has the minimal cross-component skills (i.e., front end, middle tier, back end) to create a potentially shippable product at the end of an iteration (i.e., sprint)

  • The How: Establish regular channels of communication and collaboration among team members to ensure ongoing collaboration and knowledge sharing. Use collaborative tools, such as project management software, instant messaging, or video conferencing, to facilitate real-time communication, share updates, and address any questions or concerns.

  • The How: Define a clear and shared "Definition of Done" that outlines the criteria for a task or user story to be considered complete and potentially shippable. This should include the expectations for the work of everyone on the team to be integrated into the product incrementally as part of the iteration's deliverables.

  • The How: Encourage regular retrospectives or post-iteration reviews to reflect on the team's performance and identify areas for improvement. Collect feedback from all team members on the effectiveness of the collaboration process, and use the insights to continuously improve and optimize the team's performance.

• The What: The team is no more than ten people, including roles (i.e., Product Owner, Scrum Master) beyond Team Member

  • The How: The scrum guide defines a scrum team size as less than 10 people. Here is the exact quote…

    • “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. 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.”

    • Amazon famously published how they form teams with the “Two Pizza” rule which stated that no team can be larger than what two pizzas could feed. This was published in The Guardian here. Benedict Evans stated that this approach by Amazon enabled them to make “The machine that makes the machine.” This philosophy is contrary to traditional project management. In this way of working we treat a small group of people as a product itself that has a return on investment and needs to be developed like a product to grow over time.

Adapting

Teams “adapting” the Team Iteration Review to extract the full benefit should focus on the following improvements:

• The What: The team has shared specialists (i.e., UX, DBAs ) assigned as extended team members to engage when needed so they can create a potentially shippable product at the end of an iteration
  
  
  • The How: Conduct collaborative workshops, such as design sprints or brainstorming sessions, where the shared specialists and core team members come together to discuss and define the requirements, design solutions, or address technical challenges. These workshops can help foster cross-functional collaboration, creativity, and innovation, and ensure that the perspectives and expertise of all team members are considered.

  • The How: Provide cross-functional training opportunities for team members, including shared specialists, to enhance their skills and understanding of different areas of expertise. This can help build a shared understanding among team members, promote collaboration, and enable team members to contribute to tasks or stories beyond their core expertise when needed.

• The What: Extended team members share the same goals (i.e., iteration goal)

  • The How: In a different blog post for Accountability we discuss the first step to building self-accountability. “In the book “The Five dysfunctions of a Team,” Patrick Lencioni details the five dysfunctions that teams experience that prevent them from becoming high-performing teams. At the top of the pyramid of dysfunctions is “Inattention to results” which sits on top of “Avoidance of accountability". What this practice suggests is to create team and or product goals and continuously monitor the progress toward those goals as a team. This can be done daily, weekly, by sprint, etc. When things are going off track or the results are not as anticipated, the team must correct and adjust without the need for outside intervention. Creating a working agreement that describes how the team will create and assess their own goals is a good first start.

  • Something to note about this criteria is the statement “all team members can clearly articulate.” This is saying it’s not enough for the Product Owner, Scrum Master, or a few key members to understand the goals but truly every single person on the team or working with the team must understand the team goals and be able to communicate as needed.

Source - Jeff Bzos' Two Pizza Rule for Team Size

Optimizing

Teams “optimizing” the knowledge sharing of the Team Iteration Review learnings across the enterprise should focus on the following improvements:

• The What: The team has all the skills they need to create a potentially shippable product at the end of an iteration (i.e., sprint) and does not have dependencies outside the team

  • The How: Since a scrum team contains ALL the necessary people needed to deliver an increment of value, the skills on the team should be able to support working with stakeholders, maintenance, ongoing operation, R&D, etc. When a team maintains its own software it develops it and tests it in such a way that will consider the impact of releasing it for use. Often teams who do not maintain their own releases do not feel the impact of poor-quality releases and building products that aren’t useful for the business. To get started, consider the impact of growing skillsets and or slightly increasing the team size to achieve the ability to continuously maintain your releases. In addition, other teams may be able to provide self-service operational capabilities for your teams. Here is a great blog post that goes in-depth about how to create self-service ops for teams.

  • The How: The next step to becoming a high-performing Scrum team is for the team to grow their skills to become more cross-functional. Andy Cleff has a fantastic blog post that outlines steps to do this in-depth titled “Six Steps to Self-Learning Teams and Organizations” which can be found here. The steps he outlines are…

    • Build an Inventory of Skills

    • Build a Team Level Matrix

    • Create priorities, slack and flow

    • Develop Guilds

    • Measure

    • Make self-learning teams visible

*   *   *   *   *   *

"Cross-functional doesn’t mean everyone can do everything it means “the members have all the skills necessary to create value each Sprint.”"

*   *   *   *   *   *

Conclusion

In conclusion, for teams that are developing their understanding of Scrum, team stability is a crucial aspect to focus on, as well as keeping the team size small. Emerging teams should prioritize setting common goals that every team member can articulate and having most of the cross-functional skills to create valuable increments independently. For teams that are adapting to Scrum and extracting its full benefits, building all cross-functional skills and taking responsibility for all product-related activities, from stakeholder collaboration to research and development, are essential. By focusing on these areas, Scrum Teams can improve performance and deliver value more effectively. If you want to gain a comprehensive understanding of your team’s current process status, we recommend taking advantage of our free agile assessment for Team Agility.