Agile at Slido

The way we choose our priorities and goals has huge impact on our day-to-day work. With this in mind, we decided to set very simple and clear goals for our engineering team for last fall (Sep-Dec 2017). We wanted to achieve superior up-time of our cloud application, decrease number of known bugs and speed up software roadmap delivery.

Finally, we achieved:

  • An up-time of 100% with 2,500 events weekly and frequent releasing every week
  • A decrease of 30% in the total number of known bugs and 50% in the average weekly number of new bugs
  • A decrease of 40% in the average lead time and 50% in the number of overdue tasks

In this post, I’d like to share how we got to these results, what is behind the numbers and how we work here at Slido engineering team.


To find the perfect development process for us in the current stage, we’re constantly looking for inspiration from various sources. We don’t follow any particular methodology by book, but the main influence is from Agile and Lean values, principles and practices (Scrum, Kanban, xP, TPS and gtd).

Our main goal is to understand our customers’ needs deeply and deliver our product at a speed that keeps users happy, developers energized and the helpdesk calm. We experiment and use practices that make sense for us. This means that sometimes we have to break existing schemas and habits to create new ones.

At the end of the day, we focus on developing in these areas:

  • System awareness and visibility of the value flow
  • Empowered, self-organized and feature oriented teams
  • Continuous improvement and delivery mindset
  • Open trust culture based on courage and ownership


We develop our own products and the ideas behind each new feature come from three typical channels:

  • People from the Customer Success team collect ideas and needs from our customers via direct communication and experience in the field and log it to Receptive
  • We have a dedicated Slack channel where everybody can contribute with their ideas to influence our roadmap
  • The third channel consists of the market expectations and trends we are monitoring

All these inputs are collected and translated into the features by the product management team (PM). They regularly identify the most valuable features and work on the roadmap for the next quarter or adjust the current one by steering to the golden path. As part of the process, they also do bi-weekly UX ideas triages to sort out the most wanted UX improvements.

To have a roadmap for the next quarter ready, PM has to:

  • Identify the things that are not in our current vision or strategy and should be postponed or removed
  • Discover and visualize dependencies or possible bottlenecks which could affect development
  • Group features by teams of developers according to their skills and expertise

The next step is the preparation of backlog and sprints for each team. Usually, we plan 1+ sprint ahead. Team members do backlog grooming, which involves:

  • Understand why we are doing this feature
  • Describe solution with identified constraints and options (specification)
  • Prepare UX/UI sketches, architecture, POC (if necessary) and relative estimates
  • Transform feature into user stories or technical tasks
  • Write down QA acceptance criteria
This is usually creative, iterative and incremental process with a lot of feedback and review sessions to ensure the feature will be done well. In the end, we like to have it specified very simple as: Feature = Sprint = Team.

Feature Teams

Each sprint is planned with the development team for particular feature with a clear delivery at the end. The size of each team (2–4 developers) and sprint length (1–3 weeks) are flexible and we do not measure velocity. Instead, we focus on the seamless feature flow through the development (lead time).

To achieve this, developers are working on planned stories in the sprint as a small team driven by self-discipline. We are trying to enable cross-functional organization with T-shaped people. Therefore, one feature team usually contains backend, frontend or full-stack developers who are able to deliver all necessary code. Virtually also DevOps, UX and QA guys are part of the team, but they currently serve more teams in parallel, not just one.

It is important that people in the team know context and direction; they are aligned and enabled to achieve the sprint goal. The developers in the feature team agree on who will deliver which story. To accomplish a story, they need to work on:

  • Source code
  • Unit tests
  • Integrations tests
  • Code review
  • CI configuration
  • Application artifacts deployment scripts
  • Database upgrade/migration scripts
Team members have full ownership and responsibility to deliver it to the production in the best way they can, and we prefer flexibility over local efficiency.

They cooperate with the PM, UX and QA teams to make sure that they develop according to the specification. Devops guys help them to automate and prepare infrastructure, which enables easy and fast development and deployment. If an issue is not solvable by the team directly, they quickly escalate to the PM, who is responsible for the coordination of the appropriate action.

