How do we use Scrum at GuestReady

Josef Nevoral
Sep 5, 2018 · 6 min read

For a long time, I was against a small team in a startup in Scrum methodology. I was always a fan of Kanban. The idea of having a prioritised list of tasks and simply take the first one on top appeals to me. As a developer, I like the simplicity of answering the question “What should I work on next?”.

My reluctance with Scrum came from my time in HotelQuickly, where we tried to run scrum teams and failed. Since then I thought scrum does not work. I was blaming the system, instead of looking at the situation, established processes and type of work we were doing. Obviously, there is nothing wrong with Scrum, our implementation of it was flawed.

It took me about 3 years to give Scrum another chance. To my surprise, I now have a very positive experience. I guess I learned something in those 3 years.

Problems with Scrum

In HotelQuickly, we faced the following problems:

  • We never came close to finishing tasks we said we will do in a sprint
  • We have been running 2 weeks sprints and it was typically relaxed the first week and rushed the second week
  • There was a lot of unexpected work disrupting the planned sprint
  • We were not working on a single project. Every individual was working on some different part of the system and there was not much relation between the team members work
  • There was none or very little planning with the team, it was mostly taking tasks from the backlog into a sprint. Planning was done by managers before sprints, without a say by the development team
  • Estimations by story points were not done by the team, but by managers

In retrospective, some of those problems are quite obvious mistakes in our implementation of Scrum. Based on the problems I have created a narrative for myself: “Scrum is not the right tool for my team”. It took me 3 years to change this narrative in my head.

In GuestReady, I was thinking about how we could improve our development process and I have decided to give Scrum another shot.

Problems with Kanban

In GuestReady, we were using Kanban, but we were facing several problems:

  • Preparation and planning process was not well structured. The pipeline was not clear and always changing. It was hard to answer a question like “When xyz feature could be worked on and delivered”
  • Collaboration between frontend and backend developers was not well facilitated. Both were having own tickets, there were not enough touch points between the groups.
  • There was no discussion about work in progress. There were no adjustments done during implementation. For example, a task that should take 1 week, took 2 weeks. After 2 weeks I learned, that a developer developed an unnecessarily complex solution. This could have been prevented if we would discuss the solution sooner.
  • Peer review on problems encountered during work. For example, a developer spent the whole day on figuring out a solution for a nice-to-have requirement. If I would know it will take so long to develop that specific requirement, I would drop it.

All the above issues were solvable by continuing using Kanban, I don’t think the problem is in the methodology itself. We simply haven’t established good processes to support effective work. There were 2 possible ways how to continue. Work on improving how we use Kanban to mitigate the issues mentioned above or try something else. I have decided to give a shot to run the projects in Scrum.

Implementing Scrum

The biggest worry about working in Scrum was repeating the same mistakes I described earlier. To mitigate the possibility of failing, I have established the following rules:

  • We will create a Scrum team per project. The team should be focused on the single project and have no other responsibilities
  • We will do detailed project kick-off going through all business requirements with the whole team
  • We will create tasks together and discuss each task technical details and implementation with the team
  • We will have weekly sprints to establish fast feedback cycle
  • The team will be doing all estimations

We had kicked-off two projects running on Scrum at once. One had seven people (Scrum master, product owner, designer, two frontend and two backend developers). The second team having only three team members (scrum master, backend and mobile developer).

I wanted to compare running larger and smaller team on Scrum and see if there are clear benefits of running Scrum for the larger team (that was my assumption).

Process

Our product development process has several stages:

  • Project proposal and business specification
  • Research & Interviews with users
  • Wire-framing, validations, design
  • Development
  • Alpha and beta testing
  • Release and integration to business processes

Stages #1 and #2 are pre-requisites to start a project and we work on them separately from Scrum sprints. The development team starts to be briefed during Wire-framing, validations and design. We have found out, that having feedback from developers this early helps the design team to deliver output and for developers to have a deep understanding of the project.

The length of the sprint was set to one week with possibility to extend to two weeks later. I wanted to have a fast feedback loop and have the retrospectives often to adjust to anything that was not working.

Project preparation

Before kicking-off the project development, we have two preparation meetings:

  • Project briefing from Product owner and an introduction of Scrum process by Scrum master
  • Technical analysis

The purpose of the project briefing is to make sure everyone on the team understands the context of the project. How does it fit into the overall product? How will it benefit our customers? The product owner is responsible for breaking down the projects to stories, which serve as acceptance criteria.

Technical analysis is where we go into details of business requirements, designs and break down tasks. We discuss API design, API authentication and format of requests, architecture in the backend and so on. The target of this meeting goes through all the stories and break them down to technical tasks. We discuss every task so that it is clear for everyone on the team how we will implement it.

For estimations, we use story points and technique called Planning Poker. In planning poker, every team member selects a number of story points based on his understanding of task complexity. We choose from numbers 0, 1, 2, 3, 5, 8, 13. Nothing should be more complex than 13, that would indicate too big a task. There is always a discussion about the task, to make sure everyone understands it. Then we write our estimations, discuss any differences and come up with the final number.

The discussion based on different estimations is the most valuable. When somebody puts 2 and somebody else 5, it means people are not on the same level of understanding. Maybe the person with 2 story-points did not foresee all the necessary changes. Maybe the person with 5 story-points overcomplicates implementation. The following discussion clarifies all these aspects. *Never do the estimations in an asynchronous way!*

Meetings

We have 2 standard meetings during a sprint. Every day, we have a standup meeting. It should not last more than 15 minutes. We give a quick update on our work and discuss any issues or questions.

The second meeting is a Retrospective and planning meeting. It takes one hour and we have it once at the beginning of the sprint. I was thinking if we should have 2 meetings. Planning for the next sprint at the end of the current sprint. The retrospective of the last sprint at the beginning of the current sprint.

In the end, we decided to have only a single meeting where we do both retrospective and planning. It happened only a few times when we needed more than one hour, so it works for us.

Conclusion

After running projects with Scrum for several weeks, I am satisfied with the results. It brought more clarity into day to day. We communicate better, we waste time less. There still are some issue, that we need to work on. For example, we don’t do demos of every week work, which I think could be useful. There could be more discussion on retrospectives.

We still use Kanban for operations (our name for bug-fixing, small adjustments, etc). In a next article, I will write my thoughts about choosing Kanban or Scrum.

Josef Nevoral
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade