반응형
반응형

변혁을 이끄는 CIO는 혁신 달성, 비즈니스 영향력 확대, 운영 및 보안 위험 감소에 있어 IT 문화가 중요하다는 점을 알고 있다. 견고한 IT 문화가 없다면 IT팀이 일상 ‘비즈니스 운영’ 책임을 넘어 비즈니스 부서 동료, 데이터 과학자, 파트너와의 협력하는 영역으로 확장하도록 동기를 부여하기가 어렵다.

고성과 팀 문화 조성에 관한 데일 카네기(Dale Carnegie) 연구에 따르면, 리더와 구성원이 팀 문화를 보는 방식에 차이가 있었다. 리더의 73%는 팀의 책임감 문화가 ‘매우 좋음’ 이상이라고 평가한 반면, 같은 응답을 한 팀원은 48%에 그쳤다. 또한 리더의 84%가 조직의 팀워크가 강하다고 믿었지만, 팀원은 60%만이 동의했다.

높은 성과를 내는 팀을 육성하고, 유능한 인재를 채용 및 유지하고, 디지털 KPI를 꾸준히 개선하는 것이 견고한 IT 문화의 특징이지만, 이런 지표는 CIO가 추진하는 문화 개선 프로그램의 실제 효과를 즉각 반영하지 못하는 경우가 많다. 더욱 우려되는 점은 IT 문화를 저해하는 요인들이 KPI나 직원 만족도 조사에서 수개월 동안 드러나지 않을 수 있다는 것이다.

경험상 CIO는 대개 올바른 의도를 가지고 있지만, 때로는 의도치 않은 실수를 저질러 IT 문화를 해칠 수 있다. 최근 ‘CIO가 우려해야 할 5가지 IT 리스크’에 관한 기사에서도 팀 소진, 기술 부채 증가, 계속되는 위기 관리 등 몇 가지 IT 팀 문화 문제를 강조한 바 있다. CIO가 IT 문화를 해치는 10가지 길과 이를 방지하는 방법을 소개한다.

마이크로매니지먼트 또는 명령 및 통제에 의존
클라리오(Clario)의 EVP 겸 정보기술제품 책임자인 제이 페로는 “마이크로매니지먼트(micromanagement)는 IT 문화를 파괴하는 가장 빠른 방법”이라고 말했다. 그는 “CIO가 팀의 의사결정을 믿지 않거나 모든 세부 사항을 감시할 때 창의성과 혁신은 저해된다. 고성과 전문가는 자율성을 원하며, 마이크로매니지먼트로 인해 숨이 막힌다고 느끼면 업무에 몰입하지 않거나 더 나은 환경을 찾아 떠날 것”이라고 진단했다.

경험 많은 CIO는 명령과 통제 방식을 지양하지만, 혁신을 달성하고 기한을 맞춰야 하는 압박 속에서 이를 피하기는 어려울 수 있다. 이런 압박에 굴복하는 대신, 다음과 같이 협력하는 접근 방식을 고려해야 한다.

경직된 배포 로드맵을 피하고, 집중할 가치가 있는 성과 개선 영역을 강조하며, 주요 릴리스 이후에는 팀이 재정비할 시간을 제공함으로써 애자일 팀에게 권한을 부여하고 영감을 불어넣는다.
팀이 릴리스 약속을 얼마나 잘 이행하는지, 설계 동료 검토를 얼마나 장려하는지, 그리고 실험의 영향을 어떻게 입증하는지를 통해 소프트웨어 개발자의 영향력을 측정한다.
팀 리더, 엔터프라이즈 아키텍트, 제품 관리자가 모범 사례를 장려하고 설계 원칙을 수립하는 자체 표준 개발을 촉진한다.
의견을 구한 뒤 피드백 무시
CIO가 세세하게 관리하지 않더라도 IT 직원들은 리더가 자신의 피드백과 제안을 경청하지 않는다는 사실을 쉽게 알아차릴 수 있다.

