Luiz Guilherme bio photo

Luiz Guilherme

Technical Producer

Email Twitter LinkedIn Instagram Github

I just have finished my first sprint as a Scrum Master, and I’m really happy about it. It is a sightly different experience for me. To sum up, as a researcher there are some differences between the software house approach of Scrum and the Researcher one. This article will summarize the Scrum Master role, and point out some of these differences. This is more a personal opinion rather than a general concept.

The other scrum
The other scrum


I’ll not spend time here explaining Scrum in details, there are plenty free articles about it on the web, just google it. To sum up, Scrum is a agile software(but not only) development methodology that follows the agile manifesto. It has a huge impact in companies performance and enable teams to be more self-organizable, encourage collaboration and communication and accept failure as a part of the work.

For more information, visit wikipedia page of Scrum.

Scrum Terms
Common Scrum Terms

The Workflow

In scrum, the development is divided basically in iterations called Sprints. It has 2/4 weeks length and has some artifacts and meetings to be addressed. Initially the Team must bring Stories from a Product Backlog previously created to the Sprint Backlog, and commits to finish all these tasks. The Sprint Backlog is not modified until the end of the Sprint. These Stories are broken down into Tasks that could be atomically done by the Team.

During the Sprint, the Team must communicate daily about the ongoing progress and make progress in these tasks. At the end of each Sprint, an increment to the final product is added.

A Basic Scrum Workflow
A Basic Scrum Workflow

The Meetings

Let’s make a quick overview of the most important meeting in Scrum.


Done in the beginning and every Sprint beginning. The objective of this meeting is address Business Value and Effort to each Story in the Product Backlog. To start a Sprint the Team and the PO must define a Sprint Backlog, that is a subset of prioritized Stories from the Product Backlog that will be developed by the Team during the next Sprint.

Daily Meeting

Done every day for 15 minutes. The main goal is to spread the word about the ongoing process of all tasks the Team is developing, identify any impediments that may be delaying the Tasks and promote communication among the Team members.


Done every end of Sprint. It is the time for the stakeholders to see the progress of the product. The increment must be shown, integrated and well tested at this time. Generally the Team briefly run thru all the Stories, point out the facts that happened during the Sprint, and show a Demo of what has been created in the last weeks. This meeting is focused in the product.


Also one every end of Sprint. The Team brainstorms about “What went well”, “What could be improved” and “Actions for next Sprint”. This helps the team adapt the Scrum process to it needs and make a self-evaluation of the entire work. This meeting is focused on the process.

The Roles

Scrum define 3 important roles to the process. I’ll talk about the first two in a glance, and a little more about the Scrum Master.

The Product Owner

This is the guy who owns the Product Backlog. He has the sensibility and the social skills to extract from all the interested stackeholders what Stories will give bigger value to the product. Also, he must be a ninja in prioritizing tasks.

The Team

These are the guys who pull the sleeves and make great things happen. They are responsible for calculating the Effort of the Stories, and consequently the Return of Value(ROI) of each one, execute the sprint, present the review, and improve the process during the retrospective.

The Scrum Master

Finally the one I’ve been working as. For me, the scrum master is the guy who:

  • Ensure that the methodology is being well applied
  • Solve impediments
  • Make meetings be more objective and powerful to the team
  • Does not manage anyone =)

People often confuse the role of Scrum Master as a Lead or Manager in the team. It can be ( I think its good, but not mandatory ) also a member of the team, helping the development of the project by coding or doing other stuff. Also, people tend to be “powered” by this role. It does not mean that you are superior to anyone, in scrum all the roles and hierarchies presented is supposed to be in the same level. Everyone helps to deliver the project. The Scrum Master must ensure that is is delivered in the best process possible for that team.

Scrum in a Research Environment


This section picture reflects well our first sensation of using scrum in a research environment. I had previous experience using scrum as a developer, but these were essentially coding games. Research has a bunch of differences from a generic software house that must be taken into account.

Adapt to the work

The first one is the higher tend to change the direction of the project during its development. Research is unpredictable, period. One day all your experiments could be point to a promising direction, the other day, with deeper testing and prototyping, you could be entirely wrong ( or had found a one in a million case ). The consequence is that, the project is a living entity that changes all the time ( in goal as well ), and it has a huge impact in the backlog and prioritization. The PO must ensure that, not only the direction chosen is a good one, but also the he has some other cards to play if the promising one fails.

Second, the work process is not totally based on coding. Actually, coding could be only a support of the research. You can do no code at all in some of them. It is totally based on studying, create hypothesis to improve or deliver something and validate it with experiments. The first question our PO addressed in a course was “What is a Research Deliverable in the end of a sprint?” . It could be a Systematic Review, an Article, a Data Analysis, a Testing Report, and other things rather than a functional binary to show. We adapted our reviews to expect these as “increments”

Last but not least, research requires collaboration with many people that are not accessible everyday. In my case, I interact with people from academia like Professors and graduate students, and with people inside of the company like Engineers, Sales, Marketing and so on. Everyone has an important contribution to the research. We had to deal with the possible decrease of communication caused by the distance and partial commitment to the projects. Every team has to improve it as much as it can.

Problems Found

I consider myself a different researcher ( at least in Brazil ) because I always liked to be part of the Academia and also the Industry. Since the very beginning of my Master I work as a Developer/Researcher in parallel. People that comes only from the Academia sometimes misses important things that you only learn (well) in a company. The one I thing is valuable the most is “working process”. Not talking of scrum here, but any working process that companies uses. As a researcher in academia, you generally find one that is suitable for you and use it. In companies, generally you must adapt to the one that the companies culture uses.

In our case, there has been a decision to switch to agile. Some people find it painful, especially the ones that came from a long term in academia. One of the agile principles is to keep the team motivated in the methodology and willing to have a discipline in using it everyday. I found hard to convince sometimes people that they could improve their working process using it ( specially the older ones =) ), but also, it is important to have a different point of view and improve the process from time to time using oldie good stuff.


I’ve been learning a lot the last few months. I think this role improves not only our own capacity of solving problems during a project, but makes me think everyday of how am I doing my work, and what can I do to make things better. This motivation is an excellent fuel to a busy day.

If you came until here, thanks! Love to interact via comments if you like or dislike this article.