ETC

Agile Development in a Startup: Sprints and Retrospectives for Enhanced Productivity

한국어로 읽기 →
Contents
  1. 11️⃣ Why Startups Need Agile
  2. 22️⃣ Our Journey to Agile Development
  3. 33️⃣ Our Agile Development Process
  4. 44️⃣ Changes After Implementing Agile

Software development methodologies continue to evolve. Particularly for startups that need to respond to rapidly changing markets and uncertain requirements, a more flexible and efficient process is needed compared to traditional development methods. In such environments, it's crucial to quickly incorporate user feedback and resolve issues early through smooth team communication. This is why innovative development methodologies like Agile are gaining prominence.

At ZIEN, we experimentally introduced Agile development to establish a cultural foundation for our development team. Agile is one of several software development methodologies that, unlike the Waterfall method which plans and develops from start to finish, progresses flexibly by receiving immediate feedback during development. Going beyond theoretical knowledge, we've been working to improve our team's collaboration methods and development productivity through practical application of Agile.

This article aims to share our experiences and insights from introducing Agile development at ZIEN. We hope this will help other development teams facing similar challenges find new directions.

1️⃣ Why Startups Need Agile

In startups, where market and user needs change rapidly, it's more important to respond flexibly and validate quickly rather than stick to initial plans.

  • Quick execution and improvement: Validate small functional units quickly and improve iteratively

  • Risk minimization: Prevent major issues by receiving continuous feedback from the start

In these aspects, Agile is the most suitable methodology for maximizing a startup's speed and adaptability.

2️⃣ Our Journey to Agile Development

We aimed to establish a new cultural foundation for our development team by planning work more precisely and targeting better collaboration with rapid feedback.

Previously, team members planned their development work by creating individual tasks in Notion. This made it challenging to track what tasks others were working on and how well they were progressing.

Since many tasks were independent, team members often focused solely on their work, missing opportunities for quick and efficient mutual support. We particularly recognized the need to provide guidance through rapid feedback for team members who were finding their footing with new tasks.

3️⃣ Our Agile Development Process

Our company is working to become familiar with Agile development through the following approach:

3.1. Sprint Planning

At the sprint kickoff, we gather to list tasks for the period. The format includes:

  • Project Name: Indicates the project name for the task

  • Task: Clear description of the work (e.g., "Planning - Menu Category Structure", "Development - Project Spec Setup")

  • Owner: Task assignee

  • Priority: Marked as Essential/High/Medium/Low

  • Estimated Time: Estimated work duration in hours

  • Deadline: Set deadline or target completion date

After listing tasks, we write our "one thing" - the key goal we must achieve during this cycle.

Team members then present their planned tasks. This process helps identify which tasks need more breakdown, which might be unnecessary, and where team members can share helpful references.

3.2. Sprints and Daily Stand-up Meetings

After sprint planning, we manage tasks through Notion, with completing each task feeling like clearing a quest in a game.

Daily stand-up meetings occur at 10 AM through our Slack channel. Each morning, we share what we did yesterday, what we'll do today, and any special considerations. This allows us to coordinate meeting times if needed.

3.3. Retrospectives

We hold retrospective meetings on the final day of each sprint. We start by reviewing the sprint planning document to see how planned versus actual work changed and what we achieved.

We use Miro for retrospectives with the following format:

  • Liked: Brief keywords about what went well during the sprint

  • Learned: Keywords about what we learned

  • Lacked: Keywords about what was missing or needed improvement

  • Longed for: Keywords to carry forward to the next sprint

Each person shares their Liked, Learned, and Lacked items. For example: "I'm glad Project A finished this sprint, I learned about taking a broader view in project design, but communication could have been better. I'd like to communicate more frequently next sprint."

We then collectively choose items to carry forward to the next sprint, which can come from any category or be entirely new.

4️⃣ Changes After Implementing Agile

After adopting Agile, our team experienced concrete changes:

  • Improved Work Efficiency: We began breaking down and defining tasks more clearly. Team members can now better understand estimated time requirements and priorities before starting work, significantly improving workflow efficiency.

  • Enhanced Communication and Collaboration: Daily stand-ups enabled real-time communication about progress and obstacles. For instance, we reduced unnecessary face-to-face meetings by sharing information quickly through collaboration tools.

  • Increased Ownership: Previously, team members tended to passively follow task instructions. Now, each member takes active ownership of their work. This has led to better self-organization, clearer task prioritization, and improved focus and understanding of work.

Agile methodology is still in the process of becoming deeply embedded in our development culture. Moving forward, we plan to create guide documents to introduce this culture and help new team members naturally integrate into the team. While we're still in the early stages and expect to face various challenges, we believe overcoming these will help us become more familiar with Agile development and strengthen our team.

Z ZIEN
{# 쿠키 수집 안내 팝업 — 선택 전 방문자에게만(cookie-consent '쿠키 안내 팝업'). 버튼은 폼 POST 라 JS 없이 동작하고, 닫기(×)는 '거부' 와 같이 저장된다. source·close 는 누른 버튼별 집계용 — 닫기를 거부와 따로 센다(cookie-consent '쿠키 선택 집계'). #}