텐엑스뉴코(10Xnewco)의 성장 전략가이자 임시 CIO인 조 푸글리시는 “‘당신의 의견이 중요하다’라는 생각을 철칙으로 삼고 있지만, 팀의 의욕을 꺾고 사기를 저하시키고 싶다면 의견을 구한 뒤 계속 무시하면 된다. 곧 직원들은 침묵하고 좌절하게 될 것”이라고 전했다.

CIO는 즉시는 아니더라도 의견과 피드백에 응답해 문화를 망치는 길을 피할 수 있다. 우수한 리더는 들은 내용을 다시 언급하고 관리 도구에 피드백을 기록한다. 이를 통해 리더는 옵션을 검토하고, 피드백이 변화를 이끌어낸 시점을 보여주며, 직원의 의견에 관심을 갖고 있음을 보여줄 수 있다.

하이브리드 근무 및 일과 삶의 균형 무너뜨리기
CIO가 IT 직원의 의견을 수렴해야 하는 분야 중 하나가 하이브리드 근무, 원격 근무 및 관련 정책이다. 일과 삶의 균형에 관한 직원의 목표와 회사 정책 간의 충돌, 또는 리더가 근무 원칙을 강요하면 IT 문화를 해칠 수 있다. 이런 갈등은 일과 삶의 균형을 우선순위로 꼽는 젊은 인력에게 특히 큰 영향을 미친다. 딜로이트의 ‘2024년 Z세대와 밀레니얼 세대’ 조사에 따르면 Z세대가 조직을 선택하는 3가지 주요 이유는 일과 삶의 균형, 학습과 발전 기회, 긍정적인 업무 문화였다.

시스코 콜라보레이션(Cisco Collaboration)의 SVP 겸 총괄 매니저인 아누라그 딩그라는 “인재는 모든 조직에 경쟁 우위를 제공하는 핵심 차별화 요소다. 리더는 직원에 집중해야 한다. 하이브리드 근무나 사무실 복귀 정책에 신중하지 않으면 일부 인재 계층을 소외시킬 수 있다. 직원들은 팀과 소통하고 창의적인 작업을 하고 싶을 때 사무실에 출근할 수 있기를 희망하지만, 동시에 집중이 필요한 업무 시간도 원한다”라고 말했다.

따라서 CIO는 인사 책임자와 협력해 직원 경험 개선을 주도해야 하며, 특히 IT 근무 환경이 다른 부서와는 차별화될 필요가 있는 경우라면 더 그렇다.

변화를 이끌 실용적 비전의 부재
커넥티드마인즈(Connektedminds)의 CEO이자 박사인 조앤 프리드먼은 “모든 혁신은 미래 지향적이며 디지털 비즈니스로서 달성하고자 하는 성과를 명확히 표현해야 한다”라고 말했다. 그는 “CIO는 큰 그림을 그리고, 세부 사항까지 리버스 엔지니어링하도록 팀을 이끈 다음, 이를 변화를 이끄는 실용적인 비전으로 다시 전달해야 한다”라고 조언했다.

프리드먼이 실용적 비전의 중요성을 강조하는 이유는 다음과 같다.

명확한 미션과 비전이 없으면 IT 팀은 자신들의 노력이 조직의 성과에 어떤 영향을 미치는지 알 수 없어 문화가 저해된다.
모호한 비전을 전달하면 팀이 조직의 목표를 추측해야 하고, 조직의 우선순위를 해석하는 과정에서 비효율이 발생한다.
지나치게 상세한 비전은 팀을 차선책에 가두고 혁신의 자유를 제한할 수 있다.
우수한 CIO는 IT 팀, 직원, 이해관계자, 경영진이 변화를 실험하고 추진하는 데 영감을 주는 혁신 비전의 일부로 IT를 재정립한다. 또한 이런 CIO는 IT 팀이 최종 사용자의 채택을 주도하고, 피드백을 수집하며, 솔루션을 꾸준히 개선하도록 이끌어 디지털 트랜스포메이션의 변화 관리 실수를 피한다.

