Show Cover Slide

We Don't Do Scrum. We Pre-Snap.

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

1. Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We are discovering better ways of developing software through practice and support.
Through this work, we have come to value:

• [Individuals and interactions] over processes and tools
• [Working software] over comprehensive documentation
• [Customer collaboration] over contract negotiation
• [Responding to change] over following a plan

Thus, although the items on the right have value, we place more value on the items on the left.

2. We don’t do Scrum. We Pre-snap.

2-1. Scrum has become a structure that delays execution

Scrum was originally designed to enable agility.
But in reality, it has become a ritual of meetings and planning.
Under the name of “information sharing,”
execution is delayed, and meetings often take precedence over actual progress.

The more we plan, the less agile we become.

2-2. Sprints are no longer locked in

“Once a Sprint begins, no one is allowed to interfere with the work of the Scrum Team.”
“Requirements are frozen during a Sprint, allowing a team to focus on implementation and reach a stable product increment.”
(Ken Schwaber & Jeff Sutherland, SCRUM Development Process, OOPSLA 1995)

In practice, sprints are often disrupted by changing requirements and external demands.
Sprints fail to ensure focused execution, and
the process becomes a symbol without substance.

2-3. Pre-snap is about aligning and reaffirming strategy

We take inspiration from American football.
Pre-snap is the moment before the play begins,
when the quarterback reads the defense, confirms the play, and aligns the entire team.

In our team, Pre-snap is:

• Once a day, 1 minute per person
• Simple format: Did / Doing / Need
• Questions come after; feedback is shared asynchronously

Pre-snap is not a meeting.
It’s a strategic alignment moment for execution.
Each day, we briefly revisit the plan to reduce uncertainty.

Before we execute, we ask:
“Is this still the right direction?”
Pre-snap exists to make sure we ask this—every single day.

3. We don’t sprint. We set Check-Points.

We don’t do sprints that push plans into a fixed timeframe.
Instead, we establish natural alignment points within the flow of execution.

• Sprints often morph into cycles more about planning and formality than execution.
• We are a team centered on execution, not planning.
• However, even in execution, a rhythm for discussion and checking is necessary.

We use check-points not as schedule managers,
but as “a means to design conversations.”

Check-points are

• Was the issue small enough?
• Was the flow of resolution clear?
• Are the records sharable?
• Is it connecting with the customers?
  These checkpoints allow the team to realign and converse.

When working with externals, we explain using check-points

Our method may not be familiar to all organizations.
Many external teams work centered on “schedules,” “deadlines,” “plans.”
To avoid conflicts, we use communication bridges that describe check-points like schedules.

• Internally, we use check-points as tools for aligning execution flows,
• Externally, we describe them as predictable moments of sharing.

We do not claim to be different.
We build bridges.
Check-points are a practical communication structure that connects our execution rhythm to external language.

We don’t rush.
We align, check, and move again.
Schedules are structures for conversation,
and check-points are the structures for that rhythm.

4. Agile Principles We Follow

1. Solving customer problems is our top priority

• If the customer is undefined, we do not work.
• The customer can change but must not be absent.
• The problems we solve must be within the context of the customer.

2. Innovating through short units of problem-solving

• We divide problems into small parts, solve them quickly, and
  leave them as recordable outputs.
• Small executions accumulate into innovation.

‘Short units’ not only mean time but also refer to units of execution that use working software to validate and record problems.

We trust showing the flow rather than the results,
and training to divide into executable units is itself agile.

3. Outputs are records

• Outputs are traces recorded.
• Code, documents, media explain how we solved a particular problem.

4. Minimal tools, focused thinking

• Tools are used only when necessary.
• Too many tools scatter thinking.
• We maintain alignment and execution with just a few essential tools.

5. Definitions

6. Our Declaration

We no longer scrum.
We Pre-snap.
We align and advance.
We solve problems and accumulate small executions to create innovation.
We execute a realigned Agile that Pre-snaps.

Q&A: Frequent Questions from Our Team

Q1. What should we share if there isn’t a proper output yet?

Pre-snap isn’t about presenting completion but sharing the flow of execution.
Even if there are no results yet, sharing about

• which problem you were solving
• what attempts were made
• where you got stuck

is sufficient.

We consider even failures as outputs.
If it’s organized, it’s meaningful to share.

Q2. Sometimes scrum takes more than a minute?

It might exceed that. The important thing is not to make it a habit.
If you frequently exceed one minute, it might be because

• the problem was too large,
• requests were unclear,
• there was an attempt to handle feedback during scrum.

Pre-snap is a moment of alignment.
Feedback is separate, scrum is short.

Q3. Edits keep happening, when do we deploy?

We maintain a state where we can always deploy.
Deploying doesn’t mean “it’s finished,” but that
the problem has been solved, organized, and is ready to be shared.

• If it was done in a day? You’ve executed a small, well-divided problem effectively.
• Deployment is not a planned event but part of the flow.

Problem-solving → Organizing → Sharing → Deployment
This is our team’s basic cycle.

Q4. When and how should we get feedback?

We do not provide feedback during Pre-snap.
Briefly summarize requests, and continue with

• Slack
• PR comments
• Short sync conversations if needed

for feedback separately.

Alignment now,
feedback later.
That’s our rhythm.

Q5. Can’t we just talk instead of documenting?

