국내 B2B의 SAFe 적용 사례

출처 : pixabay

 

 

오늘은 국내 대기업에 SAFe가 적용되어 운영되었던 B2B 사례의 적용 상황과 성과에 대해서 나누어봅니다. 

 

🏢 비즈니스의 특성 

 

 이번에 소개해드릴 사례는 특정 목적으로 만들어지는 하드웨어에 탑재되는 소프트웨어 입니다. 

 이 분야는 새로운 비전을 가지고 급부상하는 해외 기업들로 인해서 소프트웨어의 중요성이 매우 많이 강조되고 있으며 소프트웨어의 중요성이 커짐에 따라서 탑재된 소프트웨어의 크기도 빠르게 증가하고 복잡도 또한 빠르게 높아지고 있습니다.

 하나의 제품은 다양한 하드웨어로 구성되며 이를 제어할 소프트웨어가 탑재되고 사용자 접점의 소프트웨어도 있기에 이 제품의 소프트웨어 개발에는 다양한 회사가 참여합니다.

 

제품에 참여하는 회사들

 하드웨어 공급을 요청하는 고객이자 소프트웨어를 통합하는 A사는 사용자와 만나는 User Interface를 주로 개발합니다.

 소프트웨어를 OS 플랫폼을 제공하는 B사, 하드웨어 운영과 미들웨어, 일부 User Intreface를 개발하는 C사가 함께 하나의 제품에 들어가는 소프트웨어를 만들어 냅니다.

 

🔧 비즈니스의 변화 방향

 

 C사는 하드웨어 운용에 필요한 소프트웨어부터 User Interface를 모두 제공하였으나 User Interface에 대한 개발을 A사가 직접 담당하기 시작했으며 A사는 이전 프로젝트에서는 부분적인 범위에서 User-Interface를 개발하였으나 이제는 범위를 늘려 나아가고 있습니다. User Interface를 통해서 고객을 직접 만나고 고객의 니즈와 문제를 파악하고 빠르게 대응하기 위한 것으로 보입니다. 따라서 A사는 직접개발하는 범위를 늘려 조만간 User-Interface의 전체를 개발할 것으로 예상됩니다.

 

 이분야의 프로젝트의 개발기간은 1년~2년으로 매우 긴편입니다.

 이전에는 프로젝트 범위를 초기에 모두 결정하고 그 계획에 따라 소프트웨어를 개발했습니다. 예측하지 못한 상황이 발생하면 기능 변경을 위하여 Change Request로 진행하거나 추가적인 요청을 C사에 해야만 했습니다. 그리고 이 상황에서 추가적인 비용을 발생했습니다. CR과 추가적인 요청은 비용이 추가되기때문에 비용에 대한 협상이 완료되기 전까지는 새로운 요건에 대한 개발은 시작되지 못했습니다. 이는 시장의 변화에 빠르게 대응하는 것을 어렵게 만드는 요소였습니다.

 

🎤 고객의 니즈

 고객인 A사는 시스템이 크고 복잡해짐에 따라서 시스템의 요구사항을 초기에 확정하는 것에 큰 어려움을 겪고 있었습니다. 또한 요구사항을 확정하더라도 충분히 세밀하지 않아 업무량을 산정하기에 어려움이 있었습니다.

 그리고 시장의 변화와 경쟁사 제품의 신기능에 대응하기 위해서 프로젝트 시작 이후에도 많은 CR과 추가 개발이 필요해졌습니다. 과거보다 많은 CR과 추가 개발은 예상치 못한 과도한 개발비 증가로 이어졌습니다.

 

 고객인 A사는 애자일 방식으로 이문제를 해결하려고 하였고 그중에서 SAFe 방식을 선택하여 C사에 먼저 제안을 하며 C사의 Agile Journey가 시작되었습니다. A사는 사내에서 먼저 SAFe를 적용하였고 함께 소프트웨어를 만들어야하는 공급자인 C사에서도 SAFe 적용을 통해 통합적인 애자일 업무 체계를 마련했습니다.

 