과도한 약속과 보호받지 못하는 팀
혁신을 추구하는 CIO가 직면하는 주요 어려움은 더 많거나 큰 규모의 이니셔티브를 맡고 임박한 기한에 맞춰야 한다는 요구 사항이다. IT가 합리적으로 달성 가능한 수준 이상을 약속하는 것도 문제지만, 이해관계자들이 좌절하거나 경영진이 진행을 방해할 때 CIO가 프로그램 리더를 무방비 상태로 방치하는 것도 IT 문화를 망치는 길이다.

듀넬름 어소시에이츠(Dunelm Associates)의 매니징 파트너인 마틴 데이비스는 “IT 팀 역량과 관계없이 모든 비즈니스 요청에 CIO가 동의하고 IT 전략이나 방향성이 부족할 때 IT 사기가 저하된다. 하지만 실망하거나 화를 내는 비즈니스 고위 경영진과 이해관계자로부터 팀을 보호하지 않을 때 IT 문화는 완전히 파괴된다”라고 지적했다.

디지털 트랜스포메이션을 이끄는 뛰어난 CIO는 전략적인 우선순위에 대한 합의를 이끌어내고 추가 이니셔티브를 수행할 역량을 전달해 우선순위를 정한다. 모든 혁신 이니셔티브에는 디지털 리더십이 필요하다. 뛰어난 CIO는 더 큰 범위의 이니셔티브를 성공으로 이끌려면 디지털 트랜스포메이션을 주도할 인재 풀을 늘려야 한다는 사실을 알고 있다.

CIO는 혁신 리더와 팀이 화가 나거나 실망한 이해관계자 및 경영진을 혼자 상대하도록 방치해선 안 된다. 뛰어난 CIO는 어떤 변화가 필요한지 논의하고 되돌아보는 토론에 직접 참여한 다음, 혁신 리더가 비즈니스 이해관계자와 의미 있는 관계를 발전시키는 데 도움을 줄 방법을 고려한다.

이해관계자가 받아들이지 않는 애자일 문화 추진
회고(Retrospectives)는 애자일 스프린트 종료 시 팀이 성과와 개선 기회를 논의하기 위해 사용하는 의식과 같다. 실망하거나 화가 난 이해관계자가 있을 때는 대개 애자일에서 이해관계자의 역할, 제품 관리의 책임, 애자일 팀이 인식하는 성과 사이에 단절이 발생한 경우가 많다.

많은 CIO가 기술 구현 조직에 애자일 방법론을 도입했지만, 이는 “정시에, 범위 및 예산 내에서, 품질을 갖추는” 전통적인 프로젝트 관리 약속을 요구하는 이해관계자들의 생각과는 상당한 격차가 있을 수 있다. 디지털AI(digital.ai)의 17차 애자일 현황 보고서에 따르면, 설문 응답자의 약 절반(47%)은 비즈니스 부서에서 애자일을 채택하지 않는 이유로 조직 변화에 대한 ‘일반화된’ 반감이나 ‘문화 충돌’을 지적했다.

이해관계자 교육 없이 IT의 애자일 도입을 추진하면 문화를 해칠 수 있다. 변화 관리에 대한 책임이 팀에 전가되기 떄문이다. 애자일팀에게 이해관계자의 애자일 실천 방안 조율을 요구하면, 특히 팀이 조직의 변화 관리 문제를 다루는 데 숙련되지 않은 경우 생산성이 저하된다. 따라서 CIO는 애자일 관행 및 기타 디지털 트랜스포메이션 역량의 이유와 방법을 이해관계자에게 교육하는 조치를 취해야 한다.

