Show Cover Slide

Is Our Agile Really 'Agile'?

gpt-4-turbo has translated this article into English.

Sprints rotate, and meetings are held regularly.

The backlog is also neatly organized.

However, we often struggle to set goals for each sprint.

We have a product we want to make, but we don’t know where to start
and more fundamentally, we didn’t even know why we should make it.

Why make it—where are the customers?

There were no ‘customers’ in the meetings, in the backlog, or in the PM’s explanations.

At that moment, I asked myself.

“Is our Agile really ‘Agile’?”

Agile is not about splitting schedules

Many teams focus on adopting the form of Agile as they introduce it.
Daily scrum, sprint retrospectives, Kanban boards, backlog management…

However, if “being able to stick to the schedule” becomes more important than “what to make,”
Agile just becomes a tool for job control.

“Who is the customer of this product, and
what problem are they experiencing?”

Defining the customer is the leader’s responsibility

So, as a leader, I decided to start again with the simplest question.

“If I, a developer, were using it, what functionality would I need?”

Using this question as a starting point, we began to approach from the perspective of internal users.
Imagining the context and situation in which the actual product would be used,
we defined personas based on real-life users like elderly parents or franchise owners.

Then, based on these personas, we created scenarios and
developed working prototypes to share with internal users.

“My mom can’t use this.”
“It seems hard for a store owner to switch screens.”

This wasn’t just simple UI feedback.
It was the moment when the context of the customers first entered our team.

From then on, we became a team that asks ‘who is it for?’ before ‘what features should we make?’.

Instead of 2-week sprints, 2-day experiments

For faster validation, I suggested a structure where
we share working prototypes every two days instead of every two weeks.

The goal was not to ‘complete,’ but to

“Are we moving in a meaningful direction for our customers?”
to create small, runnable pieces of code that could verify this.

The team’s responses varied.
Some shared their outcomes every two days,
while others said, “I’ll share it in the next cycle.”

I didn’t see this difference as a problem.
Adapting to an unfamiliar method takes time, and that process is also part of Agile.

As we repeated these experiments,
those with high execution power became the core of the flow,
and all members began to view functions from the customer’s perspective.

Agile is ultimately a philosophy of leadership

I still think Agile is a good methodology.
However, I believe that for Agile to really work,
culture and philosophy must follow.

Especially in Korean organizational culture,
Agile is often used only as a ‘system to control schedules,’ and
customers are erased from meetings, feature definitions, and feedback loops.

Agile should
help organizations learn, validate, and adjust directions.

And that structure starts with the leader’s question.

“This feature we are creating,
does it really mean something to someone?”

As long as we don’t give up on this question,
I believe Agile can always come back to life.