미션 주도 개발

회사가 성장함에 따라 Agile 제품 개발을 확장하는 것이 더 어려워집니다. 13차 State of the Agile Report 응답자의 52%에 따르면 조직 문화와 Agile 가치의 차이가 업무의 주요 단점이라고 합니다.

조직 리더는 애자일 문화를 활용하여 제품 개발을 개선할 수 있습니다. 강력한 애자일 문화에는 복잡한 문제에 접근하는 팀 자율성, 고객과의 긴밀한 협력, 장기적인 비전 및 전략이 포함됩니다.

이러한 추상적인 가치는 평가하고 참여하기 어렵습니다. 조직에서 이를 활용하기 위한 효과적인 전략을 구현하는 것은 쉬운 일이 아닙니다. MDD(Mission Driven Development) 접근 방식은 이러한 문화를 성장시키기 위한 대안으로 중간 단계의 스타트업에서 부상했습니다.

확장 과제

확장할 때 몇 가지 속도 저하 패턴이 나타날 수 있습니다. 끝이 불분명한 프로젝트로 인해 팀 동기가 감소할 수 있습니다. 제품 관리자는 운영 회의에서 길을 잃었다고 느낄 수 있으므로 전략적 제품 경로를 설계하는 데 시간을 낭비할 수 있습니다. 시스템이 점점 더 복잡해짐에 따라 새로운 기능과 제품의 배포가 느려질 수 있습니다.

이러한 장벽은 문화적, 실제적 관점에서 접근해야 합니다. 이를 극복하려면 통제권 포기, 팀 자율성 증대, 급진적인 투명성 구현, 결과를 이끌어내기 위한 효율적인 제품 개발 프레임워크 설정이 필요합니다.

기존 애자일 프레임워크 확장의 과제

Agile을 확장할 때 관리 수준과 팀 수준을 동기화해야 합니다. 관리 수준은 회사 전략 개발, 제품 비전 생성 및 전달, 직원 배치 결정 실행, 팀 개발 육성을 담당합니다. 팀 수준은 이 비전과 전략을 가치 있는 제품과 기능으로 효율적으로 변환하는 데 필요한 작업을 수행합니다.

기존 애자일 프레임워크(XP, Scrum 및 Kanban)는 팀 수준에서 작동하도록 최적화되어 있어 관리 관계는 주로 해결되지 않습니다. SAFe, LeSS, Scrum of Scrums, Nexus, DAD 등 확장된 Agile 프레임워크의 새로운 물결이 이러한 격차를 메우기 위해 발전했습니다. 그러나 이러한 접근 방식은 구현하기 위한 많은 계획과 관리 및 유지 관리를 위한 노력이 필요합니다.

가벼운 접근 방식인 Mission Driven Development 프레임워크는 개발 확장 및 애자일 가치 활용과 관련된 강력한 구조를 구현하기에 충분한 지침을 제공합니다.

미션 주도 개발의 핵심 요소

미션

출발점은 미션 디스커버리입니다. 비즈니스 미션에는 시간과 노력이 필요하며 잠재적인 문제, 솔루션 공간 및 원하는 비즈니스 결과를 식별해야 합니다. 정확하게 정의되면 임무는 동기를 부여하고 협업을 촉진하며 더 넓은 디자인 공간에 대한 연구를 촉진합니다.

선수단

각 임무의 성공을 책임지는 주체는 분대입니다. 제품 관리자와 협력하여 2-4명으로 구성된 소규모 팀이 미션 목표와 시간 제한에 맞는 솔루션을 제공하기 위해 필요한 활동을 수행합니다.

6주 주기

6주 타임박스는 모든 스쿼드가 기지 계획을 위해 동일한 타임라인을 따를 수 있도록 하는 동시에 의미 있는 결과를 제공하기에 충분한 시간을 제공합니다.

버퍼 기간

MDD 프레임워크에는 일반적으로 무엇보다도 최종 통합 및 배포, 교육 및 기술 개발, 혁신 활동, 다음 주기 계획을 위한 1주 또는 2주의 버퍼 기간이 포함됩니다.

