Few topics generate passionate debate in developer circles quite as Scrum does. As smartpatient has grown over the years, a willingness to adapt and constantly evolve our processes has allowed us to utilize Scrum effectively, remaining faithful to agile values while ensuring every member of the team can work to their full potential. We spoke to Android developer, Adam Danielczyk, to get a deeper insight into how we make Scrum truly work for us.

Adam, there’s a lot of debate about Scrum and whether it is a productive framework. How has smartpatient “owned” the Scrum process to make it work?
I think here at smartpatient, we first of all make sure that everyone in the company is on board with our approach to Scrum. So, every new joiner is introduced to the process in their onboarding and we explain how the process works. At the same time, we also try to make sure the process can be adapted to our needs at any time. If we see any possible improvement areas, we try to address them. We also make sure our teams are cross-functional, self-organizing and, most importantly, that every team member should feel as though they have a certain level of responsibility towards the product.

We have sprints that last two weeks and every sprint leads to a releasable increment of the product. We try to release as often as possible, at the moment it’s once a month, and it means that features implemented for our partner products are quickly visible as downloadable applications, either for iOS or Android, which helps give our clients confidence in our platform and in the products we develop for them. It helps keep cooperation healthy.

So, overall, I think Scrum allows us to deliver the best quality product and to adapt to changing requirements in an agile way.

What measures do you take to ensure team members are on the same wavelength and the risk of communication problems is minimal?
Every agreement that is part of our Scrum team and that should lead to a feature being delivered should land in the Definition of Done. So, this Definition of Done should ensure that everyone in our team knows exactly what should be achieved to call our feature done or complete. With the teams being mature and the company growing, we try to refine our DoD and we try to make it as up to date as possible and to meet everyone’s expectations. So, this definition of done specifies a list of requirements to be able to call a user story complete.

Additionally, every product backlog item has acceptance criteria specified, which describes the desired functionality to be implemented and also allows the Scrum team to know, exactly, clients’ expectations.

So, you could say that the acceptance criteria are more granular whereas Definition of Done is more on a macro level. Then, Product Owners are responsible for preparing those criteria, which are later talked about during refinement meetings where those backlog items are estimated.

This clear communication is important, otherwise, you can get problems such as a misunderstood sprint goal which might mean a Scrum team doesn’t deliver the item that is expected by the Product Owner, which is not ideal. Together with a misunderstood sprint goal, there might be misunderstood acceptance criteria, so even if some user stories in the sprint goal are implemented it still might lead to some kind of miscommunication and delivering a different functionality to what was expected. There might be other issues, like underestimated product backlog items, which might just mean we cannot deliver the sprint goal because it’s just not realistic under the time constraints.

All of the above can lead to not meeting the requirements and might mean a feature is not finished on time or it might not be complete.

Thankfully, our Scrum teams are quite mature, so we often avoid communication issues. But we always need to work to make sure this is the case.

You’ve mentioned that our processes need to be adaptable. If team members have ideas for improvements, how do they raise them?
I would say the retrospective meeting would be the perfect place for them. During that meeting we make sure to talk about things that went well but, in particular, we make sure to talk about things that could have gone better. With such meetings, we always look to improve our processes so we can make the best product.

Some people consider Scrum to be ‘unmanaged’. What measures are in place to ensure that productivity is maximized?
First of all, we make sure that teams know that they own the product and that we focus on quality. In our Scrum dailies, we come up with a plan for the day and make sure that everything is on track as initially planned. And once the sprint ends, we present our features during the review to stakeholders to also gather their feedback.

Then, during the retrospective, we look for areas for improvement and for ways to make our future sprints even better. Additionally, during refinements we try to see clients’ vision, we analyze acceptance criteria, we estimate user stories, and we try to make them as achievable as possible. For example, we might break user stories into smaller tasks. I think all of these things lead to maximum effectiveness in our Scrum sprints.

There is, of course, a management team here at smartpatient. What involvement do they have when it comes to product development and issues relating to Scrum?
The management team can best be described as stakeholders in the development process. They are present during reviews and share their feedback.

The management team, though, does not interfere with our sprints and does not interrupt.

I think this is thanks to a large amount of trust in our processes, which has built up over years of improving and refining Scrum within the company. That process involves Product Owners negotiating the priority of product backlog items with management before a sprint.

In turn, this leads to the team being autonomous and free to make decisions on their own.

For example, things like choosing which technology we use to achieve a specific requirement or make any other possible improvements to the feature being implemented.

Earlier you mentioned company growth. How do you adapt your processes to handle this growth?
We’ve had to scale our Scrum processes to meet our growth needs. Even though we still keep a single product backlog, we have integrated several Scrum teams, it’s five teams currently, and every team has their own dedicated Product Owner, who is responsible for outlining user needs and requirements, specifying acceptance criteria, and should be available if the team needs their assistance or advice.

During planning, a team plans for their upcoming sprint using the product backlog, which at that point is already sorted and prioritized by the Product Owners, and those items are assigned to a specific team.

On the topic of growth, how do you make sure new joiners integrate with the teams and the Scrum processes?
During recruitment, we make sure there is a ‘culture fit’ when it comes to the candidate, so we explain our Scrum framework and make sure they are happy with it. Once the candidate joins the company, they go through the onboarding meetings where they are introduced to our processes, where we discuss things like company culture, Scrum meetings, and the tools to manage tasks and documentation.

And, obviously, it’s a chance for the new joiner to learn more about our product and our vision. They’re also introduced to our Definition of Done and the practices we have worked out over the years. To begin with, new joiners just observe our meetings for the first one or two sprints and they are free to ask questions at any time and if they notice any improvement areas, they are free to raise those topics in retrospectives, just like any other team member. This usually means new joiners settle quite quickly into the team.

Given smartpatient’s success with Scrum, why do you think some people are quite opposed to it?
I have previously worked in a Scrum environment where we didn’t have all of the Scrum meetings, which led to problems. For example, we weren’t really able to share our ideas for Scrum improvements because we didn’t have retrospectives, so we couldn’t share our feedback and say if some things weren’t working correctly.

That meant people were frustrated, during sprints they just couldn’t share their opinion. If people have had a negative experience with Scrum, it obviously influences their feelings towards it as a framework.

I think within smartpatient, Scrum works very well because we try to follow the Scrum guide as closely as possible and everybody has a voice and an opportunity to share their ideas. Of course, it is never perfect and there is always room for improvement, which is why we are always open to new ideas.

We are hiring!
Do you want to be a part of a team that has successfully owned the Scrum framework and where your voice can be heard?

• Check out our job ads here.