6.12. Traditional and Agile Project Management

The word “agile” has almost become a buzzword in many areas. For many, being agile means working according to modern methods and simply being flexible and agile. In the field of software development, a so-called “Agile Manifesto” has emerged. Agile process or project management is so popular in the field of software because changes very often occur during development. Agile project management is therefore primarily about agile, i.e. rapid reaction to changes in product requirements. Agile principles and agile techniques follow from this challenge. Based on these principles and techniques, the term “Agile Project Management” has emerged. In the book “Agile Project Management – Agility and Scrum in the Classic Project Environment” by Dr. Jörg Preußig, this connection is described as follows:(27)

  • Classical software development was carried out according to the so-called waterfall model. In simplified terms, it was assumed that the requirements for the software product could be completely described at the beginning of the project. This description was then one of the first process steps for product development. Other process steps that followed were, for example: Analysis, Development, and Testing. Since these steps were run through in a similar sequential manner as water falls from top to bottom, the description of this process was given the name waterfall model.
  • When using the waterfall model, however, there was always a consequence that no one wanted: the failure of the project. The assumption that one could completely describe the requirements for the software product at the beginning of the project usually turned out to be wrong. Very often, these requirements were simply too complex and not clear enough even to the clients of the project in the initial phase. The waterfall process was then gradually replaced by agile process models. With these processes, it is possible to start with less clear requirements.
  • In both software development and project management, we speak of “classical” (or traditional) and “agile” methods.
  • According to this, agile project management is project management that is based on an agile process and uses agile principles and techniques.
  • Classical project management, on the other hand, is project management that is based on a waterfall model in the broader sense and uses project management techniques that fit this model.

In general, agile project management tends to stick to the schedule and reduce the scope (requirements), while traditional project management tends to stick to the requirements and extend the time to complete tasks.


6.12.1. Basics of Agile Project Management

In agile project management, there are various process models, such as Scrum, Kanban, Extreme Programming, Feature Driven Development or Test Driven Development.(28) These terms also show the strong connection to the world of software development.

An important strategy of agile processes is to minimize the room for misunderstanding between contractors and customers through short development cycles.(29)

The term Scrum comes from rugby and stands there for

“Scrum”. Scrum is about interactive cooperation and self-organization of a team. In 2001 the first book about Scrum was published, in the same year the “Manifesto for Agile Software Development” was published. From it the 12 agile principles:

Agile principles:
Customer retention through partial products: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome change: Welcome requirement changes even late in development. Agile processes use change to the customer’s competitive advantage.
Short development cycles: Deliver working software regularly within a few weeks or months, preferring the shorter time span.
Customer perspective in the project: Business experts and developers have to work together on a daily basis during the project.
Empowered employees: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Direct communication: The most efficient and effective way to communicate information to and within a development team is face-to-face.
Functioning part product: Functioning software is the most important measure of progress.
Sustainable project progress: Agile processes promote sustainable development. The clients, developers and users should be able to maintain a steady pace indefinitely.
Extendable part products: Constant attention to technical excellence and good design promotes agility.
Simple solutions: Simplicity ? the art of maximizing the amount of work not done? is essential.
Self-organized teams: The best architectures, requirements and designs are created by self-organized teams.
Continuous improvement: At regular intervals, the team reflects on how it can become more effective and adjusts its behaviour accordingly.


Briefly summarised, the manifesto states the following:(30)

  • Individuals and interactions are more important than processes and tools
  • functioning software more important than comprehensive documentation
  • Cooperation with the customer (client) more important than contract negotiations
  • Reacting to change is more important than following a plan


Also with Kanban there are basic principles, in this case there are 4: 

  1. Start with what you are currently doing.
  2. Strive for incremental, evolutionary change.
  3. Respect current processes, roles, responsibilities, and titles.
  4. Promote leadership and accountability at all levels of the organization.

