July 05, 2023
Get in touch
The world of software development has undergone significant changes in recent years. For a long time, software development projects were carried out according to a predetermined plan, with each phase meticulously planned and documented ("waterfall principle"). However, for some time now, a different approach has been established: agile software development.
What is the secret behind the success of agile software development? Quite simply: flexibility and collaboration. Instead of following rigid plans and inflexible processes, agile teams adopt an iterative and incremental approach. Development occurs in short cycles, known as sprints, where the team continuously works on a functioning product. Scrum, Kanban, and other agile methods have proven to be highly effective in optimizing the development process. The team self-organizes, establishes priorities, and works in short, focused sprints. This dynamic approach enables problems to be identified and resolved more quickly.
A crucial aspect of agile software development is the close collaboration between developers, customers, and other stakeholders. Instead of working in isolation, team members regularly exchange ideas, share their experiences, and ensure that the end product meets expectations. Through continuous communication and feedback, changes can be implemented quickly, resulting in better outcomes and higher customer satisfaction.
The communication among individuals involved in the software development process is crucial for successful collaboration. Clear distribution of responsibilities and tasks within the team is essential for a smooth workflow. In the context of agile software development, such as Scrum, the various roles play a significant role. Only when these roles work hand in hand can a good and valuable product be created for the customer.
If you have always wanted to know what the everyday work life looks like in an agile Scrum team, we will take you on an exemplary journey through the daily routines of different Scrum roles at AOE GmbH. Melanie, Scrum Master, will start things off:
Melanie Tuppi works as a Scrum Master at AOE. After her studies in Industrial and Organizational Psychology, she gained her first experience with Scrum teams and agile projects during her time as a change consultant at a management consulting firm and in change management at a logistics service provider. Since 2019, she has been supporting both experienced and new Scrum teams at AOE.
..together with the product owner, I take a look at the backlog. We review the stories that he or she has planned for the next refinement: are all the information included, is the description clear and detailed enough, are the acceptance criteria sufficiently described. If I notice any gaps, I address them.
During the backlog refinement, I support the product owner in conducting the meeting. The typical flow is as follows: The product owner presents the first story, and the team asks questions about it. Once all questions are clarified, the team estimates the size of the story using point cards (Scrum Poker or Planning Poker). On 'three,' everyone simultaneously reveals the point card they have chosen, so that no one knows what others will estimate. The goal is not to precisely define whether the implementation of a story will take four or five days, but rather to determine whether the effort and complexity are greater or lesser than that of a reference story. Estimation is useful for the product owner to better plan upcoming sprints and have an idea of how many stories can be completed in the future sprints. Additionally, the collective estimation encourages discussions within the team. For example, one developer might think the story is only worth three points, while another developer estimates the same story as thirteen points. In such cases, I usually ask specific questions and encourage the lowest estimator to discuss the story's content with the highest estimator in the team. The others listen first. This often brings misunderstandings or different perspectives on possible approaches to light.
Sometimes I intervene in the discussion, for example, when the team gets lost in details, loses sight of the story, or deviates from the technical level. Sometimes it also happens that the story is simply too extensive and therefore difficult to estimate; perhaps the story contains too many different tasks, and one outcome of the discussion is that the product owner splits it into multiple smaller stories for the next refinement, to be estimated again. After the discussion, estimation is done again until the team reaches a consensus and can agree on a point value. During this process, the description of the story becomes more and more concrete. I enjoy working with Scrum Poker, as this method also encourages quieter team members to participate in the discussion.
The estimates of the stories from the refinement are a prerequisite for the Product Owner to be able to plan the next sprint. If a team has already gone through multiple sprints together, we have an approximate idea of how many story points the team can deliver on average during a sprint. To make a more accurate statement about the velocity for the next sprint, I check if anyone has vacation, trainings, holidays, or other events scheduled. I take these factors into account when calculating the velocity. This way, the Product Owner can better estimate which user stories should be included in the next sprint.
To be able to assemble a good set of user stories, a lot of preparation is necessary. Together, we check if all stories in the current sprint will be completed or if there are so-called "carry-overs" – stories that cannot be completed and therefore spill over into the next sprint. I also make sure that only "completed" stories are included in the planning of the upcoming sprint. Stories with very little information, those that have not been estimated by the team yet, or dependencies that are still unclear, etc., cannot be considered in the upcoming sprint.
In sprint planning, the Product Owner introduces the stories that the developers should implement in the upcoming sprint. The Product Owner decides what will be done, while the developers decide how to implement the stories. During the sprint planning, I pay attention to keeping track of the velocity. If the development team agrees with the planning, they commit to implementing the plan accordingly. If there are any concerns, we try to resolve them. Usually, this happens quickly, but it can also happen that we make changes and move user stories at this stage. I ensure that concerns from everyone are taken seriously and not simply overlooked.
Once the sprint planning is finalized, the development team takes over. In the second part of the sprint planning (task breakdown), the development team creates tasks for each user story. I often stay in this meeting to follow the discussion and find out if there are any questions or issues that arise. Since we are still at the beginning of the sprint, we can clarify open questions without affecting the sprint's outcome. If we discover problems later in the sprint, it may result in unfinished user stories, so concentration is important in this regard.
The Daily belongs to the development team. The team coordinates and decides which tasks they want to accomplish today. It is also about uncovering and resolving possible obstacles, issues, or uncertainties. I always participate in the Daily and go through the sprint board together with the team. It is the first meeting for the entire team of the day, and I become aware of any difficulties that may arise, allowing me to offer my support and promptly remove any obstacles.
In my team, a sprint lasts two weeks. The team is engaged in implementing user stories. Meanwhile, the product owner is already preparing for the upcoming sprint. He or she gathers missing information and new requirements from stakeholders. I support him or her, especially when it comes to establishing work processes. In general, I operate on three levels.
In the sprint review, the team presents the implemented stories to the stakeholders and showcases the results. The feedback from the stakeholders plays a significant role. Their comments, change requests, or suggestions are incorporated into the backlog and become new user stories. Typically, I am only an observer in this meeting, but sometimes I intervene as a moderator, for example, when I feel that the discussion is going off track or the content becomes too technical, etc.
In the retrospective, I review the last sprint together with the team. To lighten the mood, I usually start with a short icebreaker related to the last sprint, so that we can start a conversation about what has happened in the past two weeks. For example, I ask the team to paint the last sprint or conduct a mood survey. If a new team member joins, I sometimes organize a kind of "speed dating" activity. Depending on the team's situation, I create a suitable framework for the retrospective. I facilitate the meeting, but I usually let the team decide which topics they want to discuss. We discuss whether our current processes still align with the requirements and try to identify improvement opportunities and implement them if necessary. If the team is larger, we usually need to conduct a voting and prioritization after collecting the topics, as we cannot cover all topics in a single retrospective. Depending on the problem situation, I may also suggest a retrospective theme, such as our estimation approach or a revision of the Definition of Done.
The goal is to give the team the opportunity to reflect on the work done in the last sprint and collectively develop improvements. Therefore, it is important for me to formulate specific to-dos, known as action points. These action points are implemented in the upcoming sprint and reviewed again in the next retrospective to assess whether the desired improvements have been achieved.
