Classic, Agile, or Hybrid? — Choose Methods by Project Logic, Not Fashion

Project-management discussions often sound surprisingly tribal. Traditional project management is called slow, agile is called modern, Scrum is treated as professional, and Kanban as flexible. Or the stereotypes run in the opposite direction: agile becomes a synonym for weak planning, while a detailed project plan is assumed to prove control.

In AI projects, this opposition becomes misleading very quickly.

The decisive question is not which method sounds more current. The decisive question is which control logic fits the project.

This idea can be developed across several teaching days. Early in the module, participants were asked not merely to list classic and agile approaches but to research and distinguish them. Later, Scrum and Kanban were compared more concretely, AI was used to simulate roles such as Scrum Master, Agile Coach, and even the customer perspective, and hybrid approaches were developed from that exercise. On the following day, the class discussed a real participant approach that deliberately combined classic project management with agile elements.

That is more than method theory. It points to a fundamental principle:

The method should follow uncertainty, change dynamics, and project structure — not fashion.

Three control logics, not three belief systems

Classic, agile, and hybrid approaches are most useful when understood not as toolboxes but as different responses to uncertainty.

Classic: structure first, execution second

A classic planning logic is strong when the project can be described with reasonable confidence early on.

That does not mean nothing may change. It means that key variables can be defined reliably before implementation begins:

• the objective,

• the scope,

• major requirements,

• important dependencies,

• milestones,

• resources,

• approvals,

• deliverables.

In that situation, it makes sense to move a substantial amount of structure to the front of the project. Decisions are made early, work packages are planned, and dependencies are exposed before execution begins. The implementation phase can then follow a prepared path with less coordination friction.

This logic is especially valuable when later changes are expensive. If contracts, external production, procurement, formal approvals, or tightly coupled delivery chains are involved, "we will discover it in the sprint" can become a very costly attitude.

The strength of classic planning is therefore not rigidity. It is up-front coordination.

Agile: execute, learn, decide again

An agile logic becomes powerful when important information only emerges during the work.

The objective may be clear, while the best solution is not. User feedback may fundamentally change the product. An AI model may perform differently in real use than in a controlled test. A prototype may be the only reliable way to discover whether an architecture is viable.

In those situations, a highly detailed long-range plan does not create additional certainty. It merely translates uncertainty into precise-looking assumptions.

Agile work deliberately postpones some decisions. Small units are implemented, reviewed, and adjusted using newly available evidence.

The advantage is not that less planning takes place. The advantage is that planning and learning are coupled more closely.

Hybrid: stability on the outside, adaptation on the inside

Many real AI projects fit neither category cleanly.

The budget may be fixed while technical implementation remains iterative. A launch date may be non-negotiable while features are reprioritized. Compliance or customer requirements may be binding, while model choice, prompting, data preparation, and UX are developed through loops.

That is where hybrid logic becomes useful.

Hybrid does not mean, "take a little bit of everything."

A strong hybrid approach separates deliberately between:

• stable project boundaries that are decided early,

• and adaptive workspaces that can be explored iteratively inside those boundaries.

The shortest useful formulation is:

Stable shell, learning core.

The teaching deliberately moved beyond definitions

Good teaching does not treat agile methods as vocabulary for an exam.

First, a research basis is established: which project-management methods exist, how classic and agile approaches differ, and which of them are relevant for the participant's own project.

The discussion then becomes more concrete. In a Scrum and Kanban session, the class does not merely discuss boards. The method logic is connected to roles. AI can, for example, be used as a Scrum Master, Agile Coach, or customer. That allows a method to be rehearsed, not only described.

This matters pedagogically.

A method is not fully understood because somebody knows its definition. It becomes understandable when the team experiences:

• when a new requirement may enter the process,

• when work in progress must be protected,

• how priorities may change,

• who has authority to decide,

• how feedback enters the next working phase,

• and what information a team needs in order to continue.

On the next teaching day, this theory is transferred into project examples. One participant had prepared a hybrid model that combined classic project management with agile elements. That transfer from method knowledge to a real project context is the critical move.

The useful question is therefore not, "Can I explain Scrum?"

It is:

"Which parts of my project require binding planning — and which parts require deliberately short learning loops?"

Project logic 1: How stable is the problem itself?

The first decision factor is not the solution path but the problem.

If the problem definition itself changes frequently, long-range detailed planning becomes risky. A team may plan very precisely toward a target that will be framed differently two weeks later.

If the problem is stable and well understood, more work can be moved into the planning phase.

Consider two examples.

A company wants to create a clearly defined internal workshop for a known AI workflow. Audience, date, format, learning objectives, and approval structure are already known. A large part of the work can be planned classically.

Another team wants to discover what new AI product customers actually need. The problem is still open, user reaction is critical, and technical discoveries will change the idea. The control logic should be more exploratory and agile.

Project logic 2: How expensive is change?

Not every uncertainty has to be handled in an agile way.

The critical question is also what a later change costs.

A paragraph can be rewritten cheaply. A data architecture may already be expensive to replace. A contracted external production step or a hardware purchase can be extremely expensive to reverse.

The higher the cost of change, the more valuable early clarification becomes.

This produces an important hybrid principle:

Plan irreversible decisions earlier and reversible decisions later.

Hybrid work then stops being a method cocktail and becomes an economic control logic.

Project logic 3: How quickly do we receive real feedback?

Agile loops only work when the loop can actually learn.

A sprint without meaningful feedback is merely a shorter planning block.

A Kanban board without information about flow, blockers, or priority is just an attractive task list.

The crucial question is:

How quickly does new information arrive that can improve a decision?

For a digital prototype, that may happen within hours or days. For infrastructure work, useful feedback may appear only weeks later.

The shorter the feedback latency, the more valuable iterative control becomes.

Project logic 4: How many dependencies must remain synchronized?

Agility is often equated with flexibility. High dependency density can limit that flexibility.

If five work packages can be built independently, they can be reprioritized easily. If task B must wait for A, C and D compete for the same resource, and E cannot begin before an external approval, stronger coordination becomes necessary.

That does not automatically mean "classic."

It means that the adaptive part of the project requires a stable coordination layer.

AI projects often benefit from executing experiments in an agile way while planning resources, approvals, data access, and critical dependencies more firmly.

Project logic 5: What must be binding — and what may remain experimental?

This distinction is especially relevant in AI work.

Binding elements may include:

• privacy boundaries,

• budget ceilings,

• delivery dates,

• approval rights,

• approved data sources,

• quality criteria,

• security rules,

• contractual deliverables.

Experimental elements may include:

• model selection,

• prompting strategies,

• workflow variants,

• interface concepts,

• agent configurations,

• sequencing of small optimizations.

A strong hybrid approach does not treat those two categories equally.