Feature teams are vertically oriented to deliver particular feature end-to-end (E2E), but there is also a horizontal aspect to our teams: module expertise. Each module has an architect or lead developer who is responsible to develop skills, minimal standards, and simple ground rules and control technical debt. This creates necessary standardization and alignment even when a developed feature goes across multiple modules.


All developers strictly follow Gitflow Workflow, so each feature has its own feature branch. Every commit is automatically integrated and tested by CI platforms (Bitbucket Pipelines, Codeship). The team communicates about actual progress and impediments on daily syncs. There are also scrum of scrums style syncs where dedicated guys discuss topics on an inter-team level. When a story/task is ready, it’s merged into the development branch, which is automatically deployed on staging. There, it’s available for testing and internal demo purposes.

When a whole feature or some releasable part is done, it must pass QA gate:

  • Functional tests
  • Exploratory tests
  • Feature feedback sessions
  • Bugathons
  • Automated regression tests
  • Static code analysis
  • Security analysis

When QA gives the green light, the release branch is created and code is merged into a master branch with an appropriate changelog. By this time, E2E test automation is being developed by the QA team. Pre-production is automatically updated in a way similar to staging and we execute tests against production DB. If tests are okay, the code goes into production. This is the last step of our definition of done and we can close the sprint.

Release to the production can be done only for some subset of customers aka canary style (e.g. only for new customers) or for everyone using blue-green deploy to avoid downtimes.

Release notes are communicated by the Customer Success team. Feedback and usage is measured via analytics tools (Google Analytics, Exponea) and value expectations are analyzed by our Growth team.

If Something Goes Wrong

The staging and production systems are deployed on AWS by the Devops team using AWS OpsWorks (infrastructure as code) and monitored via various tools (CloudWatch, New Relic). In case of any issue, a new alert is triggered into the dedicated Slack channel. If we are in serious trouble, PagerDuty will ring on our phones to ask for immediate action.

Some issues are still not detected by us, and our customers may run into buggy operation or strange errors. In such cases, they usually contact our helpline. If it is a real bug and it is not known yet, the QA team takes care to create it in Jira and the PM makes a decision on when it will be fixed at the weekly bugs triage session. If there is a higher number of bugs reported or negative feedbacks received, we’ll plan a short cleaning sprint (3–5 days) in order to fix them.

In urgent cases, a hotfix is delivered ASAP within an hour or workaround is suggested to help quickly.

Make It Better Every Day

We know we’re not perfect and that’s why we meet every two weeks for the Retrospective to identify:

  • What we did well and we should keep doing
  • What was not so cool and needs to be improved
  • What did not add any value and should be removed
  • What we learned and should help us in the future

This is not a simple task and therefore, each team member is responsible and empowered to take care of improvements he/she can bring in. Making things better and identifying the root cause of problems or various bottlenecks is a difficult process, which involves a lot of experimenting and, of course, mistakes and failures.

We know that we have to fail and learn very quickly and also be able to confirm learning by short iterations and feedback loops to feel our progress and accomplishments. Therefore, everyone on Retrospective can talk very openly, with respect and safety.

We use Slido to collect ideas before the meeting and we review and discuss them together, so yes, we eat our own dog food. We always try to find out simple and smart solutions or at least one next possible step. We do not hide our troubles, but in hard times we keep the motivation and belief that we are running a winning race.


Our business is growing very quickly and we have to face all the typical challenges connected with it:

  • Scalability, Performance & Usability: infrastructure scaling, monitoring & testing, standardization, maintaining of tech debt & refactoring, UX improvements, increasing speed of feature/value delivery loop with higher quality, data enabled decisions
  • Organization & Culture: growing the team, personal learning, just-in-time information radiation & alignment, balancing chaos vs. bureaucracy, processes vs. good habits, avoiding cargo cult effect
There is no silver bullet or sorcerer’s stone that solves everything by magic. It is just hard work we have to do to make our history.

It All Comes Down to the People

The whole product is done by the great people who are Slido’s most valuable asset and who have a nice and open culture. We only look for people who fit into our culture and share similar values.

We use a lot of tools and procedures that help us to be organized, productive and make good decisions. Still, in some cases, we rely on intuition or gut feeling. That’s why people are the key to our success and we put in extra effort to have the right ones at Slido.

Do you see yourself fitting right in? Send us your work examples or CV and we’d be happy to talk about the opportunities here at Slido.