In a recent webinar that we hosted, we opened discussion around pilot Scrum teams– your first Scrum team. We know you’re eager to get your hands on this new agile development process, however, before you can create your first team and use it for real projects, some obstacles might stand in your way.
Here are five common obstacles we see people run into when forming their first Scrum teams and how we recommend mitigating them.
Team Size
Team size is one of the most common obstacles to forming a pilot Scrum team.
The optimal number of people on a team should be between 3-9, with an average size of 7. This is because the larger your group gets, the harder it will be to get work done (and keep everyone happy).
However, if your pilot Scrum team has too few members, then they may need more diversity in skillsets or perspectives.
To help mitigate this issue, consider splitting up into multiple smaller groups so that each can tackle different projects simultaneously; this allows each subgroup within your organization’s overall project(s) to move faster without compromising overall progress.
Find more information regarding optimal team size here.
Software/Technology
Many different software and technology options are available to help you with your pilot Scrum team, but not all of them are created equal. It would help if you choose the right tools for your specific needs and goals. Here are some things to consider when selecting software:
- What does your Product Owner need? Do they need a tool that allows them to manage tasks from their phone, computer, or both? Does the Product Owner need access to data about user behavior on desktop, mobile, or both? Do they want something simple and lightweight like Trello (which can be downloaded directly from the App Store) or something more user-friendly like Jira (which requires installation through an enterprise server)?
- Is there enough time between now and the launch date to test out several different platforms before making a final decision? How much flexibility do we have in terms of budgeting? Some products may cost hundreds per month while others only require one-time payments up front followed by monthly fees depending on usage levels rather than several users within an organization.
If your technology isn’t the right fit for your team, it will do more harm than good. Remember, Scrum adoption doesn’t work by implementing a tool like Jira and hoping the team will follow, it works by teaching the team the concepts of Scrum and using a tool like Jira to aid their efforts.
The Product Owner
The Product Owner (PO) is responsible for ensuring the team delivers the right product; this role owns the ROI. The PO is the overall vision holder and is responsible for deciding what work is to be done, in what order, and what criteria the development team must adhere to. However, they are not allowed to tell the team how to do the work.
The work and criteria are stored in a single shared source of truth: the product backlog. The PO is the only position empowered with ownership of the product backlog. Others in the organization may provide input, but the PO ultimately decides the contents and priority of the backlog.
Simply put, the PO is responsible for creating and maintaining backlog items (and ensuring that the criteria is clear, enabling developers to “do their thing”), prioritizing and adjusting the backlog to ensure that business value is produced consistently, and reviewing and accepting or rejecting the work produced by the team.
The key here is that your PO has a solid understanding of Scrum principles. Whether you elect a veteran PO for this role, or someone is transferring into this role with no prior Scrum experience, it is crucial that they have adequate knowledge of the framework and understand their role in your organization.
The ScrumMaster
The ScrumMaster (SM) is the owner of the process. They are responsible for supporting and keeping the PO and team members on track, and also ensuring that everyone is adhering to fundamental Scrum concepts. This can be challenging because it requires you to know how to do everything: agile, communication, listening, problem-solving, and coaching.
As part of keeping the team on track, the SM helps the team identify and eliminate the speedbumps and roadblocks that are stunting their progress. In doing so, they evaluate how well the current development process is working:
- Where can your team improve in order to produce the highest business value in the shortest amount of time?
- Are there persistent bottlenecks limiting your production?
- Do all members of the team have an adequate understanding of Scrum principles?
- How can the PO be supported in their efforts of creating an efficient, proactive product backlog?
Similar to the PO, the SM will struggle without a solid understanding of Scrum. Empower all of the roles of your Scrum team to continuously learn and pivot to better practices that propel the team. Your organization’s Scrum success has one limiting factor: the people performing. So, invest in them.
Getting Every Team Member on the Same Page
The fifth and final obstacle to forming your pilot Scrum team is getting all the players on the same page. Working with a remote team can be tricky, especially if some members are in different time zones.
For example, let’s say you have a 12-hour difference between your developers and Product Owner. You’ve set up conference calls daily at 9 am PST (your local time) and 6 pm EST (their local time). That means that while they’re working on their tasks during the day, you’ll be sleeping– and vice versa.
Even though tools like Slack allow for real-time communication across multiple channels, there will still be moments when one person needs clarification from another person who isn’t available at that specific moment in time because they’re asleep.
We recommend creating a shared understanding of both sides: 1) The Product Owner’s vision and 2) Your understanding of how each feature will work once implemented.
Beyond just the Scrum team staying on the same page, leadership must also be on the same page. A common obstacle for an organization building its first Scrum team, and even for an organization that has been practicing Scrum since its creation, is a lack of leadership buy-in.
When a Scrum team doesn’t have fluid communication among team members or has leadership challenging them and Scrum, the team will struggle to operate proactively. To avoid this, be cognizant of each individual team member’s needs and how your role affects them–whether you’re part of leadership or part of the Scrum team yourself. Support each other. Know when to ask for or offer help. Empower your team to fully embrace the Scrum framework and help them grow.
There Are Many Obstacles to Forming a Pilot Scrum Team; Some Are More Difficult Than Others
If you’re having trouble forming your pilot Scrum team because of one or more of these issues, then we recommend trying one of these solutions:
- Get everyone on board by holding retrospectives where you discuss what’s going well and what needs to be improved with your current process. Then ask everyone how they think things could improve moving forward (e.g., “How do we make sure everyone has enough time for planning?”). Once everyone has had an opportunity to contribute ideas–and hopefully agree on some changes–you can move on from there.
- Ensure each member understands their role within this new process before making big decisions about how things should change; otherwise, it may seem like nobody knows what they’re doing, which will cause unnecessary confusion.
In Summary
We hope this helps you form your pilot Scrum team and get started on your path to success. Remember that these are just some of the most common obstacles we have seen in our experience. If you have any questions or concerns about forming your team, please don’t hesitate to reach out! We would love nothing more than to help others succeed in their endeavors.