전환과 전략 변화에 대한 소통 실패
CIO의 소통 문제도 IT팀의 문화 장벽이 될 수 있다. 경영진이 우선순위를 전환하거나 주요 조직 개편을 발표할 때, CIO는 포럼을 열고 변경 사항을 전달해 유대를 다져야 한다. 원래 목표를 향해 열심히 일하던 IT팀은 변화가 일어나고 조직이 우선순위를 재설정한 이유에 의문을 가질 수 있다.

클라리오의 페로는 “CIO가 의도치 않게 의사 결정 ‘이유’를 소통하지 못한다면 IT 문화를 해칠 수 있다. 팀의 의견을 수렴하거나 투명성 없이 변화가 이뤄지면 불확실성과 분노가 생긴다. 신뢰와 협력에 기반한 문화를 구축하려면 CIO가 열린 대화를 촉진하고 팀이 회사의 더 큰 비전을 이해하고 조율할 수 있도록 지원해야 한다”라고 설명했다.

뛰어난 CIO는 소통 전략을 세우고 팀과 정기적으로 대화를 계획한다. 팀이 피드백과 아이디어를 공유하도록 적극 경청하는 자세가 필요하다. 회사의 전략 방향에 대한 업데이트가 있을 때는 소식을 전하고 질문에 답할 포럼을 마련해야 한다.

기술 전문 용어의 과다 사용으로 신뢰도 하락
보안 개선, 인프라 업그레이드 또는 기술 부채 감소를 위해 경영진과 이사회를 설득하고 투자를 이끌어내지 못하는 CIO는 해당 업무로 매일 문제를 겪는 IT 직원의 사기를 떨어뜨릴 수 있다. CIO는 혁신 리더들을 멘토링할 때 모범을 보여야 한다. 특히 대규모 투자 제안을 준비하는 과정에서는 전문 기술 용어 사용을 자제하고, 경영진이 이해하기 쉬운 언어로 설명해야 한다. 이를 통해 의사결정권자들이 비즈니스상 필요성을 명확히 이해할 수 있도록 해야 한다.

페이저듀티(PagerDuty)의 CIO인 에릭 존슨은 “CIO는 이사회 및 경영진과 소통할 때 기술 용어를 남발하는 실수를 자주 저지른다. CIO는 기술 개념을 비즈니스 성과로 표현해야 하며, IT와 기술팀의 중요 업무가 조직 내 다른 업무와 분리되지 않도록 해야 한다”라고 조언했다.

CIO는 이사회 회의에서 질문에 복잡하게 답변하거나 보안 투자를 설득할 때 공포를 유발하는 전술을 사용하는 등의 실수를 할 수 있다. 잘못된 소통은 신뢰도를 손상시키며 IT문화에 파급 효과를 가져올 수 있다.

존슨은 “소통 격차는 혁신을 저해할 뿐만 아니라 IT 이니셔티브와 더 넓은 비즈니스 목표 간 불일치를 초래한다. 이는 IT 문화를 약화시키고 기술을 진정한 비즈니스 혁신 동력으로 자리매김할 기회를 놓치게 할 수 있다”라고 말했다.

팀과 개인의 저조한 성과 용인
듀넬름 어소시에이츠의 데이비스는 “팀 분위기를 심각하게 저해하는 핵심 구성원에 대해 적절한 조치를 취하지 않는 것”이 문화를 해치는 주요 요인이라고 지적했다. 이는 다른 CIO들도 언급한 요인인데, 혼란과 저성과가 팀에 영향을 미치고 CIO의 우유부단한 대응이 신뢰를 손상시키기 때문이다.

클라리오의 페로는 “IT 문화를 해치는 해로운 주요 원인이 저성과자를 너무 오래 붙잡아두는 것이다. 낮은 기준이 용인될 때 고성과자들의 동기 부여는 약화되고 분노로 이어진다. CIO는 개선을 위해 필요한 지원을 제공하되, 전반적인 팀 분위기를 유지하기 위해 때로는 결단을 내릴 시점을 알아야 한다”라고 말했다.

