어둠의 불경 한 화신 인 SAFe (기업을위한 확장 된 애자일 프레임 워크)를 조심하세요.
… 아니면 그렇지 않을 수도 있습니다.
SAFe가 스스로 말하고 싶다면 사용할 수 있습니다. 위의 링크. 수백 페이지의 문서, 몇 시간의 동영상, 15 개의 다양한 교육 과정 등이 있습니다. 조금만 들리시면 SAFe가 어떻게 작동하는지 설명하기 위해 최선을 다하겠습니다.
“포트폴리오”라고하는 가장 높은 수준에서 SAFe는이를지지합니다. 무기한 “가치 흐름”자금 조달-일반적으로 제품, 제품 라인 또는 고객 유형을 나타냅니다. 그러나 자금을 제어하는 린 포트폴리오 관리 기능 (LPM) (이전에 폭포 스타일 프로젝트 예산을 담당했던 동일한 사람들)은 각 스트림으로 이동하는 포트폴리오 에픽 (대규모 이니셔티브)을 승인 할 수있는 유일한 권한이 부여됩니다. 에픽은 해결해야 할 문제에 대한 설명이 아닙니다. 이러한 문제를 가장 잘 해결하는 방법에 대한 미리 만들어진 아이디어입니다.
팀을 전략적인 기능이 아닌 “전달”기능으로 보는 구식 사고 방식의 징후를 바로 볼 수 있습니다. 수준의 사고 자들은 아이디어를 내고, 낮은 수준의 행동 자들은 그 아이디어를 실행합니다. 작업에 가장 가까운 사람들이 결정을 내릴 수있는 가장 좋은 장비가 될 가능성은 무시됩니다.이 잘못된 사고 방식에서 벗어나는 것이 Agile 사고의 핵심 목표입니다. SAFe는 원격으로 달성하지 못합니다.
약간 낮은 수준을 보면 비슷한 문제가 다시 나타납니다.
SAFe는 소규모 제품 팀 (종종 스크럼 팀)을 “Agile Release Trains”로 수집합니다. ”— “프로그램 수준”에서 각 그룹에 걸쳐 추가 관리 역할 계층이있는 팀 그룹입니다.
일반적으로 이러한 역할은 팀의 자율성을 방해합니다. 이러한 역할은 비율에 비해 프로세스 및 커뮤니케이션 오버 헤드를 추가합니다. 제공하는 가치를 제공합니다.
이러한 역할에는 PM (Product Manager), S ystem Architect (SA) 및 Release Train Engineer (RTE).
SA와 PM은 더 큰 작업 (종종 위의 포트폴리오 프로세스에서 상 속됨)을 정의하고 분할 한 다음 팀.
제품 소유자와 팀은 이론적으로 자신에게 부과 된 작업에 대해 다른 작은 작업의 우선 순위를 지정할 수 있지만 이러한 노력은 가시성과 위에서의 동의를 제한했습니다. 모든 팀원이 다른 항목이 더 가치가 있다고 믿더라도 가장 높은 지점에서 오는 작업을 가장 중요한 것으로 취급해야한다는 자연스러운 압력이 있습니다. 이 때문에 제품 소유자의 역할은 원래의 의도였던 제품 리더십에 대한 단일 책임 지점이 아닌 스토리 작성 및 승인 기준 확인으로 축소됩니다.
시스템 설계자 실제 엔지니어링 작업에 가까운 위치에 있지 않기 때문에 그들이 전달하는 건축 계획은 작업의 현실과 단절 될 수 있습니다. 이러한 종류의 역할은 대규모 설계-전방 폭포 프로젝트의 특징이었으며 SAFe에 잘 보존되어 있습니다.
릴리스 트레인 엔지니어는 일관된 팀 간 프로세스 및 케이던스를 정의하고 많은 운영 작업을 처리합니다. 궁극적으로 개별 팀이 기존 표준에서 벗어나는 방식으로 자신의 관행을 수정, 개선 또는 실험 할 여지가 줄어 듭니다.
때로는 이러한 모든 문제가 “대규모”를 추가하여 다시 반복됩니다. 솔루션 수준”— 프로그램 수준의 역할과 유사하지만 릴리스 트레인에 걸쳐있는 팀 그룹입니다.이 경우 동일한 문제가 반복 될 가능성이 높지만 솔루션 수준은 덜 일반적으로 적용되는 것 같습니다.
SAFe (종종)는 Rally와 함께 번들로 제공됩니다. 팀 자율성을 더욱 제한합니다.
SAFe는 종종 프로젝트 관리 소프트웨어 Rally와 패키지 거래입니다. Rally는 기대할 수있는 일종의 소프트웨어입니다. SAFe를 사용하는 회사는 기능이 너무 많고, 초점이 맞지 않고, 혼란스럽고, 불안정하며, 결과적으로 배우고 사용하기가 어렵습니다.
리더십을 위해 Rally를 채택한 가치 제안은 그들이 볼 수 있다는 것입니다. 간단하고 통합 된 그림을 제공하는보고 기업 전체에서 진행 상황과 문제가 발생합니다.
물론 기업의 모든 사람이 Rally를 사용해야 할뿐만 아니라 Rally를 일관된 방식으로 사용해야한다는 의미입니다. 다시 말하지만 이는 하향식 받아쓰기를 통해서만 가능합니다. Rally와 작업에 대한 생각 방식은 선호도, 컨텍스트 또는 동의에 관계없이 모든 팀에 적용됩니다. 실제로 모든 정보를 롤업하려면 예측 및 추적에 엄청난 오버 헤드가 필요하여 모든 것을 느리게하고 실제로 작업을 수행하는 데 매우 지장을 줄 수 있습니다.
또한 최상위 수준보고는 특히 유용하지 않습니다. Rally가 추적하는 것, 즉 전달 된 스토리 포인트의 양 (문자 그대로 구성됨) 또는 해결 된 버그의 양 ( “제품 품질”에 대한 끔찍한 척도)에 중점을 둡니다.경영진이 이러한 통계를 무시하면 추가되는 오버 헤드는 아무 소용이 없습니다. 메트릭을 관리하면 팀이 멋지게 보이고 홀로 남겨질 수 있도록 통계가 퍼질 것입니다. 추정치가 과도하게 채워지고 작은 작업 부분이 과장되어 쉽게 신뢰가 무너질 수 있습니다.
SAFe는 종속성 관리에있어 최악의 접근 방식을 취합니다.
A 종속성은 팀이 자신의 작업을 완료하기 전에 다른 곳에서 수행 될 작업을 기다려야하는 경우입니다. SAFe는 의존성이 수용되고 관리되어야하는 불변의 삶의 사실이라는 후진 적 태도를 중심으로 구성됩니다. 때로는 전략적 이점이라고도합니다. 실제로 종속성을 나쁜 것으로 생각할 때 (모든 기회에서 최소화해야 함) 이러한 기회가 풍부하고이를 활용하면 주로 이익이 발생한다는 것을 알 수 있습니다. 다음은 SAFe가 강조하지 않거나 완전히 무시하는 몇 가지 제안입니다.
- 한 팀이 다른 팀에 의존하지 않고 다른 팀의 코드 기반에 작업을 제출할 수있는 내부 소싱 문화를 장려합니다. 합병 수락
- 합리적 일 때 팀원이 팀을 임시 또는 영구적으로 쉽게 교체 할 수 있도록합니다.
- 팀을 고용, 구조화 및 교육에 집중하여 자신의 요구 사항을 처리합니다. 외부 도움없이
SAFe가 실제로 종속성을 관리하기 위해 선택하는 방법은 계획, 프로세스, 계층 구조 및 표준화에 대한 집중력을 높이는 것입니다. 예상대로 이로 인해 업무 수행을 방해하는 회의가 많이 발생합니다. 한 번에 전체 조직에 영향을 미치는 보편적 인 롤아웃을 통해 이러한 접근 방식을 적용합니다. 추가 부담스러운 구조없이 자립 할 수있는 영역은 고려하지 않습니다.
SAFe는 계획에 지나치게 집중되어 있습니다.
SAFe의 핵심 기능은 ~ 10 주라는 아이디어입니다. 프로그램 증분 (PI). 이러한 종류의 일반 스프린트를 모두 포함하는 거대한 스프린트라고 생각할 수 있습니다.
각 PI는 약 2 일 동안 실행되는 PI 계획 이벤트로 시작됩니다. PI 계획에는 또한 프로그램 수준의 사전 계획 및 사후 계획 활동이 필요합니다.
사람들이 직접 모여 관계를 구축하고 정보를 공유하며 목표를 지향하도록하는 것은 확실히 가치가 있습니다. 반면에 제한된 시간 창을 사용하여 사전 정의 된 기능을 기반으로 특정 사용자 스토리의 10 주 계획을 만든 다음 해당 계획에 대한 약속을 요구하는 것은 훨씬 덜 가치가 있습니다.
PI 계획이 종료되는 즉시 제한된 이해와 수많은 가정은 새로운 것을 배우는 즉시 쓸모 없게 될 것입니다. 팀은 자신이 배운 계획이 타당하지 않은 계획을 고수하는 것과 상위 팀이 이해할 수없는 이유에 대한 기대치를 다시 조정하는 것 사이에서 끊임없이 갈등을 겪을 것입니다.
SAFe는 볼륨을 중심으로합니다. 가치가 아님
파이프 라인을 통한 볼륨 메트릭, 추정 및 이탈 작업에 대한이 모든 초점에서 실제로 가치가 있거나 성공적인 것이 무엇인지에 대한 개념은 쉽게 상실됩니다. 제품의 경험이 실제로 고통스럽고 사용자가 추가 기능의 혜택을받지 못하는 경우에도 출고되는 더 많은 작업이 “가치”여야한다고 가정하는 경우가 많습니다.
SAFe는 다음과 같은 비판을 알고 있습니다. 가치에 초점을 맞추지 않고 최근에 “디자인 적 사고”, “고객 중심성”및 기타 개념을 문서에 추가하여이를 보완했습니다. 지금까지 프로세스에서 실제로 그러한 일을위한 공간을 만드는 중요한 변경을 수행한다고 확신하지 않습니다. 예를 들어 SAFe의 “고객”에 대한 정의는 비즈니스 이해 관계자 또는 가치 흐름에 자금을 지원하는 사람들을 “고객”으로 정의 할 수있는 기회를 제공합니다. 디자인 사고의 핵심 요소 인 소프트웨어를 실제로 사용하는 최종 사용자의 요구에 집중하도록 모든 사람 (자금을 제공하는 사람 포함)의 방향을 바꾸는 것과는 매우 다릅니다.
SAFe는 불필요하게 복잡합니다
SAFe는 비판에서 나온다. 너무 복잡해서 완전히 이해하기 어렵습니다. 프레임 워크를 조사하는 데 추가로 시간을 들였음에도 불구하고 여전히 일부 문제가 발생하거나 중요한 사항을 놓칠 가능성이 높습니다. 그러나 풍부한 복잡성은 그 자체로 정당한 문제입니다. SAFe에는 회의, 체크 포인트, 가치 및 방법이 너무 많아 기본적으로 모든 사람을 동일한 페이지에 표시하는 것이 불가능합니다.
SAFe는 회고 및 지속적인 개선을 제한합니다.
프로그램 수준 및 위는 모든 팀 회고에 참석할 수 없습니다.즉, 논의중인 많은 사항을 실제로 변경할 수있는 사람들은 회고전을 직접 듣지 않을 것입니다.
SAFe가이를 보완하려는 방식으로는 충분하지 않습니다.
PI 계획 릴리스 트레인의 모든 사람이 직접 대면 할 수있는 유일한 시간입니다. 안타깝게도 계획 이벤트 자체의 성공과 관련된 짧은 회고전이 포함되어 있습니다.
SAFe는 각 PI의 끝 부분에 “검사 및 조정”이벤트를 포함하지만 거의 생략하도록 설계되었습니다. RTE를 위해 조정하는 것이 얼마나 어려운지에 대한 것입니다. 개최되면 이벤트는 물론 마지막 PI의 볼륨 메트릭을 검토하여 준비됩니다. 또한 이벤트의 30 분만 문제가 드러나고 합의 된 실제 회고에 할당됩니다. 이 시간이 100 인 릴리스 트레인의 모든 구성원에게 균등하게 분할되면 각 참가자는 ~ 10 주마다 약 18 초 동안 실제로들을 수있는 상황에서 문제를 제기 할 수 있습니다.
SAFe에는 팀이보다 광범위하게 설문 조사를 실시하는 “평가 차트”와 같은 다른 요소도 있지만, 이는 SAFe 관행이 효과적인지 아닌지가 아니라 준수되고 있는지 확인하는 데 크게 의존합니다.
SAFe 집계 된 개념을 저하시킵니다.
키 제가 아직 다루지 않은 SAFe의 일부는 Scrum, Kanban, Lean Product, Lean UX 및 DevOP와 같은 기존 개념의 집합입니다.
잘 모르는 경우 각 개념을 탐색하는 것이 좋습니다. 한 번에 모두가 아니라 시간이 지남에 따라 독립적으로. 많은 것들이 그 자체로 가치가 있지만 SAFe는 실제로 그것들을 합성하는 데 큰 역할을하지 못하며 때로는 혼란을 더할 수 있습니다. 적절한 사례 :
SAFe는 관행이 “Lean-Agile”원칙을 따르는 방식을 일상적으로지지합니다. 트릭은 “Lean-Agile”이 실제로 “Lean”또는 “Agile”원칙을 참조하지 않는다는 것입니다.
대신 “Lean-Agile Principles”는 SAFe 고유의 디자인을 만든 것입니다.이 새로운 “원칙”세트는 그것이 동화되는 개념을 왜곡합니다. 예를 들어, 탈 중앙화 결정에 대한 페이지 (모든 원칙 중 가장 낮은 순위)는 많은 사용 사례에서 중앙 집중화 의사 결정의 중요성을 강조함으로써 미묘하게 전복됩니다. 나열된 다른 원칙에도 비슷한 문제가 있습니다. 이 모든 정보를 한꺼번에 접하게되면 원래 개념의 실제 의미를 잃을 수 있습니다.
SAFe는 민첩하지 않습니다.
지금까지 SAFe의 여러 방식 애자일 사고 방식과 일치하지 않는 것은 매우 명확해야합니다. 계획에 초점을 맞추고, 관료적이고, 복잡하며, 불필요한 프로세스가 많고, 팀 자율성을 무력화하는 등의 작업이 포함됩니다.
하지만 우리가 진정으로 관심을 갖는 것이 효과 일 때 SAFe가 Agile인지 여부는 중요합니까? ?
예. 그렇습니다.
애자일 원칙은 일반적으로 효과적인 것으로 인식되고 동의 되었기 때문에 애자일 원칙 일뿐입니다. 그 생각은 더 광범위한 실무자 커뮤니티와 공감했고 이것이 운동이 원래 시작된 이유입니다. 민첩성이 효과의 예측 인자라고 생각한다면 (아마도 SAFe에 대한 관심의 일부 뒤에있는 믿음) SAFe가 Agile 사고와 일치하는지 여부는 상당히 중요합니다. 사람들이 구매하는 제품에 대해 오도하는 것은 나쁜 일이며이를 알리는 것은 잘못된 것이 아닙니다.
SAFe가 효과가있는 것으로 나타난 모든 사례 연구는 어떻습니까?
scaledagileframework.com에는 성공적인 SAFe 채택에 대한 약 40 개의 사례 연구가 있습니다. 실패 사례 연구가 눈에 띄게 없습니다. 약어와는 달리 SAFe는 막대한 위험을 초래하는 막대한 생태계 전반에 걸쳐 거대한 새 프로세스에 대한 동시 변경을 포함합니다. 40 개의 성공적인 기업 각각에 11,250 명의 인증 된 SAFe 실무자를 보유하고 있지 않는 한, 우리가 듣지 못하는 기업이 꽤 많습니다.
또한, 사례 연구에 너무 많은 정보를 넣지 않습니다. 있다. 그들이 집중하는 볼륨 측정 항목이 정말 가치가 있더라도 일이 잘 된 것처럼 보이게하는 몇 가지 통계를 선택하는 것은 쉽습니다.
특정 예에 집중하기 위해 발췌 부분을 살펴 보겠습니다. Fitbit의 SAFe 구현에 대한 사례 연구에서 발췌 :
2016 년 소비자 기술 회사 인 Fitbit은 시장에 네 가지 신제품을 출시했으며 2,200 만 대 이상의 장치를 출하했습니다. 1 년에 가장 많은 수의 제품을 제공하는 것은 부분적으로는 목표 날짜를 충족하도록 팀을 확장하는 방법으로 SAFe® (Scaled Agile Framework®)를 채택하려는 회사의 노력과 성공 덕분입니다.
© Scaled Agile, Inc.
다음은 지난 5 년 동안 Fitbit의 주가입니다.
예… 2016 년은 Fitbit에게 멋진 해가 될 것 같습니다.
이제 Fitbit의 몰락을 SAFe에 기인 할 수는 없습니다. 우리가 가지고있는 정보의 양으로 채택.그러나 회사가이 정도의 어려움을 겪고 제품 결정의 대응력을 향상시키기 위해 SAFe 채택을 환영한다면 나머지 사례 연구를 살펴볼 때 눈을 좀 더 좁힐 것입니다.
그렇지만 과도기 단계로는 괜찮지 않습니까?
당신이이 주장을 할 사람이라면 SAFe를 멀어지게해야한다고 생각해야합니다. 이 시점에서 우리는 동의합니다!
그 전환을 위해 우리는 물론 제대로 작동하지 않는 부분을 지적하는 데 시간을 투자해야합니다.
많은 시간을 보냈습니까?
그렇다고해도 SAFe는 실제로 전환하지 못하도록 설정되어 있습니다. 관리의 손에 부여하는 권한은 하향식 제어 정신의 정당화 역할을합니다. 이것은 우리가 이미 다루었던 프로세스 개선을위한 부족한 방법과 잘 어울리지 않습니다. 적절한 상황에 맞게 SAFe를 “사용자 정의”할 수있는 권한은 대부분 작동하지 않는 것을 인식 할 수있는 최적의 위치에있는 실제 팀에서 사용할 수 없습니다.
SAFe 로드맵의 어느 곳에서도 실제로 어떤 것을 언급하지 않습니다. 과도기적 인 핵심 관행입니다. 과도기적 프레임 워크 인 경우 모든 종류의 전환 계획을 제공하는 데는 매우 부실합니다.
인증에 집중하는 것은 프레임 워크의 유연성을 손상시킵니다. . 인증을 받기 위해 노력하는 데 시간과 시간을 투자하면 인증은 자신의 가치의 일부가됩니다. SAFe와 비슷하지 않은 것으로 전환하는 것이 그 가치를 위협하는 것처럼 보일 수 있습니다. 인증을받은 사람을 탓할 수는 없습니다. 인력 시장 인증이 중요한 곳. 그러나 이러한 개인은 SAFe의 단점과이를 개선하거나 이탈 할 수있는 가능한 방법에주의를 기울여야 할 특별한 책임이 있습니다.
이러한 문제는 광범위하게 경험됩니다
나는 혼자가 아닙니다. 이러한 비판을 많이 표현합니다. 프레임 워크의 특정 관행과 연결하는 데 조금 더 나아 갔으면합니다. 확증적인 증언을 찾고 계신다면 다음과 같은 몇 가지 사례를 소개합니다.
Scrum의 공동 개발자 인 Ken Schwaber는 빠르면 2013 년에 SAFe에 대해 심각한 우려를 표명했습니다.
Nicholas M. Chaillan , 미 공군 최고 소프트웨어 책임자는 “SAFe (Scaled Agile Framework)와 같은 엄격한 규범 적 프레임 워크 사용”을 권장하지 않습니다.
Forbes 기고자 인 Steve Denning은 다음 기사에서 SAFe를 “특히 걱정”한다고 말합니다. 가짜 애자일을 발견하는 방법.
실리콘 밸리 제품 그룹의 Marty Cagan이 SAFe가 실리콘 밸리 기업의 사고 방식에 반대되는 방식을 설명합니다.
안전을 유지하세요 (SAFe가 아님)
SAFe는 확실히 많은 비판을 받았지만 , 내 개인적인 감각은이 비판이 특정 온라인 서클을 넘어서는 많은 청중에게 도달하지 않았을 수 있다는 것입니다. 매일 프레임 워크를 채택하는 기업의 수가 증가하는 것과 함께 고려할 때 특히 그렇습니다.
많은 사람들에게 SAFe에 문제가 있거나 Agile 원칙과 전혀 상충된다는 생각은 완전히 새로운 것입니다.
더 많은 청중을 대상으로하는 토론이 늘어 나면 도움이 될 수 있습니다. 앞으로이 주제에 대해 더 다루고 다른 대안이 무엇인지 자세히 설명하고자합니다.
현재로서는 SAFe 환경에서 작업하지 않더라도 만족할 수있는 변명은 아닙니다. . 제가 여기에 제시 한 우려 사항은보다 광범위한 경고로 간주되어야합니다. 가장 현명한 아이디어라도 세심한주의를 기울이지 않으면 쉽게 채택되고, 손상되고, 혼란스러워 질 수 있습니다.