Agile system development means using the huge store of "best practices" that have long existed in the minds of project participants. Furthermore, it focuses on what works and is therefore voluntarily applied again in the next project. This promotes individual freedom and creates trust instead of control. Agility is action, not reaction. It requires knowledge and demands a high level of qualification and professionalism from everyone involved. Only those who know how the gears mesh also have the courage and competence to disregard rules that do not fit. "Appropriateness instead of perfection" is one of the essential paradigms of agility. The focus is on the essentials and thus makes the procedure more flexible for possible adjustments to current circumstances.

Agile Process Models

The foundation for different agile strategies is the agile manifesto, on which basis several different iterative-incremental approaches have been developed. In the beginning, agile models led a niche existence and were regarded as rather exotic. By now, however, they have been established as fully valid approaches in the field of system development. The following list is a selection of well-established agile approaches:

Scrum is based on the principles of transparency, inspection and adaption, which rely on certain roles (product owner, scrum master and development team) and rituals (sprint-planning, daily scrum, sprint review and sprint retrospective). At the center of a scrum-based development process lies the sprint, which is a clearly demarcated time frame, in which a deliverable product is developed.

Extreme Programming focuses strongly on the actual development, i.e. coding, of a product. The basis for Extreme Programming are the values simplicity, communication, feedback, courage and respect. The process model uses main-practices, such as Pair-Programming, test-driven development and the collective ownership of code, which offers the developer concrete guidelines for implementation.

Kanban is not an immediate part of agile process models. It can, however, fairly easily be implemented in an agile way. Kanban consists of six principles, such as the visualization of workflow, which is outlined by columns assigned to every process step on a Kanban-board. With a pull-system in use, the requirements pass through each column of the board and therefore through each step of development.The Definition of Done defines the prerequisites for the implementation of a requirement.

 

Agile Scaled Frameworks allow for agile process models, which are usually applied within one development team only, to be combined with approaches of lean management, in order to use the advantages of agility in larger development projects.

Other agile process models, which have, however, become less significant in the last years, include The Crystal Family, Feature Driven Development (FDD) and Evo.

Agility and RE

The basic principles of Requirements Engineering  are relevant in an agile setting as well, which equally requires a well-structured use of requirements. In contrast to classic process models, the steps of Requirements Engineering are not worked through “en bloc” and only once, but are re-employed with every new iteration cycle. 

Documentation may be less significant in agile process models than in classic ones. Nevertheless, the stakeholders’ knowledge (be it the client’s or the user’s) must be communicated to the developers – which means Requirements Engineering must still be performed.

Introduction of Agility

The introduction of an agile process is a project, in which the basic principles of Change Management meet the additional challenge of established hierarchies and values. At the start of a project, the goals of the introduction of agility must be defined and the parameters of the project established.

  • Which agile approach is the most fitting and most beneficial for the company?
  • To which degree shall the agile values replace the historically-established ones?
  • How can a company-specific agile manifesto be composed?
  • In which phases of the development process should agile approaches be used?

Using agile approaches is not uniformly suitable for every company, every project and every development phase. One solution for these cases is a hybrid approach, combining agile development with classic Requirements Engineering. A hybrid approach couples the advantages of agile approaches, such as high transparency thanks to regular inspections and considerable ability to adapt thanks to short development cycles, with the structuredness and controllability of classic process models.

If one decides to introduce agility into the entire development process, a multi-step transition is a good alternative to a radical change. Traditional roles and responsibilities are compared to each other and newly distributed.

Do you have any questions?

If you have any questions to the consulting and project work of SOPHIST, we are at your disposal: from the organization and preparation to implementation and follow-up. We will be happy to help you.

Your contact person:

vertrieb[at]sophist[dot]de

+49 (0)9 11 40 900 64

Your contact person:

vertrieb[at]sophist[dot]de

+49 (0)9 11 40 900 62

Copyright 2018

SOPHIST GmbH

Do you need more information?

Just give us a Call  and let us direct you to the right contact person?

Tel:      +49 (0)9 11 40 90 00

E-Mail: heureka[at]sophist[dot]de

Our office hours:                   Monday to Thursday:                              Friday:
                                              08:00 - 12:00 Uhr                                    08:00 - 12:00 Uhr
                                              13:00 - 18:00 Uhr                                    13:00 - 17:00 Uhr



Of course you are also welcome to reach various departments directly by e-mail:

 


All about trainings, projects or consulting activities:

vertrieb[at]sophist[dot]de

 



All about our job offers and your career opportunities at SOPHIST:

DeineZukunft[at]sophist[dot]de


 

All about our events, marketing activities and publications:

marketing[at]sophist[dot]de


 

 

Legal disclaimer

Privacy Policy