Agile development methods such as Scrum and Kanban have already existed for several decades and have proven themselves in practice. In this blog post, we explain how this came about and how the mindset differs from classic development processes. We also show where Scrum and Kanban can be used and how Continuous Delivery is the key to success in agile project delivery.
A little history
The waterfall model is one of the first software development methods and appears as early as 1970 in a document by Dr. Winston W. Royce, even though the word "waterfall" is only mentioned later in this context. The model was conceived for the development of large software systems and defines several phases, which are worked off successively. If an error occurs in one phase, it is necessary to return to the step that caused the error. Dr. Winston W. Royce recognized even then that this was a problem and wrote, "In effect the development process has returned to the origin and one can expect up to a 100% overrun in schedule and/or costs."
Agile development attempts to solve precisely this problem by reducing the risk and impact of errors through smaller iterations. The term "agile" was first mentioned in the context of software development in 2001 in the "Manifesto for Agile Software Development", although iterative process models were used earlier. The manifesto emphasizes the importance of delivering working software in short iterations, continuous customer feedback, and encouraging collaborative, self-organized teams. Different priorities are set.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
New is always better! Or is it?
The waterfall model is still widely used today. The transition from classic process models to agile methods requires a change in mindset and organizational structure. In addition, there are various factors that require a classic sequential approach. This can be the case, for example, if all requirements are clearly defined at the start of the project or if regulatory requirements necessitate this.
The iron triangle
The iron triangle clearly shows the differences in mindset between classic and agile methods. It represents the mutual relationships between scope, time and costs in a project.
In a waterfall model, the scope is usually predetermined. However, it is difficult to determine the cost or delivery date in advance. In agile development, on the other hand, the cost and iteration are predetermined timeframes. However, the scope can be variable.
However, the iron triangle also has its pitfalls. For example, the impression can arise that more resources automatically lead to more scope or shorter development times. However, the effects are not always linear and can even be negative.
It is also an illusion to believe that all three factors can be controlled. As a rule, a maximum of two factors can be influenced, the third remains variable.
Hybrid models
There are also hybrid approaches that combine the classic process model with agile methods. On the one hand, there are models that define higher-level processes, such as the Scaled Agile Framework (SAFe). On the other hand, there are methods that integrate the phases of the waterfall model into the individual iterations or define additional milestones for several iterations.
Basically, the process models and methods are frameworks that can be adapted to your own needs. In doing so, the principles of the respective development method must not be violated.
Agile Methods
Scrum and Kanban are the most widely used agile methods. We show how they are structured and what advantages and disadvantages they have.
Scrum
Scrum is an agile framework for software development that promotes collaboration in a self-organized team and defines fixed roles and time frames.
Rollen
The Product Owner is "the voice of the customer" and is responsible for the Product Backlog as well as for clarification with stakeholders and prioritization of tasks.
The Scrum Master is responsible for the correct execution of Scrum as a "servant leader". He supports the team in problem solving and removes possible obstacles.
The team is responsible for assigning and performing tasks and delivering the product increment at the end of each sprint.
Sprints
Projects are organized in sprints of 1 to 6 weeks. At the end of each sprint there is a potentially deliverable product increment.
Backlog
The "Product Backlog" is a collection of requirements, functionalities, improvements and bug fixes that are managed and prioritized by the Product Owner.
Meetings
Sprint planning is carried out at the beginning of each iteration. In this process, the team records the tasks from the product backlog that are to be implemented in the current sprint.
During the Sprint, the Daily Scrum takes place daily, where the team shares progress, challenges, and the plan for the current day.
At the end of each sprint, the development team presents the completed product increment to the product owner and the stakeholders in the sprint review.
After the Sprint Review, the Retrospective takes place, in which the development team defines suggestions for improvement for the next iteration together with the Scrum Master.
Time boxing is very important in all meetings. Each meeting has a fixed time frame that must not be exceeded.
Kanban
Kanban is an agile project management method that strives for continuous delivery. There are no fixed structures or iterations. Instead, new work packages are tackled as soon as capacities become free. This makes it possible to see at any time where work packages are in the development process and whether they are blocked. A task should be processed and delivered as quickly as possible to keep the "work in progress" as low as possible.
Board
The Kanban board visualizes the entire workflow and divides it into individual phases. The phases can be chosen freely. The first phase usually contains the tasks that still need to be completed. The work packages move from left to right across the board until they are completed. For each phase, quality standards can be defined that must be met.
WIP (Work in Progress)
Kanban pursues the goal of completing work packages that have been started as quickly as possible in order to ensure a continuous flow of work. Therefore, a maximum number of work packages is defined for each phase, which may not be exceeded. This prevents the team from being overloaded and new work being started without the existing ones being completed.
Scrum vs. Kanban
It is always easier to start new tasks than to complete existing ones. This is precisely why it is important with Kanban to limit the "work in progress". With Scrum, this problem exists less, because tasks are usually completed at the end of the Sprint, even if this is not always the case in reality.
The end of the sprint is therefore often a stressful phase for the Scrum team, in which the work must still be completed in order to get to the increment. This stress factor occurs rather less with Kanban and should also be kept in mind with Scrum.
Unforeseen work is prioritized, processed and delivered in Kanban. With Scrum, this process is made more difficult because the next iteration must be waited for in order to schedule the work package. To get around this, the Sprint Backlog can be adjusted in consultation with the team and a work package can be exchanged. This approach should not become a habit.
Kanban does not define fixed roles and meetings. Instead, the existing organizational structure is maintained. For certain teams, structured specifications or fixed time windows can be helpful to meet deadlines and ensure the plannability of the individual work packages.
More agility with Continuous Delivery
The agile manifesto emphasizes continuous customer feedback and delivery in short iterations to minimize risk and impact.
Continuous delivery of work packages is especially favored by Kanban. The feedback loop can be reduced to a minimum in this case. Continuous delivery is also possible with Scrum. In some cases, however, the product increment is considered a deliverable object and is only delivered at the end of the iteration, which contradicts the principles of Continuous Delivery.
Software delivery is largely automated through Continuous Delivery to speed up the process.
Changes to the source code are integrated into the main branch several times a day (continuous integration).
Tests and quality gates are automatically executed during each integration (Continuous Integration).
Deployment is automated into a production-like environment (continuous delivery).
Conclusion
Agile methods offer decisive advantages over classic development methods. Nevertheless, there are projects for which a classic approach is recommended. The advantages and disadvantages must be weighed up individually for each project.
Scrum offers a structured approach with fixed time frames, roles and meetings. The predefined structures can be valuable, especially for larger projects, as they increase the ability to plan.
Kanban uses existing organizational structures and offers more flexibility. However, it does not provide additional incentives for the team to complete their work within certain deadlines.
An important part of agile development is continuous delivery and customer feedback. Therefore, special attention should be paid to the automated integration and deployment of changes.