애자일 조직은 이렇게 일합니다

K-조직은 왜 애자일에 실패하는가 불확실성을 뚫고 성공하는 애자일 조직이 일하는 법 매일 수백만 명이 쓰는 토스의 송금 서비스와 쿠팡의 새벽배송은 수많은 실험과 실패에서 학습하는 피드백 루프에서 태어났다. 요즘 성과를 내는 조직은 처음부터 완벽한 서비스를 만들기보다는 서비스를 지속적으로 사용하는 유저의 리텐션을 높이는 데 집착한다. 이를 위해서는 실험이 필요하고 실패는 프로세스의 일부이다. 왜 수많은 조직이 애자일에 실패할까? 효과적인 애자일 조직의 목표는 ‘애자일’ 그 자체가 아니다. 수많은 실험과 실패에서 학습하는 피드백 루프를 만들어 불확실성을 뚫고 비즈니스에 성공하는 것이다. 저자인 스티브 매코널은 초기 애자일을 무조건적으로 좇던 강박에서 벗어나 비전과 우선순위에 따라 자율적으로 일하고 짧은 스프린트와 수직 슬라이스 배포로 성과를 내는 조직의 핵심 애자일 원칙 28을 설득력 있게 제시한다. 해결해야 하는 문제가 난해함보다 복잡함 영역에 있다고 얼마나 확신하는가? 이 책은 이에 따라 달라지는 요구사항의 생명 주기와 2주 단위의 단기 스프린트에도 상위 비즈니스 가치를 잃지 않는 스토리 매핑 전략으로, 성장 마인드셋을 갖고 있는 개인들이 함께 효과적으로 일하는 데 전념하는 조직이 되는 법을 알려 준다. 조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 조직에 알맞은 애자일 경계는 무엇인가? 세부사항이 아닌 성과를 관리하고 있는가? 촘촘한 피드백 루프로 학습을 가속화하고 수정 비용은 최소화하고 있는가? 각 장 마지막에 실려 있는 ‘애자일 리더를 위한 To Do List’로 지금 바로 현 상황을 검토하고 실패 없는 애자일 실천법을 적용하자. K-조직은 왜 애자일에 실패하는가 불확실성을 뚫고 성공하는 애자일 조직이 일하는 법 매일 수백만 명이 쓰는 토스의 송금 서비스와 쿠팡의 새벽배송은 수많은 실험과 실패에서 학습하는 피드백 루프에서 태어났다. 요즘 성과를 내는 조직은 처음부터 완벽한 서비스를 만들기보다는 서비스를 지속적으로 사용하는 유저의 리텐션을 높이는 데 집착한다. 이를 위해서는 실험이 필요하고 실패는 프로세스의 일부이다. 국내에서도 애자일이 일 잘하는 조직의 디폴트가 된 지 오래다. 밑바닥부터 시작하는 스타트업은 물론 레거시 시스템이 산더미같이 쌓여 있는 대기업도 불확실한 상황과 복잡한 문제에 기민하게 대응하는 조직을 추구하며 직급을 없애고 호칭을 바꾸고 교차기능팀을 꾸렸다. 그래서 현실은 어떠한가? 일일 스크럼은 일일 업무보고와 다를 바 없고, 일정은 그대로인데 요구사항만 중간에 추가되거나, 일단 해보고 안 되면 고치는 게 애자일이라며 스프린트를 반복되는 재작업의 악순환으로 만들어 버린 조직이 다수다. 애자일 조직의 리더가 답해야 하는 첫 번째 질문 지금 조직이 해결해야 하는 문제가 난해한 것인가 복잡한 것인가? 저자 스티브 매코널은 애자일을 도입하려는 조직의 리더라면 이에 답할 수 있어야 한다고 말한다. 난해한 문제는 전문가를 통해 어떻게 질문하고 답을 얻어야 하는지 알 수 있다. 개발해야 하는 서비스가 무엇인지 명확하다면 꼭 애자일이 아니더라도 순차 개발을 통해 요구사항을 해결할 수 있다. 복잡한 문제라면? 전문가에게도 질문을 찾는 게 도전이다. 해결책을 구하려면 촘촘한 피드백 루프로 막다른 길에서 낭비하는 시간을 줄이고 보다 낮은 비용으로 오류를 수정해야 한다. 이 책은 커네빈 프레임워크로 상황의 복잡성과 불확실성에 따라 유용한 전략을 소개하고(3장 복잡성과 불확실성에 대응하기), 각 조직에 맞는 애자일 경계를 그리는 방법을 알려 준다(2장 오늘의 애자일). 나아가 초기 애자일을 무조건적으로 좇던 강박에서 벗어나 비전과 우선순위에 따라 자율적으로 일하고 짧은 스프린트와 수직 슬라이스 배포로 성과를 내는 조직의 핵심 애자일 원칙 28을 설득력 있게 제시한다. K-조직에 애자일 절망편이 펼쳐지는 이유 포스트잇으로 가득한 벽이 있다고 해서 반드시 팀이 체계적이고 효과적인 방식으로 업무를 수행한다는 의미는 아니다. 순차 개발이 관료 체제로 실패한다면, 애자일은 무정부 상태로 실패한다. 애자일 안티 패턴은 진정한 자율관리팀을 만들지 않고 스크럼을 채택하는 것이다. 만약 경영진이 세부적인 수준에서 팀을 지휘하고 통제하면서 말로만 팀에 결정권이 있다고 한다면, 애자일 구현은 실패할 것이다. 기꺼이 의지가 있고, 준비되어 있고, 자율관리팀을 만들어 이를 지원하려는 조직이 아니라면 애자일을 채택해서는 안 된다. 이 책에는 효과적인 애자일팀으로 거듭나기 위한 실용적인 스크럼 실천법(4장 스크럼의 기쁨과 슬픔)과 교차기능팀을 만들고 지속 가능하게 운영하는 방법(5장 애자일팀 구조)이 나와 있다. 또한 더 효과적으로 일하는 데 전념하는 조직은 소프트웨어 프로젝트의 목적을 보다 포괄적인 성장 마인드셋 관점으로 바라본다(6장 애자일팀 문화, 8장 개인과 상호작용). 물론 프로젝트는 동작하는 소프트웨어를 생산해야 하지만, 소프트웨어를 만드는 팀의 능력을 향상시키는 것도 필요하다. 대부분의 생산성 연구에 따르면 생산성은 다른 어떤 요소보다 동기에 의존하는 정도가 더 높은데, 소프트웨어 개발 업무의 경우, 여러 가지 동기 중 내적 동기가 가장 중요하다. 문제는 요구사항이야 저자는 소프트웨어 개발 분야에서 일한 25년 동안, 프로젝트가 어려움에 처하거나 실패한 원인을 조사한 모든 연구에서 문제의 주요 원인은 불완전하고, 부정확하고, 모순이 있는 등 형편없는 요구사항이었다고 토로한다. 요구사항을 책임지는 프로덕트 오너의 역할이 왜 갈수록 중요해지고 있는지 알 수 있는 대목이다. 이 책은 해결해야 하는 문제의 복잡함 정도에 따라 달라지는 요구사항의 수명주기(13장 애자일 요구사항 만들기)와 2주 단위의 단기 스프린트에도 상위 비즈니스 가치를 잃지 않는 스토리 매핑 전략(14장 애자일 요구사항 우선순위 매기기)으로 더 효과적으로 일하는 법을 전달한다. 특히 효과적인 소프트웨어 개발의 원칙으로 피드백 루프를 최대한 촘촘하게 하는 것을 강조한다. 왜 우리는 애자일팀에 프로덕트 오너를 두려고 할까? 요구사항과 관련 있는 피드백 루프를 강화하기 위해서다. 왜 교차기능팀을 만들려고 할까? 의사결정에 필요한 피드백 루프를 강화하기 위해서다. 왜 요구사항을 작은 단위로 정의하고 전달할까? 요구사항을 정의하는 과정에서 실행 가능하고 동작하는 소프트웨어로 피드백 루프를 강화하기 위해서다. 왜 개발하기 전에 테스트를 먼저 수행할까? 코드와 테스트 사이의 피드백 루프를 강화하기 위해서다. 조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 효과적인 애자일 리더는 명확한 우선순위를 전달하는 것으로 팀을 지원한다. 많은 조직이 모든 것을 최우선 순위에 두고 팀이 파악하도록 맡겨 버린다. 우선순위를 너무 자주 재조정하거나, 너무 세밀한 수준으로 지정하거나, 우선순위를 아예 거부하기도 한다. 이러한 실수는 매우 흔하고 비효율적이다. 우선순위를 매기지 않는 건 리더십이 약하다는 신호다. 이는 의사결정에 대한 책임을 포기하는 것과 같다. 혁신은 표준정규분포를 따라 확산된다. 저자는 조직에 애자일을 성공적으로 도입하기 위한 도미노 변화 모델(비전, 공감대, 실력, 자원, 인센티브, 실행 계획)을 제시한다(23장 애자일 도입). 도미노 변화 모델은 누락된 요소가 하나라도 있으면 변화가 일어나지 않는다. 여기서 리더십의 역할은 필수적이며 핵심적이다. 조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 조직에 알맞은 애자일 경계는 무엇인가? 세부사항이 아닌 성과를 관리하고 있는가? 촘촘한 피드백 루프로 학습을 가속화하고 수정 비용은 최소화하고 있는가? 책의 각 장 마지막에 실려 있는 ‘애자