Get in touch
The world of software development has undergone significant changes in recent years. For a long time, projects in software development 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.
Have you ever wanted to know what the daily work routine looks like in an agile Scrum team? We will take you on an exemplary journey into the everyday lives of the various Scrum roles at AOE GmbH. Today, Dominic, a frontend developer at AOE, will take you through his daily routine.
Once a week, I have 'Refinement' scheduled in my calendar. Here, the Product Owner introduces new requirements in the form of User Stories. My task is to question whether the feature described in the story actually solves the original problem – and to do so as cleanly and maintainably as possible. In the discussion with my team and primarily with the Product Owner, I address usual questions such as: Have edge cases been overlooked? Are there technical limitations that could be important for the estimation? Are there dependencies on other teams or microservices that we need to consider? In addition, as a Frontend Developer, my job is to closely examine the design (assuming there is already a dedicated design for the feature). I pay attention to common UX design 'rules' and discuss with the other frontend developers in my team what we need to particularly focus on in terms of Accessibility. Once all these questions are answered (and no new ones have arisen), I estimate the effort of the story in so-called 'Story Points' with my team.
In the Daily Scrum a.k.a. Daily Stand-up a.k.a. Daily Sit-down (Homeoffice for the win), I briefly discuss my current tasks with my team. This is not a control meeting for the client who wants to see that I am quickly processing my tickets. For me, it's an opportunity to inform my team about what I am specifically working on, what is going well, what is not going well, and from whom I might need help to complete my task. Ideally, this doesn't take long, but it helps me and my team members enormously, as we can exchange information easily. Especially now, when the team is mainly working remotely, the Daily is perhaps the most important meeting for me.
I would like to write: 'Thanks to our in-depth problem analysis in the Refinement, we can plan the upcoming sprint quickly and easily.' However, the reality is often that by the time of the Planning, I have forgotten half of the content of the story. Thankfully, the Product Owner has meticulously documented everything discussed in the Refinement in the story description. Ideally, it only takes a brief overview of the story and then we can decide whether we can implement it in the upcoming sprint or not. It's important for this decision that as many questions and uncertainties as possible are resolved. The more certain I am about the scope (content) of the story, the easier it is for me to break it down into small tasks (subtasks). At the end of the Planning, we then have a list of stories (with tasks) that we as a team can commit to, meaning that the team says: We can work through this list in the coming two weeks.
During the sprint, I work through the board from top to bottom. This means that the stories with the highest priority are addressed first. However, depending on the complexity of the story, it doesn't just stop at plain 'coding – testing – done.' The more dependencies there are, for example, to our own backend, to other microservices of our team, or even to other teams, the more important it is to communicate. In my opinion, pair programming is almost always a good idea, regardless of the complexity of the task. Four eyes see better than two, especially when those two eyes have been reading the same three files all day. Alongside programming, code reviewing, and testing, continuing personal development should not be neglected. Even though I think that the best learning comes from working on tasks, it doesn't hurt to use free minutes and hours in the sprint to expand one's professional horizon through podcasts, articles, or workshops. After all, who knows what challenges the next sprint will bring?
In the Review, I present to the client the features that were developed in the last sprint by my team and me. To do this, I usually guide the client through the application and show 'hidden' features, such as navigation through a form using the keyboard, or how the screen reader interprets the page. If it hasn't happened during the sprint, we gather valuable feedback here. Sometimes new ideas emerge during the presentation, which we can take as requirements.
At the end of the sprint, the whole team gathers for the 'Retro' and reflects once again on the past two weeks. We look at our work, our collaboration, what went well and what didn't – with the goal of working together more efficiently and effectively in the next sprint. Here, I not only have the opportunity to freely bring up things that may have been overlooked in the daily work routine, but also to give kudos to others if the collaboration was not only very productive, but also really enjoyable. #goodvibes