저성과 관리 권장 사항에는 신속한 조치, 변경할 사항 명료화, 측정 가능한 개선 계획 수립, 성과 기준에 대해 팀과 소통하는 방법 등이 있다. CIO는 또한 성과 개선 계획을 관리할 절차를 인사 담당자와 상의해야 한다.

실수에 대한 책임 전가와 공로 독점
텐엑스뉴코의 퓰리시는 “공은 독차지하면서 실수는 팀원을 공개 지목하는 행위가 팀의 사기를 쉽게 꺾는다”라고 말했다.

중요한 교훈은 CIO가 팀 중심 접근 방식으로 리더십을 발휘해야 한다는 점이다. 문제에 대응하고, 최종 사용자 요청을 처리하고, 조직 보안 태세를 개선하고, 혁신을 제공하고, 디지털 트랜스포메이션을 주도하는 것이 바로 팀이다. CIO에게는 의욕적이고 꾸준히 발전하는 팀이 필요하다. 올바른 IT 문화를 구축하려면 실험하고 학습하며 성과를 내려는 열정을 조성해야 한다.

https://www.cio.com/article/3604847/%ec%82%ac%ea%b8%b0-%ec%a0%80%ed%95%98-%ec%8b%a0%eb%a2%b0%eb%8f%84-%ec%83%81%ec%8b%a4%c2%b7%c2%b7%c2%b7-it-%eb%ac%b8%ed%99%94%eb%a5%bc-%eb%a7%9d%ec%b9%98%eb%8a%94-%ea%b8%b8-10.html

 

‘사기 저하, 신뢰도 상실’··· IT 문화를 망치는 행동 10가지

세세한 참견부터 실용적 비전 부재에 이르기까지, IT 리더는 비즈니스 성과를 창출할 IT 문화 조성에 의도치 않게 악영향을 미칠 수 있다.

www.cio.com

 

 

반응형
반응형

경영진이 긴 프로젝트 일정, 불명확한 요구사항, 마감 기한 미준수에 지쳐 있을 때, 애자일은 더 빠른 구현, 높은 유연성, 비즈니스 요구사항과의 긴밀한 연계를 보장해 전략을 신속히 실현하고 ROI를 높일 해결책처럼 보였다. 하지만 현재 많은 기업이 가시적인 성과 부족에 실망하며 애자일 팀을 해체하고 있다.

애자일의 실패는 방법론 자체의 문제가 아니었다. 진짜 문제는 조직 내부 깊숙이 자리 잡은 전략과 실행의 불일치였다. 전략과 실행을 연계하지 못하면 애자일, 워터폴, 하이브리드 등 어떤 구현 방식도 근본적인 문제를 해결할 수 없다. 애자일이나 다른 접근 방식의 이점을 누리려면 기업은 전략을 정의하고 실행하는 방식부터 개선해야 한다. 조직의 애자일 전환이 실패하는 5가지 이유를 소개한다.

방법론에 치중하고 전략에 소홀

애자일 전환을 시도하는 대부분의 조직은 데일리 스탠드업, 스프린트 계획, 회고, 제품 백로그와 같은 방법론에 지나치게 집중한다. 이런 애자일 관행은 이니셔티브 수행 구조를 제공하지만 더 깊은 문제는 해결하지 못한다. 진정한 과제는 실행 방법이 아니라 전략과 실행을 연계해 목표 비즈니스 성과를 달성하도록 보장하는 일이다.

 

애자일은 잘못 설정된 전략이나 리더십 팀의 전략 표현 및 실행 연계 능력을 개선할 수 없다. 전통적인 프로젝트 관리처럼 애자일은 단순히 도구이자 수단일 뿐, 그 자체가 목적이 아니다. 전략이 명확하지 않고, 우선순위가 정해지지 않았으며, 제대로 전달되지 않는다면 아무리 의도가 좋은 애자일 팀도 어려움을 겪을 수밖에 없다. 이들은 경영진이 기대하는 비즈니스 가치를 창출하지 못한 채 끊임없이 반복한다. 문제는 일하는 방식이 아니라 일하는 내용에 있다.

