Learn how to do it right and what big things can happen as a result
“Scrum is an old way of doing work, meant to solve problems of another era. An organization dealing with continuous deployment doesn’t need it. Versions of code aren’t there. Sprint doesn’t make sense. You There are members of a cult with such sacraments that have lost their meaning”.
this tweetInspired by an experienced engineer, I was inspired to share how Scrum has made our teams more successful than any other team I’ve worked with over the past 16 years.
I worked with Scrum in 2011, and then with dailies in 2018. Both times it was not a good experience – no one understood why we did it or the benefits, it felt like we were reporting progress on the dailies to our manager and who put too much stress on work.
Over the past year and a half with CRY, I’ve been practicing it with my teams and learned how to do it right and what great things can happen as a result.
One important thing that I understood while learning about Agile is that Agile is not its rituals. As noted in the recommended book “The Art of Agile Development”, The Agile Manifesto was created by 17 proponents of lightweight methodologies that were created as opposed to waterfall development (Kent Beck, Martin Fowler and Uncle Bob to name a few of the more well-known from that list).
He defined four values:
person and conversation on processes and equipment
working software on comprehensive documentation
customer support contract negotiation
response to change 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 accomplish them as a team.
- Improve as a team – Team processes and the potential of individuals.
Retro is an opportunity to reflect on team work at a certain rhythm, such as weekly or bi-weekly. Since we do hybrid work, we work at Miro, which allows for a lot more 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 out the notes, each member having their own different note color, and then each person looks at their notes and explains them. We then vote on notes to discuss, discuss and create action items.
My other team changes the format each time, taking ideas from funretrospectives.com, but it’s the same stance – we put down notes separately, then go through them, and create action items. It is an opportunity for people to celebrate successes, propose changes – because they own the way team works – share struggles and have fun.
Our planning goal is to agree on a goal to be achieved as a team in an agreed 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 speed of the final sprint, the number of people we plan to take, etc. If someone has some personal conflict or professional activities outside the team, they tell the team and the team reduces the planned capacity.
how many tickets to book
A team uses points. Each point represents half a day’s work. The number of points the team achieves during the sprint is not multiplied by the number of days it takes – due to meetings and leaves etc. The team first estimates the number of points in the sprint and then iterates over it.
The other team does not use the points. They use ticket breakdown, where they make sure each ticket is small enough, and take the correct amount of tickets. Those meetings take half an hour to an hour when the team is well experienced.
how long does the ticket take
Another prerequisite for successful planning is that the team knows the details about tickets and understands the priorities of the product.
To do this we have backlog refinement meetings a few days before planning, and product or technology innovations based on need. At the beginning of projects we have research meetings to make sure everyone on the team understands the scope and details of the project.
Product searches are led by a PM, they can be a user story mapping, where the PM provides information about the background of the project, and then team members in pairs illustrate the user flow, and then share their point of view . This creates sufficient background for the designer to work with the PM on finalizing the flow, and for the engineers to initiate technical exploration where they investigate technologies or create systems designs.
Stamps are created in the course of technical discoveries and some refinements. In refinement, we try to prepare as much backlog as possible for the next sprint so that planning is as short as possible.
Product searches are relevant because the team knows the mid-term plan for the next two months. They establish a medium-term plan in searches and then review it in refinement. This includes high-level tickets (one short sentence each) for the sprint in that period.
Some of the features of our teamwork are: Getting code reviews for every piece of code people push. Our teams are co-dependent, so sometimes they receive a request in the middle of a sprint from the other team and choose to change the plan instead of waiting for future plans and sprints. The aspiration is that people should be able to do any task on board.
The goal of updates during the daily standup is to let other team members know if the team is progressing as expected, or if one of them needs to support another task, how challenging it is or personal issues. Huh. During standup, the team understands that they can work together to unblock (internal or external) if there are some blockers, and if they are likely to accomplish their goal (sometimes it doesn’t matter) and sometimes not meeting the goal means changes need to be made in planning or communication).
Meetings are facilitated by a rotating “Sprint Master”, sometimes distinguished from a “Retro Master”, or by a Scrum Master who is a developer on the team.
The result of this way of working is a team that owns its own ways of doing things and feels good about it, is not dependent on the manager, and feels high responsibility for their delivery and quality. This allows for organization-level planning and committing to deadlines without working overtime – a true work-life balance.