📈 개선된 것들

 

 SAFe 방식의 적용을 통해서 프로젝트의 투명성과 구성원들의 자율성이 높아졌습니다.

 프로젝트의 투명성은 고객의 신뢰로 이어지고 이는 다시 구성원들의 자율성을 다시 높힙니다. 고객사인 A사는 C사의 진척을 언제나 확인할수 있었고 어떤 일들이 일어나는지 세세하게 파악할 수 있었습니다. A사와 C사는 통합적인 업무 관리 시스템을 사용하고 있었고 그 시스템은 A사가 제공한 것이기에 관리자 권한을 통해 손쉽게 C의 개발 진척을 확인할 수 있었습니다.

 

 추상적인 수준에서 일감을 예상하면 일이 단순해 보이고 어려워보이지 않지만 세세한 정보와 진척을 확인하며 일감의 실질적인 크기와 C사 구성원의 노력을 이해하게 됩니다.

 

 SAFe의 가장 중요한 이벤트 중 하나는 PI Plannig입니다. 이 회의의 결과물은 3개월간의 개발 계획이고 100명의 넘는 사람들이 참여하는 프로젝트에서의 3개월은 많은 비용을 사용하게 되고 따라서 플래닝 결과물은 높은 수준의 신뢰를 요구합니다.

 

 C사는 A사가 마련한 일감 리스트로 독립적으로 플래닝을 수행하였으며 플래닝이 종료된 이후 2~3일간 고객사와 플랜을 검토하는 시간을 가졌습니다. 고객의 요청한 내용이 애자일팀의 수용할 수 있는 업무량을 초과하는 경우도 많았는데요. 개발 기간 동안의 높은 투명성은 A사가 C사의 플랜을 신뢰하게 되는 효과를 만들었습니다. 그래서 서로 다른 이해관계가 있는 상황에서도 빠르게 플랜을 협상할수 있었죠.

 

 애자일팀에 대한 A사의 신뢰를 나타내는 사례 중 하는 C사의 애자일팀이 세운 계획을 고객이 너무 도전적이라며 오히려 만류했던 사건입니다. C사의 애자일팀의 만든 계획은 많은 스토리 포인트를 해결해야했고 그 스토리 포인트가 과거의 데이터보다 너무 높았던 것입니다. A사가 직접 산정한 스토리 포인트를 C사가 신뢰하고 있었다는 것을 보여준 사례였습니다.

 

 모든 개발팀이 직접 참여하는 PI 플래닝에서 수립된 계획은 매우 상세합니다. 과거의 PI의 개발 실적은 애자일팀의 계획이 합리적인지 아닌지 판단할 수 있는 자료로 활용됩니다. 따라서 고객은 계획을 보고 자신의 의견을 제사하기가 훨씬 수월합니다. A사가 애자일팀의 계획을 만류한 것도 이를 통해서 가능했던 것이죠.

 

 SAFe을 적용하기 전 계획의 변경에 대한 대응은 C사 PM의 주요 업무 였습니다. 계획 변경이 필요한 경우에 고객은 PM에게 CR을 요청했습니다. CR이 많아지면 PM이 병목이 되어 민첩한 변경을 방해했습니다.

 

 하지만 SAFe가 적용된 프로젝트는 CR에 대해서 두가지 지점이 개선됩니다.

 먼저 CR이 많지 않습니다. 계획을 3개월 단위로 수립하기 때문에 3개월 이후로 개발을 미룰 수 있다면 CR로 처리할 필요가 없습니다. 그냥 3개월 후에 PI 플래닝에 반영하면 그만입니다.

 두번째 PM이 더이상 병목이 되지 않습니다. 프로젝트의 계획이 PM에 의해서 수립되지 않습니다. PI플래닝에 참여한 각 애자일팀이 계획을 수립하기에 계획 변경도 애자일팀의 몫이고 더이상 PM은 CR의 병목이 되지 않습니다.따라서 좀더 빠르게 계획이 변경됩니다.

 

 📘 앞으로의 숙제

SAFe의 적용으로 A사의 신뢰도가 증가하고 C사의 자유도가 높아졌습니다.
하지만 이 이외에도 더 개선되어야 하는 부분이 많이 있는데요.

 

그 중에 하나가 애자일팀의 운용입니다. C사의 각 애자일팀은 전문 분야에 매핑되어 있었는데요. 계획의 모든 전문분야에 균일한 일감이 없다면 애자일팀의 업무가 균일하게 진행되지 못하는 경우도 있습니다.

 이러한 문제에 빠지지 않으려면 두 가지 솔루션이 있습니다.

 

 먼저, 일감을 요청하는 A사가 균일하게 요청을 할 필요도 있고 그리고 일감을 처리하는 C사도 업무가 균일하지 않을 경우에 이를 처리할 수 있는 멀티 목적을 추구하는 팀을 만들 필요가 있습니다.

 

 ✓ 마무리

 이 분야에서의 애자일 적용은 해외 대부분의 회사에서 이미 완료되었거나 적용되거나 시도되고 있고 해외 컨퍼런스를 통해서 확인할수 있습니다. 제가 C사에서 일하는 동안에도 해외 많은 고객사들은 애자일 방식의 협업을 요청하는 요청제안서를 수도 없이 확인했습니다. 어떤 방식을 선택할 것인지가 결정사항이지 할것인지 말것인지는 이미 과거의 결정이 되었습니다.