Agile processes in software development
When we start a new project, many things need to be clarified in advance between customers, users, project managers, and software developers. To ensure that all project managers and developers share the same understanding of the finished product as the customer, good project management is essential for everyone involved. At AMCON, we work with the Scrum model in project execution and today we’d like to give you an insight into how it works in practice.
The Art of Constructively Thinking Past Each Other
This image might be familiar. Question: How do we get the elephant into the refrigerator? Some say: “Open the door, put the elephant in, close the door.” But is it really that simple if we don’t know the size of the elephant and the refrigerator, or what else might already be inside? The conditions aren’t clear. The same goes for the requirements, which in this case are also undefined. After all, we don’t know in what state we’re supposed to put the elephant into the fridge — whole, in pieces, or pureed? So there are several open questions both regarding the requirements and the approach. What seems like a simple task turns out to be complex, and everyone would tackle it differently. Whether the result matches what the task-giver expects is doubtful.
Agile Teamwork – What is Scrum and How Does It Work?
Translated from English, the term Scrum means a “huddle” or “crowd.” This image fits well because the purpose of this agile software development method is for teams to come together daily (figuratively “crowd together”) to talk briefly and in a structured way about the progress of the project. In Corona times, of course, this all happens via video chats. The method was developed in Japan in 1990 and strengthens the role of each individual in a team. This is also very important for project managers, who are no longer just communicators of requirements but are directly involved in the development process. By the way, we call it SCRUMCON, a coined term from Scrum and AMCON. Since every company working with this method sets its own rules tailored to its needs, having its own name is allowed 😉. For us, working with SCRUMCON is effective when project requirements are complex and can be broken down into many smaller parts that can be worked on step-by-step. Different roles are assigned in the process. The Product Owner defines the user stories from the customer’s perspective. In our case, this role is taken by the project manager, who defines the requirements with the customers beforehand and then communicates them to the team. The more precisely the Product Owner describes the user stories, the more precisely the developers can code. This way, the customer ends up with exactly the product they requested.
Backlog Grooming, Planning, and Velocities – Let’s Briefly Explain
In this first phase (called Backlog Grooming), the development team can ask questions so that everyone ends up on the same page. Next, the development team and Scrum Master together define the Definition of Ready (DoR). This means setting the acceptance criteria for the UFHO system, scheduling development steps, and establishing a working agreement between project manager, product owner, and the development team. The Scrum Master organizes task distribution within the team and supports the team. In our case, this is done by the product owner. They also handle proper planning (Planning), taking into account vacations, time for bug fixing, and Velocities. Here, velocity refers to the historical performance of the team. If the team managed an average of 70 story points in the last three sprints, that value is used as a reference during planning. Expecting 150 points in the next sprint would be unrealistic. During Planning, the team estimates each user story with story points. A story point does not correspond to a fixed amount of time but expresses complexity. This is advantageous because experienced developers can accomplish more in less time than beginners. The complexity is estimated using a general scale based on Fibonacci numbers.
Without the Development Teams, Nothing Works
The largest and most important group is the development team itself, also called the Dev Team. Members of the Dev Team are responsible for individual development steps of the UFHO system for our customers. Throughout the process, besides the short daily meetings (Daily), there are regular larger meetings to intensively discuss, test, and suggest improvements on parts of the project. Everyone participates, and hierarchy doesn’t matter. For the Definition of Done (DoD), the team decides when a requirement is finished. A Pull Request (in version control, the process of merging code from a branch into the main codebase) is only created once everything planned for that step is completed. The DoR and DoD are agreed upon once for the Dev Team and serve as a working agreement between the Dev Team and the requester. This ensures the Dev Team receives high-quality requirements matching their standards, and the requester only gets tested, finished features that meet their quality criteria.
What opportunities does SCRUMCON offer?
As with any agile methodology, we have developed the best and most practical approach for ourselves. With SCRUMCON, we increase productivity, optimize communication—both internally within the team and externally with the customer—enhance flexibility, and improve the quality of our products. At the same time, we promote understanding between the different departments involved in a project. At the end of a project, the retrospective is an important step to continuously improve processes. Once a sprint is completed, we all come together to reflect: What went well? What could be done differently? Where is there potential for improvement? Everyone has the opportunity to give open feedback. Our Head of Development Sebastian Schnieder, Technical Project Manager Alex Stasewitsch, and Training Manager Rolf Norrenbrock introduced the agile working method to our company. “Scrum is based on highly qualified, interdisciplinary teams that receive clear goals but work independently on implementation. This autonomous work increases the satisfaction of individual team members — and we observe this very clearly at our company,” says Rolf Norrenbrock.