애자일을 프로젝트에 적용하면 실패할까?
프로젝트의 실패 원인을 애자일에서 찾지는 말자
애자일은 방법론이라고 생각한다. 개인적으로 ‘방법론’이라면 개발을 하는 데 필요한 더 많은 요소를 포함하고 있어야 한다.
그런데 많은 사람들이 알고 있듯이, 일부 애자일 프레임워크를 제외하면 스크럼과 같은 경우에는 개발에 필요한 구체적인 방법론적 내용이나 절차에 대한 정의가 부족하다고 보는 것이 맞다.
그러다 보니 우리가 하는 개발에 스크럼을 적용하면, 시작 단계부터 혼란이 오게 된다.
당장 고객이 요구하는 기본 산출물인 요구사항 정의서나 설계 문서만 보더라도, 왠지 애자일스럽지 못하다는 생각이 들게 된다.
하지만 애자일은 이러한 부분을 규약화하지 않는다. 오히려 더 유연하게 접근하기 위한 방법이라고 보는 것이 적절하다.
개발을 위해 작성한 산출물이 실제 개발 단계에서 얼마나 활용되는지 돌아보면, 그 많은 산출물이 개발에 실질적인 도움이 된다고 보기는 어렵다.
초기에 만들어진 설계 문서는 실제 개발 단계에 이르면 상당 부분 의미를 잃는다.
심지어 요구사항 정의서 역시 변경 심의 과정을 거친다면, 프로젝트 중반 이후에는 일부 핵심 사항을 제외하고는 완전히 다른 모습이 되어 있는 경우가 많다.
애자일적 접근은 그래서 초반에 모든 것을 정의하기보다는, 진행하면서 필요한 만큼만 정의하는 데 초점을 둔다.
요즘은 기업들도 분위기가 많이 바뀌어 요구사항 변경을 일정 부분 수용하는 경향이 있다.
그럼에도 불구하고 여전히 막연한 압박감이 존재하고, 마치 해서는 안 될 일을 하는 듯한 죄책감을 느끼는 경우도 있다.
애자일을 프로젝트에 적용한다는 것은, 사실 따져 보면 결코 쉬운 일이 아니다.
아무리 고객과 협의가 되어 있다고 하더라도 쉽지 않다. 특히 프로젝트의 의사결정 권한을 가진 사람이 애자일을 이해하지 못하거나 관심이 없다면 더욱 그렇다.
또한 프로젝트에 참여하는 멤버들 역시 각자 맡은 일에만 집중할 뿐, ‘팀’이라는 개념이 부족한 경우가 많다.
팀을 단순히 함께 식사하거나 회식하는 관계로 인식하는 경우도 적지 않다.
하지만 애자일 팀은 ‘함께 일하는 것’에서 출발한다.
협업은 단순한 역할 분담이 아니라, 서로의 일을 함께 책임지는 개념이다.
크로스펑셔널 팀이 되기 위해서는 ‘누구의 일’이 아니라 ‘우리의 일’이라는 인식이 필요하다.
애자일을 프로젝트에 적용한다는 것은, 특정 개발 방법론을 틀에 맞게 적용하는 것이 아니라
소통과 변화에 적응하면서 최상의 서비스와 제품을 만들어 가기 위한 지속적인 노력이다.
그 과정에서 애자일의 가치와 원칙을 우선적으로 지키고,
일을 계획하고 수행하는 데 있어 애자일에서 제공하는 다양한 기법을 활용하는 것이 중요하다.
‘애자일을 프로젝트에 적용하면 실패할까?’라는 질문은,
어쩌면 애자일의 가치와 철학이 제대로 지켜진다면 성립하기 어려운 질문일지도 모른다.
우리는 종종 자신의 상황에 맞게 타협하고, 외부 요인에 책임을 돌리며, ‘나만 아니면 된다’는 생각으로 행동한다.
이러한 태도를 가진 팀원이 있다면, 그 순간부터 프로젝트는 이미 실패의 방향으로 가고 있는 것이다.
프로젝트는 어떤 방법론을 따르든지, 그 안에서 애자일이 추구하는 가치를 충분히 실천할 수 있다.
또한 수행 과정에서 애자일의 실천법을 적용한다면, 애자일을 도입했다는 이유만으로 실패할 일은 없다.
결국 문제는 애자일이 아니라,
책임을 회피하려는 태도와 순간을 모면하려는 생각일지도 모른다.
결론적으로, 애자일이 문제인지 스스로에게 물어보기 전에
우리는 다음과 같은 질문을 던져야 한다.
“나는 지금 제대로 협업하고 있는가?”
“나는 변화에 열려 있는가?”
“나는 더 나은 방법을 고민하고 있는가?”
혹시 ‘예전에는 이렇게 하지 않았는데’라는 생각이 머릿속을 맴돌고 있다면,
이미 변화에 저항하고 있는 상태일지도 모른다.
그보다는
“이보다 더 나은 방법은 없을까?”
라고 고민하는 사람이 되기를 바란다.
<정재용> | <대표코치> | <AGIN>
애자일을 프로젝트에 적용하면 실패할까?
프로젝트의 실패 원인을 애자일에서 찾지는 말자
애자일은 방법론이라고 생각한다. 개인적으로 ‘방법론’이라면 개발을 하는 데 필요한 더 많은 요소를 포함하고 있어야 한다.
그런데 많은 사람들이 알고 있듯이, 일부 애자일 프레임워크를 제외하면 스크럼과 같은 경우에는 개발에 필요한 구체적인 방법론적 내용이나 절차에 대한 정의가 부족하다고 보는 것이 맞다.
그러다 보니 우리가 하는 개발에 스크럼을 적용하면, 시작 단계부터 혼란이 오게 된다.
당장 고객이 요구하는 기본 산출물인 요구사항 정의서나 설계 문서만 보더라도, 왠지 애자일스럽지 못하다는 생각이 들게 된다.
하지만 애자일은 이러한 부분을 규약화하지 않는다. 오히려 더 유연하게 접근하기 위한 방법이라고 보는 것이 적절하다.
개발을 위해 작성한 산출물이 실제 개발 단계에서 얼마나 활용되는지 돌아보면, 그 많은 산출물이 개발에 실질적인 도움이 된다고 보기는 어렵다.
초기에 만들어진 설계 문서는 실제 개발 단계에 이르면 상당 부분 의미를 잃는다.
심지어 요구사항 정의서 역시 변경 심의 과정을 거친다면, 프로젝트 중반 이후에는 일부 핵심 사항을 제외하고는 완전히 다른 모습이 되어 있는 경우가 많다.
애자일적 접근은 그래서 초반에 모든 것을 정의하기보다는, 진행하면서 필요한 만큼만 정의하는 데 초점을 둔다.
요즘은 기업들도 분위기가 많이 바뀌어 요구사항 변경을 일정 부분 수용하는 경향이 있다.
그럼에도 불구하고 여전히 막연한 압박감이 존재하고, 마치 해서는 안 될 일을 하는 듯한 죄책감을 느끼는 경우도 있다.
애자일을 프로젝트에 적용한다는 것은, 사실 따져 보면 결코 쉬운 일이 아니다.
아무리 고객과 협의가 되어 있다고 하더라도 쉽지 않다. 특히 프로젝트의 의사결정 권한을 가진 사람이 애자일을 이해하지 못하거나 관심이 없다면 더욱 그렇다.
또한 프로젝트에 참여하는 멤버들 역시 각자 맡은 일에만 집중할 뿐, ‘팀’이라는 개념이 부족한 경우가 많다.
팀을 단순히 함께 식사하거나 회식하는 관계로 인식하는 경우도 적지 않다.
하지만 애자일 팀은 ‘함께 일하는 것’에서 출발한다.
협업은 단순한 역할 분담이 아니라, 서로의 일을 함께 책임지는 개념이다.
크로스펑셔널 팀이 되기 위해서는 ‘누구의 일’이 아니라 ‘우리의 일’이라는 인식이 필요하다.
애자일을 프로젝트에 적용한다는 것은, 특정 개발 방법론을 틀에 맞게 적용하는 것이 아니라
소통과 변화에 적응하면서 최상의 서비스와 제품을 만들어 가기 위한 지속적인 노력이다.
그 과정에서 애자일의 가치와 원칙을 우선적으로 지키고,
일을 계획하고 수행하는 데 있어 애자일에서 제공하는 다양한 기법을 활용하는 것이 중요하다.
‘애자일을 프로젝트에 적용하면 실패할까?’라는 질문은,
어쩌면 애자일의 가치와 철학이 제대로 지켜진다면 성립하기 어려운 질문일지도 모른다.
우리는 종종 자신의 상황에 맞게 타협하고, 외부 요인에 책임을 돌리며, ‘나만 아니면 된다’는 생각으로 행동한다.
이러한 태도를 가진 팀원이 있다면, 그 순간부터 프로젝트는 이미 실패의 방향으로 가고 있는 것이다.
프로젝트는 어떤 방법론을 따르든지, 그 안에서 애자일이 추구하는 가치를 충분히 실천할 수 있다.
또한 수행 과정에서 애자일의 실천법을 적용한다면, 애자일을 도입했다는 이유만으로 실패할 일은 없다.
결국 문제는 애자일이 아니라,
책임을 회피하려는 태도와 순간을 모면하려는 생각일지도 모른다.
결론적으로, 애자일이 문제인지 스스로에게 물어보기 전에
우리는 다음과 같은 질문을 던져야 한다.
“나는 지금 제대로 협업하고 있는가?”
“나는 변화에 열려 있는가?”
“나는 더 나은 방법을 고민하고 있는가?”
혹시 ‘예전에는 이렇게 하지 않았는데’라는 생각이 머릿속을 맴돌고 있다면,
이미 변화에 저항하고 있는 상태일지도 모른다.
그보다는
“이보다 더 나은 방법은 없을까?”
라고 고민하는 사람이 되기를 바란다.
<정재용> | <대표코치> | <AGIN>