6주 주기의 중요성

6주의 기간은 일부 Agile 실무자에게 많은 시간처럼 보일 수 있지만 몇 가지 중요한 이점이 있습니다.

짧은 주기로 작업하는 팀은 수정, 버그 및 작은 기능의 "세탁 목록"을 확인하는 것처럼 느끼기 때문에 제품 비전에 대한 참여를 잃는 경향이 있습니다. 이는 솔루션을 제공하기 위한 최선의 방법을 탐색하고 선택하는 팀의 자율성을 위협합니다.

주기가 길어질수록 제품 추정 정확도가 떨어집니다. 결과적으로 제품 팀의 많은 계획 노력이 필요합니다.

6주는 제품 타임프레임의 골디락스(Goldilocks)라고 불리며, 혁신적인 사고, 신속한 프로토타이핑 및 지속적인 제공을 통해 최소 실행 가능한 제품을 제공하기에 충분한 시간을 제공합니다.

6주 주기는 자율성을 활용하여 팀 비전 참여를 더욱 향상시킵니다. 미션이 명확하게 명시되어 있고 팀이 원하는 결과에만 집중할 수 있을 만큼 주기가 짧다면 세세한 관리가 필요하지 않습니다.

마지막으로, 제품 관리자는 6주마다 계획 활동에 참여하여 팀이 임무를 계속 추적할 수 있도록 충분한 예측 가능성을 유지할 수 있습니다. 결과적으로 제품 개발의 전략적 및 탐색적 차원에 더 많은 시간을 할애할 수 있습니다.

미션 주도 개발의 구현

예를 들어 인공 지능 애플리케이션을 사용하여 고객 수익을 높이는 네트워크 가격 최적화를 제공하는 B2B 제품을 보유한 중간 단계의 스타트업을 가정해 보겠습니다. 이 비즈니스는 최근 관련 업계 행위자로 자체를 공고히 하고 시장 점유율을 300%까지 늘리는 것을 목표로 새로운 자금 조달 라운드에 서명했습니다.

이 시나리오에는 몇 가지 제품 개발 문제가 있습니다.

• 보류 가치 가설을 검증하기 위해 현재 및 잠재 고객으로부터 피드백을 어떻게 얻을 수 있습니까?
• 매력적인 사용자 경험을 위해 플랫폼에서 구축하거나 제거해야 하는 기능은 무엇입니까?
• 확장을 처리하고 문화적 가치를 활용하여 성장을 가속화하기 위해 관리 구조를 어떻게 설정할 수 있습니까?

결국 회사는 복잡한 프레임워크를 피하기 위해 Mission Driven Development 프레임워크를 적용하기로 결정했습니다. 미션 주도 개발에서 "라스트 마일" 세부 사항은 모든 조직에서 정의합니다. 정의할 주요 요소는 다음과 같습니다.

• 미션 디스커버리
• 미션 구조
• 스쿼드 어셈블리
• 검사 및 적응
• 버퍼 반복
• 용량 계획

미션 디스커버리

출발점은 미션 디스커버리입니다. 팀 허빅(Tim Herbig)은 발견을 문제나 아이디어에 대한 불확실성을 줄여 올바른 청중을 위해 올바른 제품이 구축되도록 하는 반복적인 프로세스라고 설명합니다. 반복 주기에서 임무를 수행하기 전에 가능한 한 포괄적으로 검증해야 합니다.

Mission Discovery 프로세스는 특별히 할당된 팀에 의해 수행됩니다. 발견 팀은 제품 관리자가 이끌고 제품 연구원, 비즈니스 분석가 및 디자이너로 구성됩니다. 여러 제품 관리자가 있는 경우 CPO(최고 제품 책임자)에게 보고하여 제품 전반에 걸친 공통의 비전, 제품 및 글로벌 회사 전략의 적합성, 적시 납품을 보장합니다.

임무 발견을 위한 권장 출발점은 도전, 문제 또는 기회입니다. 예를 들어, 도전에서 시작하면 팀이 더 많은 디자인 공간을 탐색하여 마침내 솔루션 가능성을 확장할 수 있습니다.

