Since we adopted the framework wholeheartedly, we’ve experienced a sense of rhythm, momentum, and productivity that makes our studio an exciting place to work and ensures that our work is consistently high quality.
Although it’s a framework for delivering software, Scrum isn’t restricted to the software industry. In this article, I’ll show you how we do things at Remote while also showing you how you can apply these principles in your own business.
Scrum was first conceptualised in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the Harvard Business Review article “New New Product Development Game”. In 1995, Jeff Sutherland and Ken Schwaber put the principles into a framework for software development.
It’s a series of ceremonies that teams carry out regularly to ensure an Agile work environment that provides predictability, discipline, and momentum to projects.
The success of Scrum relies on adherence to all of the ceremonies, not just some of them. That’s the only difficult part of Scrum; building a discipline of consistency with the ceremonies. It took us a few attempts to get it right, but once we did, it became part of our culture, and everything else within our culture levelled up in turn.
The foundation of Scrum is the “sprint,” a two-week cycle of work. The ceremonies revolve around preparing for the sprint, delivering the work within the sprint, and reviewing the sprint. This repeating flow creates a framework for measuring effectiveness and improving constantly.
Our team is split into Streams - a group of 2 or 3 developers who work together to complete their sprint. We rotate the people in the streams every few sprints so that everyone gets to work on all our projects with each other. We don’t like silos or just one person knowing the code for a project.
The Scrum ceremonies we use (including a couple of non-scrum ceremonies) are:
- Ticket creation
- Sprint Backlog
- Sprint Refinement
- Sprint Planning
- Standup
- Internal Demo
- Retrospective.
Ticket creation defines a single piece of work to be done. Tickets can be created by the project manager, ticket owner, lead developer, or other team members. The Product Owner decides what needs to be done and the Project Manager turns that requirement into tickets. Then those tickets are moved into the Sprint Backlog.
The Sprint Backlog is a list of outcomes that we need to achieve. Tickets can stay in the backlog for several sprints or longer as business priorities can change. The Project Manager conducts “Backlog grooming” every week to remove irrelevant tickets and prioritise the remaining ones.
We hold Sprint Refinement meetings every week. They’re attended by the team delivering the work, the product owner, and the Scrum Master. The product owner communicates the whole vision and aim of the project, and the team adds technical scope and defines the work to be done, including - importantly - a specific list of outcomes so that everyone is clear on what defines ‘done’ for that ticket. We keep all the tickets in the Sprint Backlog until they’re ready for development. Each ticket goes through two refinement sessions before it’s moved into the sprint; that week in between refinements allows the team to subconsciously consider the ticket, allowing for any concerns, questions, or brilliant ideas to come up before work starts.
The Sprint Planning meeting is where the team decides what they can deliver in the upcoming sprint. The team, product owner, and scrum master attend this meeting to review the Sprint Backlog and plan the work to be done. Now that we’re clear on what the requirements are, we estimate the Story points for each ticket. A Story point is a measure of complexity, size and effort. We use a scale on the Fibonacci sequence from 1 to 100, although if a ticket is bigger than an 8, it’s because it either needs to be split into smaller tickets or we’re not clear enough about the requirements.
Story points are an essential measure for us, as we don’t charge by time, we charge by story points; this changes the whole energy of our projects; Paying for the deliverables rather than the time we spent creating them is just so much better for everyone.
We hold a Standup every day to align the team and keep the projects on track. The team discusses what they’re working on; it’s an opportunity to bring up any challenges they’re facing and also to make sure that the sprint strategy is working; each stream will make sure that the right people are on each ticket in progress, and orchestrate the best plan for completing their sprint.
We use a method we call “Walking the board” for stand-ups. We use a kanban board to represent the flow of tickets from ‘Ready’ through ‘In Development’ to ‘Internal testing’, to ‘Code review’ and ‘Closed’. If someone’s stuck on a ticket, they move it to ‘Blocked’. During standups, we walk through the board and discuss the progress of each ticket. It’s a simple but essential ceremony that takes about 10 minutes every day and ensures everything stays on track.
At the end of every sprint, we hold an Internal Demo; each member of the team demos the work they completed in the sprint; it’s an opportunity for everyone to share their feedback and stay up to date with what the rest of the team is working on.
The Retrospective is a meeting to reflect on the sprint and identify areas for improvement. The team, product owner, and scrum master attend this meeting to discuss what went well, what didn’t, and what can be improved for the next sprint.
This is one of our most powerful ceremonies; a no-holds-barred, no-blame, tell-it-like-it-is analysis of the sprint. We celebrate our wins and talk about how we could have improved. We also analyse why things didn’t go to plan if something was off-track. These whys go deep, and we’ll continue discussing each point until we’ve got a new action point or additional process to adopt to make sure that if we do that thing again, it will go better. The Retrospective has forced us to grow and adapt, and over the last few years has been a massive driver for growth and improvement in the company.
So, those are the elements of Scrum. A continuous cycle-within-a-cycle of preparing, delivering, and reviewing. It takes time, discipline, and effort to enforce the process and refine that process for your team and delivery style, but the results are worth it.
Think about how you might apply these ceremonies in your own business, and when you’re working with software developers, ask them whether they are all-in on Scrum; if they are, the chances are it’ll show in the high quality and speed of their developments.
