Agile · Scrum
Agile / Scrum
What is Agile?
- Agile = a philosophy of short iterations and fast adaptation
- Scrum = a way of running a team to put it into practice
- Learning fast beats planning perfectly
What Agile really changes is not working speed but the unit of decision-making. A structure in which a six-month plan, once approved, kept running even as the market shifted becomes one in which the order of remaining work is re-ranked every two weeks around something usable. Because what the team sends upward is a working product rather than a progress chart, learning you were wrong within two weeks rather than six months later is the biggest benefit of this approach.
Scrum has a minimum set of rules that keeps its shape. Sprints run 1 to 4 weeks, with 2 weeks the most common in Korean workplaces; the daily scrum stays within 15 minutes; and the team, including the Product Owner and Scrum Master, stays under 10 people. Above all, the backbone is the promise that once a sprint starts, its to-do list is not touched. Once a single remark from an executive starts inserting work mid-sprint, it is a sprint in name only and no different from the old practice of pushing in work at any time. The team is grouped around a product owner with clear accountability.
Not every kind of work fits Scrum, either. Organizations where work flows in continuously, such as customer support, operations, and maintenance, find it hard to cut work into cycles, and Kanban, which limits work in progress, fits better. For work such as public-sector system integration or facility expansion, where requirements are fixed in the contract and changes are prohibited, Waterfall is still the rational choice. The test is simple: is this work whose right answer you can’t know until you try it, or work where the answer is already set and only execution remains?
The most common point where practice goes wrong is when the team lead doubles as Scrum Master. If the lead runs the meeting, the 15-minute daily quickly turns into a morning status report, and team members repeat “in progress” instead of saying “I’m blocked.” The moment the retrospective shifts its target from the process to people, it hardens into a place for writing apologies and disappears within a couple of sessions. Another common misreading is to translate Agile as “faster and more”: if you set sprint goals at 1.5 times the team’s capacity and keep letting them fail, the team ends up committing only to what it can surely deliver.
Ara LimExpert in global leadership, AI, and business communication
John KimInstructor John Kim, author of B2B Marketing Design and CEO of Nanum ConsultingIt was established in 2001 when 17 software developers published the 'Agile Manifesto.' Scrum is a leading framework that had been developing since before then, in the 1990s.
Let’s look at a hypothetical case: Company A, an industrial parts manufacturer with 240 employees and KRW 80 billion (≈ US$59,853,400) in annual revenue. Its online store redesign project had gone eight months without launching. The plan had been scrapped and rewritten three times, and 142 requirements sat unaddressed.
- When Team Lead Kim of the web planning team posted all 142 requirements on the wall and said, "Let's keep only what we can't launch without in the next two weeks," just 9 were left.
- They gave the Scrum Master role not to the team lead but to Lee, a UX associate with four years of experience, and changed the rule for the 15-minute daily to ask only “What’s blocking you today?” instead of “What did you do yesterday?”
- At the week-2 review, they invited two sales reps and one dealer owner to click through the cart screen themselves, and a checkout error that would not have surfaced until three months after launch turned up on the spot.
- When someone said at the third retrospective, “We stalled for four days waiting on an executive’s sign-off,” Director Park of Management Support handed Team Lead Kim approval authority for items under KRW 2 million (≈ US$1,500) during the sprint.
- The company’s online store, which had dragged on for 8 months, launched in 12 weeks across 6 sprints. The time to absorb a requirement change fell from an average of 23 days to 5, and three months after launch the cart abandonment rate dropped from 31% to 22%.
- Uncertain projects where requirements change often
- When fast feedback and iteration matter
- Autonomous small teams
- When requirements and regulations are fixed and change is rare
- Large fixed-price contracts and document-driven environments
- Work where getting it right once matters more than iterating