잘못된 우선순위와 리소스 혼란

사람들은 흔히 애자일이 리소스 충돌과 팀 효율성 문제를 자동으로 해결해 준다고 오해한다. 하지만 리더십이 전략적 우선순위를 명확하게 설정하지 않으면 애자일은 오히려 혼란을 가중시킨다.

애자일 팀이 스프린트 단위로 결과물을 내더라도, 조직이 이니셔티브의 우선순위를 정하지 않으면 리소스는 여전히 중요도가 낮은 프로젝트에 분산된다. 팀은 끊임없이 작업을 전환하고 새로운 우선순위를 쫓아다니며 실제로 작동하지 않는 결과물을 제공하기 쉽다.

 

애자일은 이 문제를 해결할 수 없다. 어떤 방법론도 마찬가지다. 해결책은 리더십의 명확한 우선순위 설정이다. 다시 말해 어떤 프로젝트가 중요하고 어떤 프로젝트를 기다릴 수 있는지 결정해야 한다. 이는 리소스 관리가 아니라 우선순위 설정 문제다. 모든 일을 한꺼번에 하려고 하면 어느 하나도 제대로 할 수 없다.

완벽주의의 함정

애자일 팀은 반복에 갇혀 실질적인 진전 없이 프로세스나 기능을 개선하는 데 매몰될 위험이 있다. 완벽한 코드 작성이나 요구사항 목록 완성과 같은 산출물에 집착하다 보니 비즈니스 가치 창출이 지연된다.

많은 팀이 애자일 전문성을 인정받아 채용됐기 때문에 결과 도출보다는 방법론을 따르는 데 가치가 있다고 믿는다. 진정한 성공이 무엇인지 명확하게 이해하지 못하면 프로세스 완벽주의의 순환에 빠진다. 그러면 애자일이 의미 있는 성과를 달성하기보다는 프레임워크를 준수하는 데만 치중하게 된다.

 

사고방식 전환의 부재

애자일이나 다른 방법론의 진정한 잠재력을 끌어내려면 사고방식의 명확한 전환이 필요하다. 리더는 조직이 달성하려는 목표를 분명히 해야 한다. 프로젝트가 완료됐을 때 성공이란 어떤 모습이며, 비즈니스 목표에 미칠 영향은 무엇일지 파악해야 한다. 핵심 성과 목표를 정의하면 유능한 팀은 획일적인 프로세스를 따르지 않고도 목표에 도달하는 최선의 방법을 찾아낼 수 있다.

전략과 실행의 분리

애자일은 전략과 실행을 분리해 생각하지 않을 때만 효과가 있다. 하지만 대부분의 조직은 이를 별개의 단계로 취급한다. 전략은 경영진이 정의하고 이를 딜리버리 팀에게 전달해 실행하게끔 한다. 처음부터 연계가 없다면 아무리 좋은 구현 방법이라도 성공하기 어렵다. 전략이 명확히 정의되고, 효과적으로 전달되며, 생산적인 방식으로 실현되도록 하는 데 아무도 집중하지 않기 때문이다.

애자일이 성공하려면 전략, 실행, 실현을 연속 및 반복되는 프로세스로 통합해야 한다. 비즈니스 목표를 명확히 정의하고, 실행에 참여하는 모든 사람이 목표를 이해하며, 프로세스가 아닌 결과로 성공을 측정해야 한다. 모든 구성원이 성과를 중심으로 하면, 애자일은 실행을 간소화하고 더 빠르게 가치를 창출할 수 있다.

 

https://www.cio.com/article/3594947/%ec%b9%bc%eb%9f%bc-%ec%95%a0%ec%9e%90%ec%9d%bc-%ec%a0%84%ed%99%98%ec%9d%b4-%ec%8b%a4%ed%8c%a8%ed%95%98%eb%8a%94-%ec%9d%b4%ec%9c%a0-5%ea%b0%80%ec%a7%80.html

