It was 1993.

Second year of my studies in Industrial Informatics. A strange setup: classes during the weekend, full‑time jobs during the week. Everyone was tired, most of us were guessing our way through.

The subject was Assembly Language.
The lecturer walked in, looked at the room, and opened with something that sounded more reassuring than it actually was:

“Now that you’ve passed the first year, you all know how to program. So I don’t have to teach you that anymore.”

That was… optimistic.
Then he continued:

“Everything about the Intel x86 architecture is in the book. All instructions are there. So there’s nothing I need to explain about that either.”

A short pause.

“The only thing I will show you is how to turn source code into an executable.”

And that’s exactly what he did.
After that, he gave us a task.

The Assignment

We were to form teams of two.

By the end of the next term — about ten months — each team had to hand in a floppy disk. Not just any disk. A bootable one. You’d put it in a PC, start it, and it would run our own version of a DOS‑like command interpreter.
In simple terms: write your own command.com.

Every two weeks, we would meet and show our progress.
That was it.

No methodology.
No templates.
No further explanation.

Two Ways of Starting

Most of the class reacted the way you would expect.
They started planning.

  • project plans
  • timelines
  • “business analysis” documents

Why anyone felt the need to write a business analysis for something already described in the MS‑DOS manual remains a mystery to me, even to this day.

They also kept coming back to the lecturer, asking for approval.
Not feedback.
Approval.
Plans were discussed. Documents reviewed. Nothing ran.

My buddy and I took a different approach.

We agreed to meet once a week for a few hours.
Week one, we “went to buy a floppy disk”.
At least, that’s what we said — so it wouldn’t look like we were doing nothing.
In reality, we spent the time playing FIFA International Soccer, which had just come out. He was obsessed with it. I was terrible.

The rest of the class noticed. There were comments. Some laughter.
The lecturer said nothing for a while. Then, at some point:

“I know which team will deliver by the end of the year.”

He didn’t elaborate.

Something That Runs

The next time we met, we had something.

A floppy disk we could boot from.
And a command.com that showed a prompt, accepted input, and answered everything with:

“Sorry, I can’t help you.”

Not impressive.
But it ran.

The Rhythm

From there, we settled into a pattern.

Every week:

  • take a few commands
  • implement them separately
  • meet
  • merge
  • test
  • fix
  • occasionally play some FIFA

And every two weeks:

  • show the result
  • ask the lecturer what he wanted to see next
  • clarify which parameters mattered

Sometimes we delivered everything we planned.
Sometimes we didn’t.
But every time, we could boot the machine and show something new that worked.

The Uncomfortable Decision

Around the middle of the project, something started to bother us.
We had more and more commands — but the way we handled parameters was… limited.
Good enough to continue.
Not good enough to keep.
So we made a decision.

We would stop adding new commands for a while and refactor what we had.

Build a proper parameter parser.
Rework existing commands to use it.

It wasn’t without risk.
Ten months sounds long — until it isn’t.
There was a real chance we wouldn’t finish all commands in time.

We went ahead anyway.

Meanwhile…

Around the same time, the rest of the class started working on their implementations.
Some of them were just figuring out how to make a floppy bootable.
Plans still looked impressive.
Documents were still growing.
Working software remained… rare.

The Outcome

At the end of the term:
We delivered:

  • a bootable disk
  • a command interpreter
  • 21 out of 29 commands
  • most of them with proper parameter support
  • plus the ability to run batch files

The rest of the class, in most cases:

  • had a bootable disk
  • a basic command shell
  • two or three commands
  • without parameters

What they did have were well‑structured documents.
They even criticized us for lacking documentation.
We didn’t argue much.
We just pulled out the MS‑DOS manual.

What This Was — and How It Was Recognized

Years later, when I started telling this story in trainings — Product Owner trainings, Scrum Master trainings, workshops — something predictable happened.
People recognized it almost immediately.

“That’s agile.”

And they weren’t wrong.
Looking at it through today’s lens, everything fits:

  • incremental progress
  • fast feedback
  • adapting along the way

The label works.
And I never really argued with it.

What Makes It Interesting

But for me, that’s not the interesting part.
Because back then, in 1993, none of this was a method.

We didn’t follow principles.
We didn’t apply any framework.
We didn’t even have the vocabulary.

We just tried to build something — and adjusted when it didn’t work.
It felt obvious.
Not innovative.
Not special.
Just… the most direct way from idea to result.

A Different Angle

That’s why I’ve never been fully comfortable with how the story is usually interpreted.
Because it suggests that we were “already doing agile” — as if we had somehow anticipated something that would only be defined years later.

I don’t think that’s what happened.
What happened is simpler.

This is what product development looks like
when the focus is on making something work.

What Came Later

Only later did I start hearing the distinction people like to make:

“classical project management”
versus
“agile”

As if one replaced the other.
As if one evolved from the other.

From where I stand, that distinction always felt… inverted.
What people call “agile” today is not a new invention.
It is a rediscovery of something much older:
What happens when people focus on making something work.

And what is often called “classical” is what appears when that focus is replaced by planning, documentation, and control mechanisms around the work.

What I Still Have

I still have that floppy disk somewhere.
I haven’t had a machine that could boot it in years.
It’s a useless artifact by now.
But it reminds me of something simple:
We didn’t know what we were “doing right”.
We just built something.
Step by step.
And adjusted when reality disagreed.

It also left something else behind: a lasting preference for working this way.