Small Scale Scrum vs. Large Scale Scrum

We surveyed individual members of small and large scrum teams. Here are some key findings.
204 readers like this.
Two different business organization charts

Following the publication of the Small Scale Scrum framework, we wanted to collect feedback on how teams in our target demographic (consultants, open source developers, and students) work and what they value. With this first opportunity to inspect, adapt, and help shape the next stage of Small Scale Scrum, we decided to create a survey to capture some data points and begin to validate some of our assumptions and hypotheses.

[Download the Introduction to Small Scale Scrum guide]

Our reasons for using the survey were multifold, but chief among them were the global distribution of teams, the small local data sample available in our office, access to customers, and the industry’s utilization of surveys (e.g., the Stack Overflow Developer Survey 2018, HackerRank 2018 Developer Skills Report, and GitLab 2018 Global Developer Report).

The scrum’s iterative process was used to facilitate the creation of the survey shown below:


Small scale scrum survey process

The survey, which we invite you to complete, consisted of 59 questions and was distributed at a local college (Waterford Institute of Technology) and to Red Hat's consultancy and engineering teams. Our initial data was gathered from the responses of 54 individuals spread across small and large scrum teams, who were asked about their experiences with agile within their teams.

Here are the main results and initial findings of the survey:

  • A full 96% of survey participants practice a form of agile, work in distributed teams, think scrum principles help them reduce development complexity, and believe agile contributes to the success of their projects.

  • Only 8% of survey participants belong to small (one- to three-person) teams, and 10 out of 51 describe their typical project as short-lived (three months or less).

  • The majority of survey participants were software engineers, but quality engineers (QE), project managers (PM), product owners (PO), and scrum masters were also represented.

  • Scrum master, PO, and team member are typical roles in projects.

  • Nearly half of survey respondents work on, or are assigned to, more than one project at the same time.

  • Almost half of projects are customer/value-generating vs. improvement/not directly value-generating or unclassified.

  • Almost half of survey participants said that their work is clarified sometimes or most of the time and estimated before development with extensions available sometimes or most of the time. They said asking for clarification of work items is the team’s responsibility.

  • Almost half of survey respondents said they write tests for their code, and they adhere to best coding practices, document their code, and get their code reviewed before merging.

  • Almost all survey participants introduce bugs to the codebase, which are prioritized by them, the team, PM, PO, team lead, or the scrum master.

  • Participants ask for help and mentoring when a task is complex. They also take on additional roles on their projects when needed, including business analyst, PM, QE, and architect, and they sometimes find changing roles difficult.

  • When changing roles on a daily basis, individuals feel they lose one to two hours on average, but they still complete their work on time most of the time.

  • Most survey participants use scrum (65%), followed by hybrid (18%) and Kanban (12%). This is consistent with results of VersionOne’s State of Agile Report.

  • The daily standup, sprint, sprint planning and estimating, backlog grooming, and sprint retrospective are among the top scrum ceremonies and principles followed, and team members do preparation work before meetings.

  • The majority of sprints (62%) are three weeks long, followed by two-week sprints (26%), one-week sprints (6%), and four-week sprints (4%). Two percent of participants are not using sprints due to strict release and update timings, with all activities organized and planned around those dates.

  • Teams use planning poker to estimate (storypoint) user stories. User stories contain acceptance criteria.

  • Teams create and use a Definition of Done mainly in respect to features and determining completion of user stories.

  • The majority of teams don’t have or use a Definition of Ready to ensure that user stories are actionable, testable, and clear.

  • Unit, integration, functional, automated, performance/load, and acceptance tests are commonly used.

  • Overall collaboration between team members is considered high, and team members use various communication channels.

  • The majority of survey participants spend more than four hours weekly in meetings, including face-to-face meetings, web conferences, and email communication.

  • The majority of customers are considered large, and half of them understand and follow scrum principles.

  • Customers respect “no deadlines” most of the time and sometimes help create user stories and participate in sprint planning, sprint review and demonstration, sprint retrospective, and backlog review and refinement.

  • Only 27% of survey participants know their customers have a high level of satisfaction with the adoption of agile, while the majority (58%) don’t know this information at all.

These survey results will inform the next stage of our data-gathering exercise. We will apply Small Scale Scrum to real-world projects, and the guidance obtained from the survey will help us gather key data points as we move toward version 2.0 of Small Scale Scrum. If you want to help, take our survey. If you have a project to which you'd like to apply Small Scale Scrum, please get in touch.

Download the Introduction to Small Scale Scrum guide

What to read next
Agnieszka is an Associate Consultant working for Red Hat App Dev Center of Excellence and developing software solutions for customers in small 1-3 person Agile teams. She spent a year researching Small Scale Scrum for her final thesis and has recently graduated with MSc in Computing (Communications Software).
User profile image.
Leigh is an Engineering Manager and passionate about process improvement and researching new ways to approach problems. He is an accredited ICF Coach and has led several Agile transformations within Red Hat.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.