회사는 애자일의 의미를 진정으로 이해하기도 전에 "애자일로 전환"하겠다는 사명에 착수하는 경우가 너무 많습니다. 균열이 나타나기 시작하고 기대치를 달성하지 못하면 모두가 "애자일로 전환"하는 것의 가치에 의문을 제기하게 되고 기대치를 충족할 가능성이 낮아집니다.
사실 애자일로 전환하면 팀의 생산성이 향상되고 프로젝트가 더 빨리 제공될 수 있지만 모두가 게임의 규칙에 동의할 수 있는 경우에만 가능합니다. 애자일 원칙에 대한 합의를 얻는 것이 프로세스를 구현하는 것보다 중요한 이유에 대해, 전자상거래 대기업인 Gilt의 Heather Fleming 및 Justin Riservato의 논의를 살펴보세요.
특히 Heather와 Justin은 애자일 여정을 시작하기 전에 모든 팀이 답을 준비해야 하는 세 가지 중요한 질문에 대한 답을 탐구합니다.
- "그래서 언제 다 됩니까?" 애자일로 전환할 때 기한의 개념을 없애는 것이 가장 중요하고 가장 어려운 대화인 이유입니다.
- "제 최우선 순위지만 다음 주까지는 회의를 할 수 없어요." 비즈니스 파트너가 팀의 완전한 구성원이 되지 못하는(또는 않는) 경우 해야 할 일입니다.
- "저는 코딩만 하고 싶어요. 왜 제가 이 모든 회의에 참석해야 합니까?" 스크럼 구현이 애자일로의 전환의 첫 번째 단계가 아닌 이유입니다.
보고 배우기
질문 및 답변
여기서 Heather와 Justin은 프레젠테이션의 Q&A 세션에서 가장 중요한 질문 중 몇 가지를 선택했습니다. 애자일 방법론을 적용하는 방법에 대한 전략을 자세히 알아보려면 자세히 읽어보세요.
Q1: 디지털 애자일 보드와 물리적 애자일 보드를 비교할 때 어떻게 생각하십니까?
A1: 팀 설정에 따라 다릅니다. 모두 같은 장소에 있는지, 팀의 규모는 얼마나 되는지, 대규모 물리적 보드를 위한 공간이 있는지에 따라 다릅니다. Gilt에서는 두 가지를 모두 했지만, 수십 개의 팀으로 성장하고 확장하면서 Jira Software의 애자일 보드가 실제 보드보다 실용적이라는 것을 발견했습니다. 설정 및 변경이 더 쉽고 원격 팀원과 공유하기도 더 쉽습니다. 저희가 물리적 보드에 대해 좋아하는 점은 눈앞에 있기 때문에 무시할 수 없다는 것입니다. 그리고 현재 작업에 대한 즉석 토론을 하거나, 스탠드업을 하는 경우 스탠드업을 하기에도 좋은 장소입니다.
Q2: 애자일 프로세스를 따르지 않거나 이해하지 못하는 매니저 또는 고객과 어떻게 협력할 수 있나요? 제가 능숙하지 못한 워크플로 코치처럼 느껴질 때가 있어요.
A2: 운영 순서에 대해 생각하는 것이 중요합니다. 애자일의 가치를 믿지 않는 팀원들과 함께 애자일 프로세스로 일하려는 것은 시기상조입니다. 효과적으로 해내는 데 있어 가장 중요한 부분은 프로세스를 실행하기 전에 철학에 대한 합의를 도출하는 것입니다. 저희는 과거에 팀이 현재 프로세스에서 겪고 있는 특정 문제를 살펴보고 애자일한 방식으로 해결하여 이 부분을 달성했습니다. 매니저나 고객이 해결하려는 실제 문제와 애자일 프레임워크에서의 접근 방법을 안내할 수 있습니까? 전체 프로세스를 크게 변경하는 대신 애자일로 전환하는 방향으로 조금씩 나아갈 수 있습니까? 그런 다음 팀이 더 효과적으로 운영되면서 이 방식으로 점진적 성과를 보여줄 수 있습니다. 즉, 애자일로 전환하려면 애자일 접근 방식을 취하세요. ;)
Q3: 프로젝트가 고정된 입찰 및/또는 구현해야 할 요구 사항 목록이 있는 고정된 일정인 경우 어떻게 애자일 프로세스를 구현할 수 있습니까?
A3: 우선, 고정된 일정과 구현해야 할 고정된 요구 사항의 목록이 주어지면 프로젝트를 완료하는 것은 불가능합니다. 그러면 모두가 이것은 환상이라는 데 동의하도록 만들 방법이 있습니까? 기한 및 요구 사항에 대한 대부분의 제약은 진정한 제약이 아니라 바람일 뿐입니다. 작업을 수행하는 이유 또는 해결하려는 문제가 무엇인지 논의를 시작하세요. 프로젝트의 목표와 제약의 이유를 진정으로 이해한다면 팀이 적시에 올바른 작업을 수행하고 있는지 확인할 수 있습니다. 모든 요구 사항과 그 옆에 날짜를 함께 적어 둔다고 해서 모든 것이 마술처럼 제 시간에 이루어지지는 않습니다.
Q4: 대부분의 프로젝트에는 일반적으로 파트너 및 고객에게 전달되는 릴리스 날짜가 있습니다. 시나리오에서 품질에는 약간의 타협이 있지만 협상 가능한 유일한 것은 기능 세트입니다. 고정된 기한이라는 제약 속에서 어떻게 작업할 수 있나요?
A4: 질문 속에 답변이 있는 것 같아요. 범위를 협상하면 가능합니다. 그렇게 하지 않으면 품질이 저하된다는 점에서 맞는 이야기입니다. 상관없이 범위를 끼워넣을 수 있다고 생각하는 것은 현실적이지 않습니다. 팀원들이 듣고 싶어하는 말이 아니더라도 팀이 현실적인 태도로 일하고 있는지 확인해야 합니다. Heather가 여기에 대해서 쓴 짧은 블로그 게시물이 있는데 여기에서 읽어보실 수 있습니다.
Q5: 스크럼 구현 방식을 어떻게 변경해야 한다고 생각하나요?
A5: 저희가 스크럼에서 느끼는 가장 큰 문제는 그 강성입니다. 어떤 작업을 하고 있는지, 누구인지와 관계없이 모든 팀에서 고도로 규범적인 하나의 프로세스가 효과가 있다고 생각하는 것은 건방진 태도입니다. 팀에 효과가 있는 것을 보기는 했지만, 스크럼이 애자일을 유지하는 유일한 방법은 아니며 많은 팀에서는 규정된 모든 직무 역할, 사용자 스토리, 수락 기준, 회의 및 아티팩트를 사용하여 특정 방식으로 스크럼을 구현해야 한다고 생각하기 때문에 애자일에 실패합니다. Heather는 “스크럼 마스터”라는 호칭에도 문제가 있다고 생각합니다. ;)
Q6: 이해 관계자가 팀원에게 직접적인 영향을 미치지 않도록 하려면 어떻게 해야 합니까?
A6: 좋은 이해 관계자는 팀원이기도 합니다. 따라서 주요 이해 관계자를 팀에 참여시켜 모두가 함께 일할 수 있도록 하는 것이 이상적입니다. 팀에 일을 던져놓거나 프로젝트 중에 갑자기 참여해서 모든 것을 바꾸려는 이해 관계자가 있다면 팀 전체가 이들이 무엇을 왜 하고 있는지 이해하는 것이 중요합니다. 따라서 이해 관계자가 누구와 대화하든 똑같은 답변을 얻을 것입니다. 이것이 바로 여러분을 개인의 집합이 아니라 한 팀으로 만들어주는 요소입니다. 커뮤니케이션을 많이 하고 모두가 동일한 정보를 제공받으면서 같은 방향으로 나아가고 있는지 확인해야 합니다.
Q7: 대략적인 규모 추정치(시간 단위) 또는 포인트 중 어떤 것을 기반으로 스토리를 추정합니까?
A7: 저희는 둘 다 사용하며 전혀 추정하지 않는 팀도 있습니다. 포인트는 더 추상적이고 달력 위의 특정한 시간에 묶여 있지 않기 때문에 아주 좋습니다. 시간은 더 실재의 것이기 때문에 팀이 추정에 저항하는 경우 시간이 전환으로서 유용할 수 있습니다. 추정의 핵심은 스프린트가 너무 무겁거나 너무 가벼운지 판단하고 조정할 수 있는 것이며, 스프린트가 시작되면 실제로 목적이 없습니다. 저희는 어느 정도의 기간에 한 팀으로서 일하면 추정 프로세스가 불필요해진다는 것을 알았습니다. 모두 작업을 살펴보고 스프린트에 적합한 양인지 매우 쉽게 판단할 수 있습니다.
Q8: 요구 사항을 수집하기 위해 단순히 기술 및 비즈니스 이해 관계자 간의 회의 일정을 잡는 것과 비교해서, 프로젝트 리더/관리자가 심층적인 분석 기술과 제품 지식을 갖추도록 하는 데 얼마나 많은 가치를 부여합니까?
A8: 거의 모든 가치라고 할 수 있습니다. :) 회의 일정 잡기, 메모 작성 등은 특별히 전문적인 기술이 아니어서 누구나 할 수 있습니다. 해야 하는 일이기는 하지만 실제로 팀에 더할 수 있는 가장 큰 가치는 아닙니다. 하는 일이 전부 행정 업무라면 팀은 여러분이 왜 팀의 일원인지 의문을 제기해도 타당합니다. Gilt의 PMO에 있는 모든 직원은 관련 주제와 작업을 완료하는 데 필요한 도구 및 기술에 대해 깊이 이해하고 있으며 자신들이 일하는 모든 팀에서 이 이해를 제공합니다. 저희는 대부분 이전에 엔지니어였거나 Gilt의 다른 부서와 함께 일한 적이 있으며 고유한 주제 전문 지식을 제공했습니다.
Q9: 일반적으로 팀의 규모는 얼마나 크며 Gilt에서 팀원들은 어떤 배경을 가지고 있습니까?
A9: 이상적으로는, 팀이 린하면서도 자급자족할 수 있을 정도로 커져서 다른 팀에 의존하지 않고도 프로젝트를 진행할 수 있기를 바랍니다. 저희는 '피자 두 판의 법칙'이라는 규칙을 따릅니다. 즉, 팀은 피자 두 판을 나누어 먹을 수 있을 정도의 규모여야 합니다. 또한 팀의 각 개인은 저마다의 재능을 가지고 있으며 직책과 관계없이 팀에 재능을 제공할 수 있어야 한다고 강하게 느낍니다. 기존의 제품 소유자가 모든 프레젠테이션을 담당하지만 잘 해내지 못하고, 스토리텔링에 능숙하고 청중을 확보하는 엔지니어가 있다면 저희는 엔지니어가 팀에서 그 재능을 발휘하도록 할 것입니다. 직책이 모든 것을 말해주지는 않습니다.
Q10: 특히 테스트가 개발과 다른 스프린트에서 이루어질 수 있는 경우 별도의 QA 팀을 어떻게 관리합니까?
A10: 저희는 논란이 많은 입장을 취하고 있는데, Gilt에는 별도의 QA 팀이 없습니다. 저희는 개발 및 배포 프로세스 전반에서 자동화 테스트가 효과적이라고 믿습니다. 팀은 코드의 품질을 책임집니다. 코드를 작성할 시간과 전문 지식이 있다면 테스트를 작성할 시간과 전문 지식도 있을 것입니다. QA 팀에 단순히 일을 던지면 결코 좋은 결과가 나타난 적이 없으며 QA 팀의 속도를 높이려면 많은 추가 설명서와 시간이 필요합니다.
Q11: 여러 '제품'에 대해 동시에 작업하는 팀이 있다면, 스프린트 계획에 모든 제품 관리자를 참여시키하고 제품 간의 상대적 우선 순위를 결정하도록 하면 효과적입니까? 다른 아이디어가 있습니까?
A11: 추천하지 않는 방법입니다. 분명히 효과가 없을 것입니다. 팀에는 자체 제품 매니저가 있어야 하며 팀 외부에 있는 여러 제품 관리자를 위해 여러 제품에 대해 작업하지 말아야 합니다. 팀 리더 역할을 맡은 팀원은 여기서 한 걸음 더 나아가 팀의 우선 순위 지정 방법론과 이 방법론을 기반으로 해당 작업을 어떤 순서로 실행할 것인지 명확하게 설명해야 합니다. “프로세스를 시행하기 전에 방법론에 정렬되어야 한다”는 저희의 요점과 관련이 있습니다.
Q12: 마케팅 크리에이티브 서비스 팀을 애자일로 만들려고 합니다. 특정 날짜에 꼭 제공해야 하는 몇 가지 산출물이 있습니다(잡지에 인쇄할 광고 디자인). 프로젝트를 애자일 프레임워크에 어떻게 적용할 수 있습니까?
A12: 애자일은 이와 같은 제약을 처리할 수 있습니다. 해야 할 일과 시기를 파악하고 그에 따라 스프린트를 계획하는 것은 팀의 몫입니다. 애자일은 스프린트마다 우선 순위와 계획된 작업(범위)을 조정할 수 있는 능력을 주므로 기한을 맞출 수 있습니다. 속도 추적을 시작하면 기한을 맞출 수 있는지 곧 알 수 있게 됩니다. 그런 다음 팀의 성공을 위해 필요한 것을 협상할 수 있는 능력은 훌륭한 팀 리더에게 달렸습니다.
Q13: 목표를 변경하면 범위 초과처럼 보이는 것이 아닙니까?
A13: 네, 그렇게 보이기는 하지만 저희는 프로젝트 중의 변화를 장려하고 싶기 때문에 '범위 초과'라고 하지는 않습니다. 애자일 철학의 가장 큰 장점은 통제 범위를 벗어난 것에 적응할 수 있다는 것입니다. 경쟁 환경이 변하거나 비즈니스 요구 사항이 변경되거나 사용 가능한 새로운 기술이 있을 때, 몇 개월이나 전에 만들어진 요구 사항 매트릭스를 느릿느릿 진행하고 싶으십니까? 고객에게 최고의 제품을 제공하려는 경우 변화를 받아들이고 유리하게 활용하세요. 애자일에는 '범위 초과'라는 것이 없습니다(여기에 제다이의 마인드 트릭을 넣으세요).
