Agile, Kanban, Scrum, Sprint…? What really matters?

Category

Opinions on the bass

Written by

Luke Lee (CEO)

Date

Empty

Hello. This is Lee Taeyang.

It's been about two months since I joined Base Investment as a growth partner. After meeting with 20 teams—which can feel like a lot or a little depending on how you see it—I've found that, although concerns differ based on business area, team size, or service model, one topic keeps coming up: service development methodology(?). As we strive to deliver great products for customers, issues inevitably arise around sprint schedules not being kept, defining the right MVP specs, and communication between planners, designers, and developers. There are many ways to address each issue, but for a more fundamental solution, I often use the following analogy.

Startups are building solutions that haven't yet been validated in the market, and it's like feeling your way across stepping stones in pitch-black darkness, not knowing what lies ahead.

Someone—the entrepreneur—who's found (or believes they've found) something across the river gathers others to cross with and sets out on that challenge. In these conditions where you can’t see even an inch in front of you, it’s an adventure: stepping carefully to the water’s edge, checking for stones to step on, and crossing the river—sometimes in a zigzag rather than a straight line.

So, how do we cross this river quickly and safely?

You have to step where there's the highest chance of finding stepping stones. (A good hypothesis)

You need to take as many steps as possible to find the stepping stones without falling in.
(Time is a limited resource, so more attempts = faster execution )

So, the way to cross the river quickly = good hypothesis * fast execution

A development methodology that lets us quickly execute on good hypotheses is Scrum, one of the most common agile frameworks.

Sprint cycles, repeated regularly, help us search for new stepping stones at a steady pace. Setting a cycle—usually two weeks—prevents us from overinvesting in one go (by minimizing release scope), while daily scrums encourage not just execution but meaningful communication to reach goals. Retrospectives then help us build and test even better hypotheses, creating a positive feedback loop.

However, many teams get too caught up in the Scrum framework itself and run into problems like these:

•

Focusing on churning out sprint deliverables and feeling satisfied with just that

•

Holding daily scrum meetings that simply check off the schedule with no real meaning

•

Retrospectives filled with complaints but no improvements (meaningless features, missed deadlines, etc.)

For example, let's imagine a hyperlocal secondhand market called Grape Market. In this company, the Discovery Team comes up with the idea of adding a hashtag search function in the current sprint. They suggest it could be easier and more trendy than their existing keyword search. But by the second day of the sprint, a developer points out that the task is so big and complex, and so intertwined with other departments, that it will be hard to meet the deadline—and even harder to roll back after adding the feature. Still, since it's already been agreed to and mentioned to other teams and management, the decision is made to push through no matter what. Eventually, the plan turns into a four-week project, and they work through the night to hit the release date. Celebrating the tough achievement, they start preparing more hashtag-related features (like blocking harmful keywords and managing favorite keywords) for the next sprint.

In this example, the Discovery Team could have either set a better hypothesis or executed more quickly.

Finding places most likely to have stepping stones (a good hypothesis)

To validate the hypothesis, we could've checked usability and satisfaction through existing keyword search, making the feature's scope and goals clearer.

Instead of jumping straight into more feature development after release, we could've built better hypotheses by looking at user search patterns and conversion rates.

As many attempts as possible without risking much (fast execution)
3. We could've simply switched the keyword search UI to a hashtag style, cutting down workload for other departments and validating through A/B testing.
4. In the daily scrum, when developers mentioned the spec getting too heavy, what if we'd considered a smaller scope focused on our main hypothesis?

In summary,

•

Look more closely at the core of the problem to set a good hypothesis,

•

Focus on the core features for testing your hypothesis, so you can move quickly,

•

View the results objectively and continuously come up with better hypotheses.

Scrum is a framework for discovery—a tool to help us adapt efficiently in complex, unpredictable environments. The real goal isn't to simply ship new features in a sprint, but to boost user satisfaction and create additional value that improves our service and business through those features. If we keep adding features that don't meet this goal, we just make our product more complex and dilute the value we want to give our customers—and weigh ourselves down as we cross the river.

I mentioned Scrum as an example, but there’s really no single right answer for development methodologies. Methods that were seen as 'the answer' years ago are now relics of the past. I wanted to start this conversation to reflect, even briefly, on what criteria we should use as we search for an approach that fits our market, our customers, our service, and us!

The following is a famous Agile Manifesto . I reread it before writing this post, and I plan to read it again as I wrap it up.

Subscribe to 'BASS Ventures'

Welcome to BASS Ventures, the mecca for entrepreneurs with crazy dreams!
By subscribing to the site, you will be the first to receive the latest updates, including new posts, via notifications and email.
Join SlashPage and subscribe to 'BASS Ventures'!