미션 검증에는 회사가 고객의 요구를 더 잘 이해하는 데 도움이 되는 몇 가지 활동이 포함됩니다.

1. 시장 조사 및 경쟁사 분석 수행
2. 미션이 정의된 문제 공간 이해
3. 저충실도 스케치 및 프로토타입 디자인
4. 임무의 명확한 범위 정의
5. 클라이언트 피드백 및 검증 수집

이러한 활동은 미션이 개발팀의 견고한 지침이 되고 사용자를 위한 가치가 창출되도록 돕습니다.

결과적으로 일부 임무는 발견 활동 및 피드백 수집을 통해 지속적으로 발전하는 임무 백로그에 들어갈 수 있도록 검증되었습니다.

이 예에서 다음과 같은 문제를 해결해 보겠습니다. 매력적인 사용자 경험을 생성하기 위해 플랫폼에서 어떤 기능을 구축해야 할까요? 제품 관리자가 이끄는 단 하나의 발견 팀만 이 문제를 해결하기에 충분할 것입니다.

현재 예제 회사의 플랫폼이 클라이언트의 원시 데이터를 가져와 처리된 데이터 파일에 대해 최적화된 가격 책정 네트워크를 반환한다고 가정해 보겠습니다. 그러나 플랫폼 UX는 매력적인 경험을 위해 최적화되지 않았습니다. 이 시점의 목표는 클라이언트 가치가 UX 개선, 새로운 기능 개발 또는 플랫폼 서비스 향상에서 나올지 여부를 결정하는 것입니다.

초기 시장 조사 후 결정은 새로운 기능을 개발하는 것입니다. 플랫폼의 후보 기능은 다음과 같습니다.

• 초고속 가격 조정
• 빠르고 반응이 빠른 인터페이스
• 지능형 및 고급 가격 책정 규칙
• 가격 조정 및 판매 내역

발견 목적으로 회사는 디자인 스프린트 접근 방식을 사용하기로 결정했습니다. 즉, 사용자와 함께 디자인, 프로토타이핑 및 아이디어 테스트를 통해 중요한 비즈니스 질문에 답하는 5일 프로세스입니다. 검색 프로세스는 각 후보 기능에 대해 실행되어 현재 및 잠재 고객에게 더 많은 가치를 창출할 기능을 확인합니다. 개발을 위해 선택된 최상위 기능은 지능형 및 고급 가격 책정 규칙입니다.

미션 구조

확고한 임무 정의를 달성하는 것은 쉬운 일이 아닙니다. 명확한 비즈니스 과제를 설명하고 결과에 대한 경계를 설정하는 동시에 분대가 혁신적이고 효율적인 솔루션에 도달할 수 있는 충분한 공간을 제공해야 합니다. 명확하고 정확한 임무:

• 문제 영역을 식별하고 설명하여 비즈니스 과제를 명확하게 설명합니다.
• 이전 단계에서 발견된 모든 정보와 통찰력을 종합합니다.
• 원하는 비즈니스 결과로 연결됩니다.
• 결과 지향적이며 임무 성공의 그림을 명확하게 나타냅니다.
• 6주 주기 기회 내에 현실적이고 달성 가능합니다.
• 초점을 보장할 만큼 충분히 좁고 세부 사항에서 멀어질 만큼 충분히 넓습니다.

이 예에서 발견한 지 일주일 후에 정보와 사용자 피드백이 수집되고 합성되었습니다.

대상 사용자: 고객 가격 분석가.

문제 공간: 사용자는 특정 조건에서 자동으로 가격을 조정할 수 있도록 가격 책정에 대한 지능형 고급 규칙을 설정하고 관리할 수 있기를 원합니다.

규칙에 대한 가장 중요한 조건은 경쟁사 가격, 배송 긴급성, 주문 총액, ​​사용 가능한 재고 및 프리미엄 고객에 대한 할인입니다.

통찰력: 규칙은 사용자 지정 우선 순위에 적용되어야 하며 필요한 경우 수정할 수 있습니다.

