Small Scale Scrum
Small Scale Scrum
Small Scale Scrum
COM
LEIGH GRIFFIN
AGNIESZKA GANCARCZYK
ABOUT OPENSOURCE.COM
What is Opensource.com?
INTRODUCTION
Introduction 5
CHAPTERS
Introduction
Here's how the scrum agile methodology can help teams of three or fewer work more efficiently.
skills to be self sufficient for the roles to be filled, is a In such engagements the customer is the only stakeholder
standard practice in Agile, but the real value for small- and their view and voice are followed to the letter. Planting
scale teams comes from members taking additional roles innovation is critical to get the team and customers to think
(within reason). For example, an engineer may become outside the project’s defined requirements so they can en-
the frontend developer, backend developer, quality engi- vision the final solution with the most creative and optimal
neer, or user interface (UI) designer. The idea behind this architectures, requirements, and designs.
approach is to ensure that the small team is as self-suf-
ficient as possible. For small teams to adopt multiple re- Customer growth over customer engagement
sponsibilities, the workload must be fair and the project’s A successful customer engagement is very important to a
processes must be streamlined. This can be achieved by project, but it’s not sufficient for building and maintaining a
continuously reviewing and improving work conditions and strong and successful relationship with the customer. For
simplifying processes to help the team focus on delivery. small teams, it’s important to approach business engage-
Coaching should be offered to give team members guide- ment from the customer’s business-success perspective.
lines to help them improve their skills. Growth or creation of business is the customer’s highest
priority for a software solution, therefore it should be the
Accelerating innovation over marginal team’s highest priority.
request-driven thinking
Request-driven thinking where specific business requests
are followed strictly, is important in enterprise engage- A version of this article was originally published on Medium and is republished
with permission.
ments, but innovation is what customers value the most.
and may be attended by the customer and/or customer pleted work, confirms fixes, and signs off on the release
team. The Sprint Retrospective is time-boxed and requires build.
no advance preparation. Due to the small size of the devel- The Scrum Guide’s [2] recommended time-box guidelines
opment team and the Sprint builds (with a smaller number per ceremony should be considered valid for Small Scale
of features delivered), this meeting is relatively short. The Scrum ceremonies.
Sprint Retrospective takes place after the Sprint Review
and before the next Sprint Planning meeting. Links
The Sprint Review, Sprint Retrospective, and Sprint Plan- [1] https://github.com/agagancarczyk/small-scale-scrum/
ning may be combined into a single meeting which we term blob/master/Agnieszka-Gancarczyk-20060828-Final-
the Sprint Termination, lasting approximately 90 minutes. Dissertation.pdf
These meetings are concise, structured (thanks to advance [2] https://www.scrumguides.org/scrum-guide.html
preparation), and must not include any unnecessary/unrelat-
ed discussions.
The First/Final Release is the project’s end result. A related version of this article was originally published on Medium and is
republished with permission.
The development team runs the tests, verifies the com-
• N early half of survey respondents work on, or are as- • T he majority of teams don’t have or use a Definition of
signed to, more than one project at the same time. Ready [8] to ensure that user stories are actionable, test-
• Almost half of projects are customer/value-generating vs. able, and clear.
improvement/not directly value-generating or unclassified. • Unit, integration, functional, automated, performance/load,
• Almost half of survey participants said that their work is and acceptance tests are commonly used.
clarified sometimes or most of the time and estimated be- • Overall collaboration between team members is consid-
fore development with extensions available sometimes or ered high, and team members use various communica-
most of the time. They said asking for clarification of work tion channels.
items is the team’s responsibility. • The majority of survey participants spend more than four
• Almost half of survey respondents said they write tests for hours weekly in meetings, including face-to-face meetings,
their code, and they adhere to best coding practices, docu- web conferences, and email communication.
ment their code, and get their code reviewed before merging. • The majority of customers are considered large, and half of
• Almost all survey participants introduce bugs to the code- them understand and follow scrum principles.
base, which are prioritized by them, the team, PM, PO, • Customers respect “no deadlines” most of the time and
team lead, or the scrum master. sometimes help create user stories and participate in
• Participants ask for help and mentoring when a task sprint planning, sprint review and demonstration, sprint
is complex. They also take on additional roles on their retrospective, and backlog review and refinement.
projects when needed, including business analyst, PM, • Only 27% of survey participants know their customers
QE, and architect, and they sometimes find changing have a high level of satisfaction with the adoption of agile,
roles difficult. while the majority (58%) don’t know this information at all.
• When changing roles on a daily basis, individuals feel they These survey results will inform the next stage of our da-
lose one to two hours on average, but they still complete ta-gathering exercise. We will apply Small Scale Scrum to
their work on time most of the time. real-world projects, and the guidance obtained from the sur-
• Most survey participants use scrum (65%), followed by vey will help us gather key data points as we move toward
hybrid (18%) and Kanban (12%). This is consistent with version 2.0 of Small Scale Scrum. If you want to help, take
results of VersionOne’s State of Agile Report [5]. our survey [3]. If you have a project to which you’d like to
• The daily standup, sprint, sprint planning and estimating, apply Small Scale Scrum, please get in touch.
backlog grooming, and sprint retrospective are among the
top scrum ceremonies and principles followed, and team Links
members do preparation work before meetings. [1] https://research.hackerrank.com/developer-skills/2018/
• The majority of sprints (62%) are three weeks long, [2] https://about.gitlab.com/developer-survey/2018/
followed by two-week sprints (26%), one-week sprints [3] https://docs.google.com/forms/d/e/1FAIpQLScAXf52K
(6%), and four-week sprints (4%). Two percent of par- MEiEzS68OOIsjLtwZJto_XT7A3b9aB0RhasnE_dEw/
ticipants are not using sprints due to strict release and viewform?c=0&w=1
update timings, with all activities organized and planned [4] https://www.wit.ie/
around those dates. [5] https://explore.versionone.com/state-of-agile/versionone-
• Teams use planning poker [6] to estimate (storypoint) user 12th-annual-state-of-agile-report
stories. User stories contain acceptance criteria. [6] https://en.wikipedia.org/wiki/Planning_poker
• Teams create and use a Definition of Done [7] mainly in re- [7] https://www.scruminc.com/definition-of-done/
spect to features and determining completion of user stories. [8] https://www.scruminc.com/definition-of-ready/
GET INVOLVED
If you find these articles useful, get involved! Your feedback helps improve the status
quo for all things DevOps.
Contribute to the Opensource.com DevOps resource collection, and join the team of
DevOps practitioners and enthusiasts who want to share the open source stories
happening in the world of IT.
The Open Source DevOps team is looking for writers, curators, and others who can help
us explore the intersection of open source and DevOps. We’re especially interested in
stories on the following topics:
• D
evOps practical how to’s
• D
evOps and open source
• D
evOps and talent
• D
evOps and culture
• D
evSecOps/rugged software
ADDITIONAL RESOURCES
WRITE FOR US
Would you like to write for Opensource.com? Our editorial calendar includes upcoming themes,
community columns, and topic suggestions: https://opensource.com/calendar
Learn more about writing for Opensource.com at: https://opensource.com/writers
We're always looking for open source-related articles on the following topics:
Big data: Open source big data tools, stories, communities, and news.
Command-line tips: Tricks and tips for the Linux command-line.
Containers and Kubernetes: Getting started with containers, best practices,
security, news, projects, and case studies.
Education: Open source projects, tools, solutions, and resources for educators,
students, and the classroom.
Geek culture: Open source-related geek culture stories.
Hardware: Open source hardware projects, maker culture, new products, howtos,
and tutorials.
Machine learning and AI: Open source tools, programs, projects and howtos for
machine learning and artificial intelligence.
Programming: Share your favorite scripts, tips for getting started, tricks for
developers, tutorials, and tell us about your favorite programming languages and
communities.
Security: Tips and tricks for securing your systems, best practices, checklists,
tutorials and tools, case studies, and security-related project updates.
Keep in touch!
Sign up to receive roundups of our best articles,
giveaway alerts, and community announcements.
Visit opensource.com/email-newsletter to subscribe.