애자일은 스크럼이 아니다. – Agile is NOT SCRUM

Agile 관련 거의 대부분의 강의에서 Scrum을 가르칩니다. 추측하건대, Agile이 소프트웨어 개발 방법론으로 써 실체화 된 것이 별로 없기 때문일 것입니다.  이 글은 Scrum은 Agile이 맞지만 Agile이 Scrum이 아니라는 당연하지만 몰랐던 사실을 알려줍니다.

Agile Vs. Scrum

아래는 원문의 번역 문입니다.

Agile is not scrum

원문: http://ouragilejourney.com/2013/11/12/agile-is-not-scrum/ , Posted by adammyhr

Agile에 관한 정보를 찾을 때, 소프트웨어 개발이 가장 공통적인 산업으로 묘사된다. 그 결과 내에서 종종 Scrum이 구현으로 사용된다. Agile에 관해 일반적인 수준에서 말하고자 하는 많은 기사들은 Scrum으로부터 용어들을 사용한다. 이것의 공통적인 부작용은 많은 사람들이 Agile과 Scrum 같은 레벨로 연관 짓는다는 것이다. 이것이 문제다.

Agile is flexible.

Agile에 관한 학습과정에서 나는 주요 개념 중에 하나는 모르는 것을 모른다는 것을 깨닫게 되었다. 우리는 프로젝트를 진행하면서 새로운 정보가 생기게 될 것이다. Agile을 하면서 우리는 그것을 솔직히 인정한다. 우리는 프로젝트 시작에 필요한 최소한의 정보가 있을 때 프로젝트를 시작한다. 우리는 자주 우리가 그 길을 따라 어떤 변화와 함께 무엇을 배웠는지 보기 위해서 자주 휴식을 취한다. 가장 중요한 것은, 우리는 그들이 그 프로젝트 또는 우리의 프로세스로 존재하는지에 따라 그런 변화들이 일어나는 것을 용인할 수 있다.

Scrum is well-defined.

Scurm을 고려하기 위해서는 반드시 준수되어야 하는 매우 구체적인 규칙이 있다. 만일 그것들 중 어떤 것이라도 놓치고 있다면, Scrum은 진정으로 자리를 잡지 못하는 것이다. 만일 그것들 중 어떤 것들이라도 명목상으로만 존재한다면 “Scrum-but(나쁜 Scrum-Scrum의 역기능)”이 자리를 잡은 것이다.  Scrum을 하기 위해서 필요한 것의 전체는 16 page(https://www.scrum.org/scrum-guide) 가이드 또는 20 page primer(http://scrumfoundation.com/library)로 요약할 수 있다. 그 이상도 그 이하도 Scrum을 위해서 요구되지 않는다.

Agile guides decision.

Agile의 핵심은 Agile Manifesto(http://www.agilemanifesto.org/) 에서 말하고 있는 가치들이다. 소프트웨어 개발을 위해 정의된 Agile의 다음 단계로 파고드는 것은 12가지 원칙(http://www.agilemanifesto.org/principles.html) 이다. 그 가치들 또는 원칙 중 어떤 것에서 행동을 위한 칙령(지침서)가 없다. 그 가치와 원칙의 그들 모두 의사결정의 선두에서 유지하기에 이상적이다. 그 가치와 원칙은 작업을 성취하기 위해 그 방법을 사용되기를 강요하는 것이 아니고 프로젝트가 목표를 위해 진행되는 방법을 다듬는다는 의미이다.

Scrum dictates process structure.

Scrum의 핵심은 역할들, 이벤트, 결과물의 집합이다. 사람들이 프로젝트에서 수행하는 역할들은 3개로 이름이 지정된 위치 중 하나로 통합되었다. 매 이터레이션마다 개최되어야 하는 특별한 미팅이 있다. 직업은 반드시 어떤 특정한 방식으로 구조화(Structured) 되어야 하고, 대기(Queued)되어야 한다.  그 정의된 Shell 안쪽이 Scrum이고, 그 바깥쪽은 다른 것이다.

Agile is a way of thinking.

Agile사고는 어떤 프로젝트든 혜택을 받을 수 있다. Agile사고는 많은 다른 작업환경에서도 할 수 있는 것이다. 응급실은 Kanban 과 같은 방법을 사용하여 Agile 프로젝트를 실행할 수 있다. Agile 사고는 변화로의, 향상으로의, 개선으로의 열린 사고이다.   Agile 사고 끈을 현실적으로 넓게 해준다.

Scrum is a framework for getting work done.

Scrum은 상품 개발, 특히 소프트웨어 개발에 특화되어 있다. Scrum은 유연성을 허용하지만 오직 그 프레임워크 안에서만 가능하다. 그 프레임워크 밖에 있는 어떤 것도 Scrum에 부가물이다. 그 프레임워크를 악화시키지만 않는 다면, 용인된다. 프레임워크에서 어떤 것이든 제거된다는 것은 더 이상 Scrum이 아니라는 의미이다.

Scrum is Agile but Agile is not Scrum.

모든 Fords 가 자동차이지만, 모든 자동차가 Fords는 아니다. Scrum은 Agile이지만 Agile은 Scrum이 아니다. Scrum은 알맞게 사용될 때 Agile 이다. Scrum은 거듭되는, 짧은 피드백 주기, 계속되는 향상을 가능하게 하고, 그것을 필요로 하는 모든 사람들에게 투명함을 준다. Agile은 더 많은 것을 가능하게 한다. Agile은 최선의 가치가 고객에게 전달되기를 요구되어지기 때문에 그 프레임워크가 변화하는 것을 용인한다. Agile은 정해진 역할들의 앞에 있는 것을 용인한다.

Scrum은 Agile Journey(Agile을 하는 것은 프로세스 이기 때문에)를 시작하기에 좋은 위치이다. 그것은 개념이 간단하다. 그것은 넓게 퍼져 있고 지난 10년간 많은 성공을 보여주었다. 그것은 잘 이해되었고, 그 이점은 쉽게 조직들에게 큰 부분에서 설명되었다. Scrum의 구조는 조사할 수 있고, 매울 짧은 시간 안에 조직에 자리를 잡을 수 있다. Agile 코치로써 나는 모든 소프트웨어 개발 환경에서 착수시점에 Scrum을 기초로 한다. 종료지점에는 비록, Agile은 Scrum 보다 더 중요해질 필요가 있다. Scrum은 작동할 것이다. 그것이 최선의 솔루션이 되도 같다. High-performing 으로 향하는 팀의 경향은, Scrum의 프레임워크가 그 제품과 그 팀의 performance 향상에 제약이 되면 안 되는 것이다.  이런 이유 때문에, 비록 Scrum으로 시작하지만, Agile 코치로써 그냥 그것을 뻔뻔하게 대하는 것보다 많은 경우에서 순수 Scrum 위의 Scrum-but” 나쁜 Scrum-Scrum의 역기능”를 공개한다.