분석가는 주어진 제품에 대해 특정 시간에 어떤 규칙이 적용되는지 쉽게 확인하고 싶어합니다.

원하는 비즈니스 결과: 플랫폼에서 보낸 시간으로 측정할 때 사용자 플랫폼 참여를 25% 늘립니다.

스쿼드 어셈블리

팀 구성 프로세스는 모든 개발 주기에 대해 임시로 수행됩니다. 팀 자율성과 자기 조직화 원칙은 여전히 ​​핵심입니다. 팀 조립은 임무 복잡성, 개발자 및 디자이너 기술, 관심, 분대 구성 등 다양한 요소에 따라 진행됩니다.

스쿼드 구성 과정은 애자일 코치에 의해 촉진됩니다. 결정을 내리기 전에 각 사람은 앞으로 6주 동안 어떤 유형의 일을 하고 싶은지 묻습니다. 그런 다음 경험, 지식 및 기술을 기반으로 분대를 구성하여 임무를 성공적으로 수행하는 데 필요한 지식과 기술을 갖추도록 합니다.

애자일 코치는 개발 주기에 따라 여러 분대와 협력하여 장애물과 종속성을 높이는 데 도움을 줍니다. 애자일 코치가 여러 명 있을 경우 팀 구성, 지속적인 개선, 애자일 제품 전달을 담당하는 애자일 팀장에게 보고합니다.

권장 분대 규모는 2-4명입니다. 일반적으로 임무 복잡성에 따라 한 명의 디자이너와 한 명 또는 두 명의 개발자입니다. QA 엔지니어는 원하는 품질 표준을 달성하는 데 하나 이상의 팀을 지원하는 것으로 간주됩니다.

분대는 주기가 끝날 때마다 혼합되는 경우가 많으므로 모두가 다른 사람들과 협력하고 지식을 전파하며 다양한 제품 차원에서 작업할 수 있지만 고성능 분대는 몇 주기 동안 함께 일할 수 있습니다.

예제의 특정 팀은 UI 디자인, 데이터 처리 및 데이터 시각화 기능을 가진 사람들을 고려해야 합니다.

주기 내 검사 및 적응

표준 Agile 사례를 통해 Agile 코치는 투명성, 검사 및 적응을 지속적으로 권장해야 합니다.

짧은 주간 회의는 작업을 조직하고 장애 및 의존성을 높이는 데 도움이 됩니다. 필요한 경우 분대가 임무와 사용자 스토리를 완전히 이해할 수 있도록 정리가 수행됩니다. 매주 말에 짧은 회고전을 수행하여 변경 사항과 개선 사항을 식별하고 구현합니다.

주기 전반에 걸쳐 지속적인 전달 방식을 유지해야 합니다. 6주 주기 타임박스는 기본 규칙을 설정하는 동시에 분대 예측 가능성을 달성하는 데 도움이 되는 케이던스 기반 접근 방식이므로 임무 목표를 더 일찍 달성할 수 있습니다.

투명성을 향상시키는 좋은 방법은 팀과 제품 관리자 간에 합의된 이정표를 기반으로 4주 말에 데모를 하는 것입니다. 이 데모의 목표는 필요에 따라 범위를 조정, 축소 또는 늘리는 것입니다.

예시 임무의 경우, 4가지 다른 릴리스에서 분대와 제품 관리자 간에 릴리스 계획이 합의되었습니다.

1. 릴리스 1:
   • 새로운 규칙 기능 UI
   • 경쟁사 가격 규칙
2. 릴리스 2:
   • 배송 긴급 규칙
   • 주문 총계 규칙
   • 규칙 우선 순위
3. 릴리스 3:
   • 사용 가능한 인벤토리 규칙
   • 시각화 적용 규칙
4. 릴리스 4:
   • 프리미엄 고객 할인

릴리스 3은 네 번째 주에 대한 데모로 동의합니다. 개발 주기 전반에 걸쳐 릴리스가 수행되었으므로 개발 주기가 시작되는 순간부터 원하는 비즈니스 결과(이 경우 사용자 참여)를 추적해야 합니다. 그래픽으로 다음과 같이 진행이 예상됩니다.