Kanban suggests six practices for use in projects: 

  1. Make the work visible.
  2. Limit the amount of work started. 
  3. Measure and manage the flow.
  4. Make process rules explicit. 
  5. Develop feedback mechanisms.
  6. Make collaborative improvements.


6.12.2. Important Terms of Agile PM Using the Example of Scrum

Product Backlog: Documented requirements for the project object in the form of user stories in prioritized order incl. effort estimation.

User Story: A requirement often from the user’s point of view. A classic formulation is: “As a user, I would like to be able to book the concert with one mouse click”.

INVEST principle: User Stories should follow this principle. Independent, Negotiable, Valuable, Estimable, Small, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable, Testable.

Sprint: In Scrum, the implementation of user stories takes place in sprints, a constant time period of usually 30 days.

Sprint Backlog: Collection of upcoming tasks in the current sprint that are derived from user stories.

Daily Scrum: Short daily meeting (15 minutes) always at the same time for a short comparison of what was achieved the day before and planning of what is to come.

Increment: (Partial) result of a sprint. At the end of each sprint there is a new increment and at the end the final result. The increment itself must work and be presentable. The feedback then flows back into the user stories and into the planning of the next sprint.

Release plan: Overview plan that shows in which sprints which user stories are to be implemented. Takes into account priority, size, speed of the team and the strategic and economic framework conditions.

Roles: Scrum Team, Scrum Master, and Product Owner. In Scrum, there is no project manager. The Scrum team consists of the development team, Scrum Master and Product Owner. The Scrum Master is responsible for the functioning of the model and supports the team by creating optimal conditions. The product owner represents the customer/client, is responsible for the economic success, writes and initiates the user stories and prioritizes them.

Taskboard: A physical or electronic board on which user stories, tasks on hold, tasks in progress, and completed tasks are displayed in the form of cards. An excellent electronic tool for this is Trello (www.trello.com).


User Stories (in prioritized order) Task on hold (detail user stories into tasks, a task should be completed in one day) Task in progress Completed tasks
User Story 1

Task Y

Task Z Task W

Task A

Task T

Task M

Task P

Task O

Task E


Team members automatically put tasks on hold and start processing them. On the respective cards for the tasks, name abbreviations or color codes can show who is currently working on the respective task.


6.12.3 Agile and Traditional Compared


Agile Traditional

  • Conscious handling of fuzzy/unclear requirements in short intervals, functional
  • Intermediate products/results delivered
  • Goals and plans can be easily adapted to changing requirements 
  • Fast and reliable scheduling 
  • High degree of adaptation to the requirements of the client/customer 
  • Motivation of the team through self-coordination

  • Precise definition through specifications 
  • Extensive formal documentation 
  • Good planning capability
  • External project partners can be easily integrated through work package planning
  • Distributed and also virtual teams can be integrated more easily

  • High need for coordination
  • Difficult to implement with large teams 
  • Final project result difficult to predict
  • Little documentation available for the process, therefore difficult for safety-critical projects

  • Rigid in terms of time and resource planning and risky in terms of unknowns
  • Adaptations to changing requirements are time-consuming


6.12.4 Hybrid Project Management

Very often, agile project management does not occur in pure culture, but in a hybrid form. For example, the entire project can be managed traditionally, but subprojects can be managed according to agile principles. Another way to combine traditional and agile is to make individual phases of the project agile.

Definition of hybrid project management: The use of methods, roles, processes and phases of different standards or process models.(31)


27 Dr. Jörg Preußig, Agile Project Management, ePDF, p. 13-15, ISBN 978-3-648-10591-7

28 Holger Timinger, Modern Project Management, p. 161 ff, ISBN 978-3-527-53048-9

29 Dr. Jörg Preußig, Agile Project Management, ePDF, p. 45, ISBN 978-3-648-10591-7

30 Holger Timinger, Wiley Quick Course Project Management, pp. 69-70, ISBN 978-3-527-53024-3

31 Holger Timinger, Modern Project Management, p. 241, ISBN 978-3-527-53048-9