This rigid approach left little room for extraordinary innovations. Thus, the customer received exactly what they had defined at the beginning of the project, preferably in a requirements specification. A requirements specification was a long document in which all requirements for the product were detailed. The problem with this approach was that customers often don’t know exactly what specific requirements there are for the applications at the beginning. Some only become clear during the course of development, and existing requirements can also change because better solutions are found or some functionalities are not feasible without compromises.
The revolution came in 2001 with the emergence of the so-called “Agile Manifesto”. A group of 17 project-experienced software developers and innovative thinkers met in a cabin at the Snowbird Ski Resort in the Wasatch Mountains of Utah to find possible alternatives to the previous documentation-heavy and cumbersome development processes. The result – the Manifesto for Agile Software Development – was groundbreaking for the entire IT industry and has not lost its significance to this day. The participants developed twelve principles of agile software development based on four fundamental values:
Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while we value the items on the right, we value the items on the left more.”
Traditional Methods vs. Agile Software Development
According to traditional methods, such as the waterfall model, software projects are divided into individual phases that follow each other chronologically and are ideally processed by different teams. Once one of these phases has been completed, it is very difficult to return to it and make adjustments, as the team is already in a different phase. Due to this structural project setup, blocking problems can quickly lead to bottlenecks and delays, as the completion of one phase is a prerequisite for the start of the next phase.
At the end of a project, there is a single release where the complete product is published. At this point, the end customer usually comes into contact with the product for the first time, as, in contrast to agile approaches, new prototypes cannot be presented iteratively. As a result, possible problems are often discovered far too late, which can lead to higher costs. If you could iteratively show new prototypes to the customer, you could react very quickly if requirements were misunderstood and developed incorrectly.
Traditional methods are suitable for products where the requirements are already clearly defined and structured at the beginning. Furthermore, they also have their strengths in products with high non-functional requirements, such as security, performance, or reliability, as they can be taken into account from the start and thus better planned.
Nevertheless, requirements in today’s practice change very quickly, as enormous technological advances occur in a short time. Agile software development helps to respond to these changing requirements in a timely manner. Accordingly, the projects are divided into short, iterative cycles, focusing on communication, collaboration, and regular feedback. This flexible way of working makes it possible to respond to (market) changes, such as new technologies or trends, and thus ensure high customer satisfaction. A well-known and widespread agile method is SCRUM.
How Does a Project with SCRUM Work?
Agile software development using SCRUM proceeds in well-defined, short, and repetitive phases called sprints. At the beginning of a sprint, teams meet to plan the upcoming phase. The basis for this sprint planning is the prioritized product backlog of the Product Owner. This product backlog typically consists of user stories that describe the product requirements. The team then estimates the effort for these user stories. This can be done, for example, by estimating the time required or through approaches like Planning Poker. After several completed sprints, a team has an average sprint velocity. This indicates how many user stories they can complete on average per sprint. The sprint backlog is then created based on the respective velocity and effort estimates for the individual user stories.
Process Flow According to the SCRUM Method
Efficient communication and collaboration are very important in the SCRUM method, which is why there are daily stand-up meetings. These deliberately short meetings, about 15 minutes, serve to better coordinate the software team with each other. Each developer briefly explains what tasks they completed the previous day, what is planned for the day, and if there are any obstacles or problems that could block their work. If problems arise, the team looks for solutions.
At the end of a phase, a sprint demo takes place. Ideally, there is a test environment that represents the production environment as closely as possible. Team members demonstrate the results of the sprint to each other and to the stakeholders. This gives the SCRUM team immediate feedback and the opportunity to react directly, thus avoiding later adjustments. Otherwise, it could happen that, for example, requirements were misunderstood and valuable time is lost through extensive modifications.
Additionally, there is a sprint retrospective. This review reflects on what went particularly well, where the problems were, and what potential improvements there are for upcoming sprints.
What Roles Need to Be Filled in SCRUM?
The Product Owner focuses mainly on the product. They know the requirements precisely and are accordingly responsible for prioritizing the upcoming tasks. For this, they develop and manage the product backlog, the prioritized collection of all due tasks that were developed together with the customer. Through close collaboration with the team, they ensure that all elements in the backlog are understood by everyone. The Product Owner also decides when the product will be delivered. It is advisable to choose a more frequent delivery frequency.
The SCRUM Master is responsible for the correct execution and implementation of the SCRUM process. They support the team in process optimization by removing possible obstacles and avoiding distractions. To this end, they mediate between the Product Owner, developer team, and company, and take over the planning of the required resources for the respective sprints, stand-up meetings, sprint reviews, and sprint retrospectives.
The actual SCRUM teams consist of the operational software developers. Ideally, they are composed of five to seven members with different areas of expertise that complement each other. They work as much as possible at a common location to ensure efficient communication and collaboration and to work together towards the successful project completion. Through mutual coaching, the risk of bottlenecks and resulting delivery delays is reduced.
What Are the Advantages of SCRUM?
The biggest advantage of the method lies in the flexibility it offers, because product requirements are rarely set in stone. Change requests in SCRUM are not seen as a disturbance, but are integrated into the method. This iterative approach allows requirements to be continuously adjusted to create the best possible product.
By focusing on short sprints, milestones are frequently achieved, making the steady project progress more tangible and thus increasing motivation in the team. This is also promoted by the self-organization and personal responsibility of individual team members.
As stakeholders are involved in the entire development process and provide feedback, the quality of the product and customer satisfaction increase.
Best Practice: SCRUM at digatus
digatus develops software using the agile SCRUM method. Different roles are defined within the team, which take on defined tasks throughout the entire project. Core elements of the method are the time-boxed sprints, which at digatus typically last 1-2 weeks.
For estimating efforts, digatus preferably uses the Planning Poker method. Each developer receives a set of cards that resemble the Fibonacci system (1, 2, 3, 5, 8, …). Every team member estimates the effort for individual user stories and assigns cards accordingly. Afterward, the results are compared. If there are significant deviations, the team discusses the estimation until a common result is reached.
This Sprint Backlog forms the basis for development and the requirements to be implemented during this period. In the cyclical sprint meetings, the planning for the next upcoming phase is realized, as well as the review and acceptance of the previous one. In this way, all stakeholders are continuously informed about the current state of development and, together with the team, ensure compliance with goals, schedule, and budget.