버퍼 기간

완충 기간으로 1~2주를 취하는 것은 미션 주도 개발 구현과 SAFe와 같은 다른 확장 접근 방식을 통해 반복되는 관행입니다.

SAFe에서는 모든 개발 주기에서 혁신 및 계획 반복이 수행됩니다. 컨텍스트 전환기 역할을 하여 일반적으로 다른 전달 중심 프레임워크에서 누락된 탐색 및 혁신의 프로세스와 활동을 가능하게 합니다. 이번 버퍼 주간에 구현된 활동의 예:

• 솔루션의 최종 통합 . 6주 주기가 끝날 무렵 배포할 때 통합, 검증, 문서화 및 검증이 보류 상태로 남아 있을 가능성이 높습니다. 전용 시간은 기존 제품에 새로운 솔루션을 효과적이고 원활하게 통합하는 데 도움이 됩니다.
• 임무 계획 및 우선 순위 지정 . 임무는 세분화되고, 작거나 큰 배치로 분류되며, 다음 개발 주기를 위해 우선 순위가 지정됩니다. 미션의 우선 순위를 정할 때 일부 회사는 최고의 미션이 회사에 제공되고 협업 방식으로 다음 개발 주기를 위해 헌신하는 피치 데이를 시행합니다.
• 해커톤 . 해커톤은 혁신을 촉진하고 커뮤니티를 만들고 재미있는 방식으로 새로운 지식과 기술을 구축할 수 있는 능력 덕분에 스타트업과 기업 사이에서 점점 인기를 얻고 있습니다. 결과는 다른 사람에게 제공되고 임무 백로그의 후보가 됩니다.
• 실험적 프로토타입 개발 또는 사이드 프로젝트 . 버퍼 시간이 끝날 때 완료된 작업을 보여주는 한 엔지니어와 디자이너가 결정한 대로 작업할 시간을 주는 것이 일반적입니다.
• 엔지니어링 작업 . 인프라 개발, 테스트 자동화, 기술 부채 감소 및 시스템 마이그레이션과 같은 순수 엔지니어링 작업이 일반적으로 수행됩니다.
• 새로운 기술과 지식의 개발 . 지식 진화의 빠른 속도로 인해 개발자는 글로벌 트렌드에 대한 최신 정보를 유지해야 합니다. 완충 시간은 무엇보다도 현장 교육, 실무 커뮤니티 및 기술 워크숍을 개최하기에 적합합니다.

버퍼 기간은 식별된 지식 격차, 혁신 목표 및 다음 주기에 대한 요구 사항에 의존해야 합니다. 예를 들어, 일주일의 버퍼 기간은 다음과 같을 수 있습니다.

용량 계획

Basecamp 공동 설립자 Jason Fried에 따르면 다음 개발 주기에 대한 임무 약속을 결정할 때 일반적인 관행은 먼저 작거나 큰 배치를 식별하는 것입니다. 큰 배치는 큰 제품 특징이나 기능을 나타내고 작은 배치는 더 작은 반복이나 작업을 나타냅니다. 주어진 예에서 새로운 기능에 대해 선택된 임무는 큰 배치로 간주될 수 있습니다.

권장 사항은 간단합니다. 항상 작은 배치와 큰 배치를 혼합하여 사용하십시오. 소규모 배치는 3~4주가 소요될 것으로 예상되는 미션이며, 대규모 배치는 6주 이상이 소요될 수 있습니다.

소규모 배치 팀이 3주 또는 4주까지 임무를 완수했다면, 합의된 데모는 팀이 구현된 솔루션을 개선하기 위해 계속 작업해야 하는지, 다른 분대를 도우며, 새로운 소규모 배치 임무를 수행해야 하는지 또는 시작해야 하는지 평가할 기회입니다. 계획되지 않은 작업.

크고 작은 배치를 잘 혼합하면 사람들이 100% 용량으로 작업하는 것을 방지할 수 있으므로 계획되지 않은 작업의 경우 기동하고 적응할 수 있습니다. 대규모 배치 팀은 주기 동안 최대한 많은 집중을 하는 반면, 소규모 배치 팀은 예상치 못한 작업으로 인해 발생하는 임시 작업을 처리할 수 있습니다.