Talking is good, but records need to remain for reuse.
It doesn’t have to be a polished document.
Slack messages, PR comments, simple Notion notes are fine.

We value “it is recorded” over “it was said.”

Q6. Is this method okay when working with externals?

Our alignment is always at a level safe to show externally.
Pre-snap sharing should always be able to explain

“Why did we do this?”
“Why was this necessary?”

Sharing is not a waste of time but an act of structuring why we did the work and conveying it.

Q7. Can we share mistakes and failures too?

Certainly. We aim to be an organization that executes without fear.
Failure is not to be hidden but recorded and passed on as an asset to the next person.

Agile is not about adhering to plans,
but about learning from repeated experiments.

Q8. I feel like I have nothing to write. What should I write?

Ask yourself:

“What customer problem did I solve with my actions today?”

In Pre-snap, instead of your feelings or efforts, write about
which customer’s problem you were solving and how.

• It’s okay if it’s not resolved yet.
• Just organizing why you are doing it and where you are stuck is enough.

The focus is less on “did you work?” and more on “for whom and why did you work?”
If you think customer-centric, you will always have stories to write.

Q9. I’m not making progress. Isn’t it bad to record that?

That thought is very natural and common.
But the real essence of agile is showing the flow of execution rather than the results.

• Slow progress is an issue.
• And that’s a good feedback opportunity.
  → “This problem was too big”
  → “We might have defined the problem incorrectly”
  → “This approach isn’t working”
  These are signals you are providing.

The important thing is “not to hide the progress.”
Hiding is a problem; revealing is feedback.

And you should be able to say:

“It’s not that I’m slow; it’s a case showing that the team needs to divide the problem smaller.”

A team that reveals this is doing agile well.

Q10. I feel like I’m falling behind others. Is that okay?

Absolutely, it’s natural to feel that way.
However, agile is not about comparing speeds but about aligning directions.

• If you are pausing to think,
  it’s not that your execution is slow, but that you are engaging in necessary alignment.
• That pause might be a vital feedback that protects the whole team.

We trust people who can stop when needed more than those who run fast.

Q11. I don’t understand why this task is important.

Always ask,
“Whose problem does this solve?”
“What customer will be troubled if we don’t do this?”

• Focusing on the problem rather than the task itself starts to reveal its importance.
• If, after looking closely, there’s no customer connection,
  it might indeed be a task that needs redefining.

Being agile means constantly checking “why are we doing this?”

Q12. My work seems too small to share; it’s embarrassing.

If it seems small, you’ve divided it well.
We intentionally break down work into small, sharable pieces.

• Small, divided problems are quickly resolved,
  quickly shared,
  and quickly receive feedback.

It’s not embarrassing but proof that you’re accurately on the team’s flow.
Small and rapid executions accumulate into real change.

Q13. Wouldn’t too many requests be a disturbance?

Not at all. Many requests mean
problems are being better revealed.

• If requests are asynchronous, no one’s rhythm is disrupted.
• If requests repeat often, it shows that
  we might automate or improve a tool.

Questions aren’t disturbances but signals for structural improvement.
Requests are starting points for improving the organization.

Q14. If it’s agile, why are there so many fixed routines?

Agile is not about having no plan but about having a structure that can adjust plans.
Pre-snap is a rhythm for alignment,
and having that rhythm allows experiments to be freer.

• With fixed times and formats,
  we can anticipate each other’s flows and
  collaborate without disruption.

True freedom is created within structure.
Pre-snap gives us that structuring rhythm.

Q15. There’s too much asynchronous feedback; I can’t focus on my work.

Correct. Just because it’s asynchronous doesn’t mean it won’t interrupt focus.
Constant messages might even be more distracting.

So, we organize like this:

• Feedback doesn’t need to be addressed immediately.
  The important thing is preserving the flow so you can respond anytime.
  → We use designated channels like Slack, PR, Notion.

• Focus time is a promise we keep with each other.
  Feedback is not about immediate processing but doing it when possible.

• If requests are accumulating, share that fact.
  “I have three pending requests, and I can only address one today”
  → Sharing like this allows the team to wait and adjust structurally.

Requests are not to be hidden but transparently shared signals.
We are a team that respects both each other’s focus and responses.

Appendix: Why We Solve Problems with Software

We don’t just use software because we like it.
Software offers the shortest feedback loop among the tools available to us.

1. A short feedback loop means speed in execution and learning.

• WordPress allows you to preview a web page before publishing it.
• Photoshop lets you see the effects of filters or layers in real-time.
• Developers can save and immediately run codes to see the results.

All these structures help us
“execute → check → modify → repeat” in a quick learning cycle.

2. The software we use is more than just an implementation tool.

Software is an execution-based design tool that allows us to express, validate, and improve our ideas.

We can quickly realize ideas,
incorporate user feedback,
and record failed attempts.

This is why we adopt “short units of execution” as the basic structure for problem-solving,
and it’s the tool that enables this structure—software.

3. Therefore, we create and share ‘executable units’.

• A functioning button
• An input processed in reality
• A testable flow
• Visible media outcomes

These are the outputs of our team,
units quickly divided, rapidly verified, and recordable.

Software allows us to experiment the fastest,
fail the smallest,
and share the clearest.
That’s why we use software as a tool.