반응형
반응형

 

애자일 원칙 

Agile Principles(애자일 12가지 원칙)

 

https://medium.com/hgmin/agile-principles-%EC%95%A0%EC%9E%90%EC%9D%BC-12%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-d3f386bd9839

 

Agile Principles(애자일 12가지 원칙)

고객과 시장의 변화에 빠르게 대처하며 Agile하게 일하기 위한 12가지 원칙에 대해서 소개합니다.

medium.com

 

Agile은 일을 빠르게 하기 위해서가 아니라, 고객과 시장의 변화에 빠르게 대처하기 위한 방법입니다. Agile하게 일하기 위한 12가지 원칙에 대해서 소개합니다.

초기에 확정된 일을 그대로 한다면 Waterfall이 더 나은 방법일 수 있지만, 초기부터 동작되는 소프트웨어를 만들어 시장에 적용/학습/개선하기 위해서는 Agile 방식이 더 나은 방법입니다.

Agile Manifesto(선언문)

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Agile Principles(원칙)

Agile 선언문을 따르기 위한 12가지 원칙들

https://www.visual-paradigm.com/scrum/agile-manifesto-and-agile-principles/

반응형
반응형

“애자일은 대형 프로젝트에서 안돼”



스크럼, XP, 린 S/W 개발 등은 7~9명 단위의 작은 팀을 기반으로 설명되어 있었고, 이 인원으로 최고의 생산성과 품질을 낼 수 있다 라고 언급하였다. 그나마 스크럼 프로세스 정도가 여러 스크럼 팀으로 확장 될 때 작은 팀들을 여러개 만들고 이를 스크럼의 스크럼이라는 형태의 회의로 이슈를 해결하면 된다라는 확장에 대한 고민을 담았다.

하지만 심지어 스크럼 조차도 개발 외에 요구사항을 받는 방법이라던지, 릴리즈의 구체적인 방법에 대한 언급은 없었기 때문에, 규모가 큰 프로젝트에서 적용하는데는 제약이 있다는 생각들이 많았다.
그 때문이었을까… 십년 이상동안 대형 프로젝트에서 애자일을 활용하는 극복의 과정은 꽤나 고통스러웠다.

작은 팀 위주에 초점을 맞추던 기존의 프랙티스에서 벗어나 대형 프로젝트에 맞게 일부 변경된 시도를 하던 사람들에게는 많은 비난이 쏟아졌다.이전의 오리진(Origin)을 버리는 것이라 비난하는 이도 많았고 조금이라도 문서화에 초점을 맞추면 “이건 애자일이 아냐” 라고 비난하는 사람들이 생겨났다. “무늬만 애자일”, “하이브리드”, “미니워터폴” 등 다양한 용어들로 변형된 프로세스에 대해 부정적이었다.

하지만,이에 대한 변화는 결국 시장이 주도하게 되는데, 기존 프로세스에 대한 불만과 클라우드로 전환하는 시장의 흐름에 따라, 애자일의 확산 니즈는 점점 커졌다. 이와 함께 애자일 또한 일반화/정형화/대중화 되기 위한 움직임들이 나타났다.

그리고 다양한 조직의 더 많은 사람들이 애자일 방식을 기반으로 한 나름대로의 프로세스를 만들어 나갔다. 기존의 한계를 극복하며 현실적인 접근을 시도했던 것이다.

이의 대표적인 프로세스가 DaD(Disciplined Agile development), SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum) 등이다. 심지어 SAFe는 미국 정부를 비롯하여 애자일을 하는 회사의 50%이상이 활용할 정도로 큰 인기를 얻고 있는 애자일 프로세스이다.



<SAFe(Scaled Agile Framework):150명 이상의 Portfolio 관리가 필요한 대형 애자일 방식>