작은 배치와 큰 배치를 결합하면 위험도 줄어듭니다. 큰 배치만 있으면 사용자 경험에 부정적인 영향을 미칠 가능성이 높아집니다. 몇 가지 새로운 기능이 서로 가깝게 출시되면 적절한 변경 관리가 수반되어야 합니다. 또한 계획되지 않은 작업의 경우 사용 가능한 용량이 줄어듭니다. 마지막으로, 여러 대규모 배치 팀이 실패하면 반복이 비생산적인 것으로 감지되어 팀의 사기를 저하시킬 수 있습니다.

미션 주도 개발의 위험

미션 주도 개발을 구현하면 많은 이점이 있지만 모든 규범적 프레임워크와 마찬가지로 고려해야 할 몇 가지 고유한 위험이 있습니다.

임무 범위

미션은 도전 과제의 복잡성과 분대 기술 간의 적절한 조화를 목표로 현실적이어야 합니다. 그렇지 않으면 개발 결과에 미치는 영향이 상당할 수 있습니다.

지나치게 야심찬 임무는 좌절과 불안을 불러일으키고 분대 성과에 부정적인 영향을 미칠 수 있습니다. 반면에 열정적이지 않은 임무는 분대원의 의욕을 꺾고 지루함을 유발할 수 있습니다. 따라서 최소 실행 가능 제품 사고 방식은 프레임워크 내에서 일정하게 유지되어야 합니다.

선교의 이유

강력한 비즈니스 미션에는 문제 영역과 회사 비전과의 관계에 대한 포괄적인 정의가 있어야 합니다. 이 관계가 명확하지 않으면 문제 해결이 회사 목표에 미치는 영향에 대한 이해 부족으로 인해 귀중한 통찰력을 잃을 수 있습니다.

폭포 함정

6주 동안 폭포수 모델에 빠지는 것은 분대의 자연스러운 경향입니다. 여기에는 두 가지 주요 요인이 있습니다. 첫째, 배포에 대한 압력은 주기가 끝나갈수록 더 강해집니다. 둘째, 분대는 임무 내에서 가능한 한 많은 범위를 축소하기를 원하므로 개발 주기가 끝날 때 배치가 시급합니다. 따라서 주기 전반에 걸쳐 애자일 릴리스를 달성하고 폭포수 관련 위험을 피하기 위해 지속적인 배포 방식을 권장해야 합니다.

제품 운영

인프라, 서비스 또는 구성 요소 모니터링과 같은 제품 운영 작업은 속도에 영향을 줄 수 있으므로 분대의 범위를 벗어나야 합니다. 원자 설계와 같은 개발 표준 및 관행에 의존하면 개발 노력이 줄어들고 결과적으로 확장이 가속화됩니다. 이 프레임워크의 또 다른 일반적인 관행은 제품 운영 및 모니터링 관리 외에도 인프라를 처리하는 중앙 운영 팀입니다.

근시안적 프레임워크로서의 6주 주기

일부 시나리오는 프레임워크에 적합하지 않습니다. R&D 프로젝트나 중요 시스템 마이그레이션과 같이 고객 경험에 막대한 영향을 미칠 수 있는 크고 복잡한 시스템을 다룰 때 특히 그렇습니다.

민첩한 확장을 위한 경량 옵션

제품 개발 및 회사 성장의 속도를 따라잡기 위해 Agile을 확장하는 것은 Agile 실무자에게 잠재된 과제입니다. 최근에 개발된 Agile 접근 방식으로서 Mission Driven Development 프레임워크는 사용 및 구현의 용이성으로 인해 기업들 사이에서 인기를 얻었습니다. MDD 프레임워크는 발견에서 제공에 이르기까지 기존 애자일 구조에 존재하는 격차를 메우는 종단 간 제품 혁신 프로세스를 시작합니다. Mission Driven Development는 성장하는 회사를 위한 새로운 스크럼이 될 가능성이 있습니다.