스크럼과 애자일, 무엇이 진정한 민첩성을 가져올까?

ⓒ pexels.com

 

1. 모두가 원하는 '민첩성', 그러나 무엇이 문제인가?

소프트웨어 관리자가 '민첩해지기'를 원하지 않을 리 없습니다. 그러나 '애자일(Agile)'이라는 개념을 제대로 이해하거나 실제로 적용하려고 깊이 고민하는 관리자는 그리 많지 않은 듯합니다. 애자일의 선언을 읽어본 사람조차 드물며, 애자일의 본질과 그것이 실제 현장에서 어떻게 작동하는지에 대한 탐구는 더욱 부족한 현실입니다.

대부분의 소프트웨어 개발자들은 애자일 선언에 담긴 철학과 원칙을 존중합니다. 하지만 "그러면 우리는 무엇을 해야 하는가?"라는 근본적인 질문에는 답을 찾기 어려워합니다. 많은 조직은 단순히 스크럼 컨설턴트를 채용하고 이를 실행하면 민첩해질 것이라는 결론을 내립니다. 하지만 이러한 접근 방식이 애자일 원칙의 본질과 맞는 것일까요?

---

2. 스크럼, 애자일의 도구인가 걸림돌인가?

스크럼(Scrum)은 애자일 실천법 중 하나로 잘 알려져 있습니다. 하지만 스크럼을 고정된 틀로 강제 적용하는 관행은 때로는 애자일의 원칙과 정반대로 작동합니다.

스크럼은 정해진 시간(스프린트) 안에 작업을 끝내야 하는 구조를 요구합니다. 이 과정에서 작업은 정해진 시간에 맞추기 위해 모양이 바뀌고, 결과물이 원래 의도와 어긋나는 경우가 생깁니다. 결국, "계획에 따르기보다 변화에 대응한다"는 애자일의 핵심 원칙은 간과되기 쉽습니다.

또한, 스프린트를 반복하다 보면 항상 마감에 쫓기게 되고, 이는 부실한 결과물과 스트레스로 이어질 수 있습니다. "무언가를 끝내야 한다"는 압박이 품질보다 속도를 우선시하도록 만들기 때문입니다.

---

3. 스크럼의 의식화와 비효율성 문제

많은 경우, 스크럼은 불필요하게 장황한 의식으로 변질되곤 합니다. 예를 들어, 매일 진행되는 일일 스탠드업 회의에서 직원들이 단순히 "어제 무엇을 했고, 오늘 무엇을 할 것인지"를 보고하기 위해 시간을 소모합니다. 이러한 회의는 때로는 아무런 실질적 피드백 없이 단순히 의무적으로 진행되기도 합니다.

게다가 끝없이 이어지는 스프린트 계획 회의, 백로그 정리 회의는 개인 간의 상호작용을 뒷전으로 밀어내고, 팀원들이 진정으로 협력할 시간을 빼앗습니다. 결국 이러한 구조는 애자일의 철학과 멀어지게 만듭니다.

---

4. 더 나은 애자일 실천을 위한 제안

애자일의 본질을 살리기 위해 스크럼의 고정된 형식을 벗어난 접근 방식을 고려해볼 수 있습니다. 아래는 제안하는 방법들입니다.

1. 작업 분할
   • 작업을 프로젝트의 필요에 맞게 자연스러운 덩어리로 나눕니다. 크기가 다르더라도 상황에 맞게 조정이 가능합니다.
2. 유연한 일정 관리
   • 각 덩어리에 필요한 시간이 처음 예상과 다를 수 있음을 인정하고, 시간에 얽매이지 않습니다.
3. 즉각적인 방향 전환
   • 상황 변화로 인해 작업의 우선순위가 바뀌면 즉시 새로운 방향으로 조정합니다.
4. 주기적 검토와 피드백
   • 특정 날짜가 아니라 적절한 시점에 지금까지의 작업을 검토하고 이해관계자에게 피드백을 요청합니다.
5. 최적의 작업 환경 조성
   • 회의보다 개인과 상호작용, 그리고 작업의 본질에 집중하도록 환경을 개선합니다.

이러한 접근은 본질적으로 유연성과 기민함을 기반으로 하며, 애자일 원칙에 더 가깝게 다가갈 수 있습니다.

---

5. 애자일 선언의 원칙 이해하기

애자일 선언은 네 가지 핵심 가치를 중심으로 12가지 원칙으로 구성되어 있습니다. 이 선언의 핵심은 다음과 같습니다.

• 가치의 중심
  1. 개인과 상호작용이 프로세스와 도구보다 중요하다.
  2. 작동하는 소프트웨어가 포괄적인 문서보다 중요하다.
  3. 고객과의 협력이 계약 협상보다 중요하다.
  4. 변화에 대응하는 것이 계획을 따르는 것보다 중요하다.
• 12가지 원칙
  1. 고객 만족을 최우선으로, 지속적이고 빠르게 가치 전달.
  2. 변화하는 요구사항을 수용.
  3. 작동하는 소프트웨어를 자주 전달.
  4. 개발자와 비즈니스의 협력.
  5. 동기 부여된 개인 중심의 프로젝트.
  6. 대면 커뮤니케이션 우선.
  7. 작동하는 소프트웨어를 진척의 주요 척도로 간주.
  8. 지속 가능한 개발 보장.
  9. 기술적 우수성과 설계 향상을 통한 민첩성 증대.
  10. 단순함 유지.
  11. 자기 조직화된 팀.
  12. 정기적으로 성찰하고 개선.