<LESS(Large Scaled Scrum): MAX 80명 애자일 조직을 대상으로 수행하는 대형 스크럼방식>




이러한 프로세스는 기존의 도그마(Dogma: 독단적인 학설, 이성적으로 증명되지 않은 가설)라고 이야기 되던 순수 애자일 추구에서 벗어나 현실속에서 기존 문화와 다양한 프랙티스들을 섞는 것을 시도하는 내용들이 담겨 있었다. 시장 상황, 이해관계자들의 일해오던 방식 등을 일부 존중하면서, 애자일 방식을 통해 가치를 얻을 수 있는 중간 단계의 무엇인가를 찾는 노력들이 있었다.


이에, 디지안 씽킹으로 대표되는 디자인 방식의 변화, 린스타트업으로 대표되는 스타트업 바람이 더해져 바탕으로 이제는 소프트웨어 회사의 94%이상이 본인들은 애자일을 하는 회사라 말하고 있다.




<버젼원의 리포트2016: 애자일을 수행하는 회사가 94%라는 설문 결과>


전체적으로 스펙트럼이 소/중/대형을 넘나드는 애자일 방식들이 생겨나게 된 내용은 지금까지 설명한 바와 같다.


그렇다면 과거의 소규모를 향한 애자일과 중/대형 사업의 애자일과의 구체적인 차이는 무엇일까? 현실과 맞물린 일하는 방법이란 과연 무엇일까?


이를 효과적으로 설명하려면 2001년의 애자일 선언을 가지고 이야기 하면 좋다.



과거 작은 팀을 중심으로 진행하는 애자일 방식은 오른쪽 노란색 부분은 마치 금기처럼 무시하려는 분위기가 강했다. 그래서 조금이라도 오른쪽에 접근하는 것을 경계했다.


하지만 현실과 맞물리며 대형 프로젝트 같은 경우, 왼쪽보다는 확실히 덜 중요하나 오른쪽 부분 또한 중요하다는 인식으로 발전되어 갔다.


이를 설명하면 다음과 같다.


1. 대규모 프로젝트(50명 이상)에서 개인과 상호작용만 강조하면, 두 개이상의 팀이 되었을 때 효과적인 커뮤니케이션을 하기 힘들다 때문에 툴을 사용하는 것이 좋다


2. 동작하는 소프트웨어에만 집중하면 팀 내에서는 진행상황에 대해 잘 이해할 수 있으나 두 개이상의 팀이 되었을 때 서로의 진행사항을 확인하기 어렵다. 애자일팀들이 아주 쉽게 말하는 “우리팀에 와서 언제든 제품을 보세요” 라는 말은 2팀 이상을 봐야 하는 관리자에게는 눈살을 찌푸리게 만드는 대화가 될 수도 있다. 때문에 적당한 문서화는 커뮤니케이션에 도움이 될 수 있다.


3. 고객과의 협업만 강조하면 다양한 이해관계자를 모두 포용하지 못할 수 있다. 때문에 계약과 협상 을 통해 전체 이해관계자와 동일한 비전/생각을 갖으며 일을 해야 한다.


4. 상황에 따라 변화를 하는 것은 중요하지만, 주변 팀에 이야기 하지 않으면 두 팀 이상이 될 경우 의존관계를 무시하게 되여 고객의 비즈니스 가치를 늦게 딜리버리하는 상황을 만날 수 있다.

혹시나 대형 프로젝트, 대규모 조직에서 애자일을 적용하다 현실의 벽에 부딪혀 고민하고 있는 독자가 있었다면 위 이야기를 듣고 반가운 생각이 들 수 있다.


하지만, 다시한번 강조하여 이야기 하고 싶다. 개인과 상호작용, 동작하는 소프트웨어, 고객과의 협업, 상황의 따른 변화가 여전히 더 중요하다. 그래야 애자일 방식이다.



...

반응형

+ Recent posts