There are many different, purpose-oriented development processes and methods, which are differently suited depending on the application and the type of object to be developed, whether it is hardware or software. Following we will give an overview of the methods commonly used today. We have already applied all of the following methods in our consulting work with customers. Agile methods are also suitable for other application areas not just development processes.
V-Model
Originally designed for software development, the V-model is similar to the waterfall model in terms of the phases that are formed. In addition to the development phases, the V-Modell also defines test phases, which represent quality assurance, since they compare the individual development phases with corresponding test processes. Usually, a functional specification is started on the left-hand side, which is hereinafter further detailed and technically specified. At the bottom of the model the implementation is started, so that each development level can be completed with the corresponding tests on the right side of the V. Thus, development phases are directly compared to test phases in V-form. One of the largest application areas of the V-Modell is still the automotive industry.
Kanban
Kanban (‘signboard’ [kan ‘sign’ or ‘signal’, ban ‘board’ or ‘card’]) is a method that combines the following core practices in addition to the known cards:
- Visualization of the workflow
Necessary process steps are displayed on a (Kanban) board. More precisely, the chain of value creation or the flow of work is represented as columns within the board. Individual tasks are recorded on (file) cards – often also as sticky notes – and organized in the columns as work packages. Over time, the tasks (also called tickets in the context of Kanban) move from left to right through the columns or process steps on the Kanban board. - Limiting the work in progress
Within a column the number of tickets (whichare being worked on the same time) is limited. This limits the amount of tickets in progress (in the context of Kanban WiP also ‘work in progress’). This system has two advantages; firstly, a “pull principle” is created so that each station has to pick up the work from the previous one. Secondly, this procedure prevents subsequent stations from being overwhelmed with work. It also makes it possible to detect possible bottlenecks. - Measurement and control of the workflow
Key Performance Indicators (KPI) are defined for the identification of bottlenecks. For example, to measure queue lengths, cycle time or throughput to determine how well the work is organized. This helps to identify where the flow of work shows weaknesses, where there is room for improvement and what assurances can be made to the partners for whom you work. In addition to reliability, this also improves planning security. - Make the rules for processes explicit
The framework conditions of a Kanban board must be clearly defined for all parties involved. For example, definition of when a task is “finished”, what the individual columns represent and under which conditions the next ticket is selected. - Implementation of feedback cycles
The team is brought together for feedback rounds at previously defined dates. This includes the following variants:- Operation Reviews:
An objective glance of the activities takes place. - Retrospectives:
The cooperation is looked at retrospectively – also interpersonal. - Standup meetings:
There will be a brief discussion of upcoming tasks or blockages.
- Operation Reviews:
- Use of models
A model is the simplification of something real and allows to identify potential for improvement in the context of Kanban. Models originate from different theories and can, for example, help to achieve a better understanding of processes and to achieve more effectiveness and efficiency by means of derived practical experiments.
Scrum
Scrum embodies the values of agile software development formulated in the agile manifesto by Ken Schwaber, Jeff Sutherland and others:
- Individuals and interactions are more important than processes and tools.
- Working software is more important than comprehensive documentation.
- Cooperation with the customer is more important than contract negotiations.
- Responding to change is more important than following a plan.
Compared to Kanban, the Scrum process is usually cycle based with fixed cycles. At the beginning of a cycle, the product owner compiles the worklist (backlog) into a sprint (cycle). In the next step these stories are now evaluated and qualified by the developers. The team then plans as many stories for the sprint as are theoretically feasible. After the formal sprint start, it is often frowned upon to make changes to the sprint scope. At the end of the sprint there is a retrospective to improve the process and the finished (extended) product, which has the goal to be executable.
There are now countless extensions and modifications of the original process, whereby the basic rules remain mostly untouched. In large software development teams, gamification is often observed (see videos) to better identify with the product and the development processes.
Summary of Development Processes
You have just read three of the different methods of development processes, whose introduction to customers we accompany with our experience and knowledge from other projects and developed together with the customer. One of our first tasks in consulting is to determine which approach makes the most sense for you. Even if you are already using a method, we can help you to optimize it and, through the clever use of software and tools, expand it to make it more efficient. Let us unleash and optimize the potential of your software development together!
Team Honicon