How We Work With Scrum
Learn how it’s done the right way and what great things can happen as a result
“Scrum is an old way of working, meant to solve problems from another era. An organization working with continuous deployment doesn’t need it. There aren’t versions of the code. There’s no meaning to sprints. You are members of a cult with ceremonies that lost their meaning”.
This tweet, by an experienced engineer, triggered me to share how Scrum made our teams successful more than any other team I’ve worked with in the past 16 years.
I worked with Scrum in 2011, and then with dailies in 2018. Both times it wasn’t a great experience — no one understood why we do it or what are the benefits, it felt like we were reporting progress to our manager on dailies and that added a lot of stress to the day-to-day work.
In the past year and a half with Kry, I’ve been practicing it with our teams and learned how it’s done the right way and what great things can happen as a result.
The History Of Agile
An important thing I understood while learning about Agile, is that Agile is not its ceremonies. As written in the recommended book “The Art of Agile Development”, The Agile Manifesto was created by 17 proponents of lightweight methodologies that were created in contrast to waterfall development (Kent Beck, Martin Fowler, and Uncle Bob are some of the more famous names from that list).
They defined four values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
And 12 principles, as described in the image below:
So it’s not about the ceremonies and making them exactly by the book, and if someone is practicing it that way — they’re not practicing Agile.
When you practice agile, you want to:
- Work as a team — define goals and meet them as a team.
- Improve as a team — team processes and individuals’ competence.
Retrospectives — improving as a team
Retros are an opportunity to reflect on the team’s work at a certain cadence, e.g. weekly or bi-weekly. Since we work hybrid, we work in Miro, which allows for a lot of flexibility and fun.
One of my teams uses the same format every time: there are 4 boxes to put notes: stop, start, continue, and kudos. We take 10 minutes to fill in notes, each member has their individual note color, and then each person goes through their notes and explains them. Then we vote on notes to discuss, discuss and make action items.
My other team changes the format every time, taking ideas from funretrospectives.com, but it’s the same stance — we put notes separately, then go through them, and create action items. It’s an opportunity for people to celebrate successes, propose changes — because they own the ways of working of the team — share struggles and have fun.
Planning — defining goals as a team
Our planning goal is to agree on what we aim to achieve as a team in an agreed-upon time frame. We work with one or two-week sprints. During those meetings we create a list of tickets in our ticketing system that the team thinks they will manage to complete during that sprint. We take into account the last sprints’ speed, leaves that people plan to take, etc. If someone has some personal struggles or professional activities outside of the team, they let the team know and the team reduces the capacity planned.
How many tickets to put in
One team uses points. Each point represents half a day of work. The amount of points the team manages to achieve during a sprint is not the number of days multiplied by two — because of meetings and leaves etc. The team guessed the number of points in the first sprint and then iterated over it.
The other team doesn’t use points. They use ticket breakdown, where they make sure every ticket is small enough, and take in the right amount of tickets. Those meetings take half an hour to an hour when the team is well-experienced.
How time-consuming a ticket is
Another prerequisite for successful planning is that the team knows the details about the tickets and understands the product priorities.
To do that we have backlog refinement meetings a few days before the planning, and product or tech discoveries on a need basis. At the beginning of projects we have discovery meetings to make sure everyone on the team understands the scope of the project and the details.
Product discoveries are led by the PMs, they can be a user story mapping, where the PM briefs about the background of the project, and then in pairs members of the team paint the user flow, and then share their point of view. That creates enough background for the designer to work with the PM on finalizing the flow, and the engineers to start tech discovery where they examine technologies or create the system design.
The tickets are created during tech discoveries and some during refinement. At the refinement, we try to prepare the backlog for the next sprint as much as possible so that the planning will be as short as possible.
The product discoveries are contextual because the team knows the mid-term planning — for the next two months or so. They establish the mid-term planning in discoveries and then review it in refinements. It contains high-level tickets (one short sentence each) for the sprints in that period.
Daily Standups — meeting the goals as a team
A few characteristics of our teamwork are: getting code reviews for every piece of code people push. Our teams are co-dependent, so sometimes they get requests in the middle of the sprint from another team and choose to change the plan instead of waiting for future plannings and sprints. The aspiration is that people are able to take on any task on the board.
The goal of the updates during the daily standups is to let other team members know if the team is progressing as expected, or if one of them is needed to support another task due to how challenging it is or personal issues. During standups, the team understands if there are some blockers they can work together to unblock (internal or external), and if they are likely to meet their goal (sometimes it just doesn’t matter, and sometimes not meeting the goal means a change in the planning or the communication needs to be done).
Meetings Facilitators
The meetings are facilitated by a rotating “sprint master”, sometimes different from a “retro master”, or by a scrum master that’s a developer in the team.
Results
The result of this way of working is a team that owns their ways of working and feels good about it, is not dependent on the manager, and feels high responsibility for their delivery and quality. It allows org-level planning and committing to deadlines without working overtime — a real work-life balance.
