애자일을 향한 여정: Braze는 소프트웨어 프로젝트 관리 프로세스를 어떻게 재창조했습니까?

게시 됨: 2019-02-19

우리는 공식적인 프로젝트 관리에 큰 지장을 주지 않고 Braze를 구축하는 데 처음 5년 정도를 보냈습니다. 우리는 디자인 문서, Trello, 스프레드시트, 휴리스틱, 모범 사례 및 수많은 회의를 사용하여 엄청난 양의 작업을 수행했습니다. 동일한 프로젝트가 두 개 없었습니다. 일부는 현재 상태를 머리 속에 간직한 군대에 의해 운영되었고 다른 프로젝트는 거의 개별 커밋까지 세심하게 문서화되었습니다. 그것은 모두 잘 작동했습니다 ... 그렇지 않을 때까지.

2018년 초까지 우리는 몇 가지 근본적인 문제가 있다는 분명한 징후를 보기 시작했습니다.

  • 한 번에 너무 많은 프로젝트가 진행 중입니다.
  • 빌드 주기 후반에 변경되는 요구 사항이 너무 많습니다.
  • 다른 사람들이 작업하고 있는 것에 대한 투명성이 너무 낮습니다.
  • 사람들에게 프로젝트를 관리하고 작업을 적절하게 분할하는 방법에 대해 코칭하는 데 너무 많은 시간이 소요되었습니다.

이것들은 모두 상호 연결된 주요 문제 웹의 일부였습니다. 프로젝트의 우선 순위가 어떻게 지정되고, 언제 작업이 진행되고, 무엇을 구축할 예정인지 불분명했습니다. 문제는 가능한 한 핵심이었습니다. 우리는 어떻게 일합니까? 소프트웨어 프로젝트를 관리하는 방식을 근본적으로 바꿔야 할 때였습니다.

계획 세우기

숙고 끝에 우리는 엔지니어링 팀을 위한 검증된 방법론으로 이동하기로 결정했습니다. 우리는 보다 민첩하게 되기를 원했습니다.

이 새로운 도전에 접근하기 위해 우리는 전체 제품 및 엔지니어링 조직의 지식을 대표하고 활용할 그룹을 만들고 싶었습니다. 그래서 우리는 제품 관리, 디자인 및 엔지니어링을 대표하는 8명의 구성원으로 구성된 위원회를 만들었습니다. 관리자와 개인 기여자, 다양한 수준의 Agile 배경, 연공서열 및 경험을 가진 사람들이 포함되었습니다.

이 애자일 위원회(Agile Committee)는 다음과 같은 몇 가지 핵심 원칙을 확고하게 염두에 두고 상황에 접근했습니다.

  • 우리는 방법론과 소프트웨어 모두에서 가능하면 입증된 솔루션을 사용하고 싶었습니다. 독특하려면 많은 노력이 필요하며 우리는 필요하고 전략적인 영역에서만 독특하고 싶었습니다. 우리는 또한 사람들이 작업 관리에 대한 Google 모범 사례를 사용할 수 있기를 원했습니다. 더 나아가 사람들이 이미 대부분의 작업 방법을 알고 있는 Braze에 가입하도록 했습니다.
  • 우리는 같은 언어를 말할 수 있는 것이 중요하기 때문에 Braze의 제품 엔지니어링 팀이 운영 방식에서 대체로 일관되기를 원했습니다.
  • 우리는 독단적으로, 또는 깊이 생각하지 않고 아무 것도 하고 싶지 않았습니다. 방법을 선택하고 책을 읽는 것만으로는 충분하지 않습니다. 상식과 사려 깊은 반복이 하루를 지배한다는 것이 우리에게 중요했습니다.

이러한 지침으로 무장한 우리는 많은 조직에서 효과가 입증된 Agile 프레임워크인 Scrum을 사용하기로 결정했습니다. 널리 알려져 있고 확장 가능하며 Agile 프로세스를 구현하려는 경우 안전한 기본 선택입니다.

다음으로 우리는 두 가지 주요 결정에 직면했습니다. (1) 새로운 프로세스를 지원하기 위해 어떤 도구를 사용해야 하는지, (2) 프로세스에 변경 사항을 적용하는 방법입니다. 우리는 여러 소프트웨어에 대해 이야기하고, 평가하고, 시연했으며, 궁극적으로 Atlassian의 Jira가 우리에게 올바른 선택임을 입증했습니다. 그것은 잘 입증된 솔루션입니다. 우리 팀의 몇몇 사람들은 이미 그것을 사용한 경험이 있고 Braze 내의 다른 팀은 이미 그것을 사용하고 있습니다. 우리 모두가 하나의 시스템 내에서 작업하기 때문에 더 나은 팀 간 협업을 위한 기회가 열립니다.

Agile의 출시 계획을 선택할 때 몇 가지 중요한 결정을 내려야 했습니다. 첫째, 팀을 어떻게 훈련/활성화합니까? 우리는 애자일 코치를 고용하거나, 팀에서 경험이 있는 사람들이 다른 사람들을 훈련시키는 일을 하도록 하거나, 도움을 줄 컨설턴트를 구할 수 있습니다. 둘째, Agile에 대한 약간의 경험이 있는 엔지니어링 팀을 구현하기 전에 교육을 기다리도록 해야 합니까?

결국 우리는 Jira와 Scrum에 익숙한 팀이 가능한 범위에서 시작할 수 있도록 하고 조직 전체의 전환을 돕기 위해 컨설턴트를 고용했습니다. 우리는 다음과 같은 이유로 전환을 통해 팀 구성원을 코칭하는 일차적인 책임을 우리 팀이나 독립 플레이어에게 두는 데 관심이 없었습니다.

  • 우리는 개별 팀이 우리가 Agile을 수행하는 방식을 소유하는 것을 원하지 않았으며 교육이 더 잘 받아들여지고 제안이 제3자로부터 온다면 더 포괄적일 것이라고 느꼈습니다.
  • 컨설팅 사업이 개별 Agile Coach보다 더 안정적이고 신뢰할 수 있다고 생각했습니다.
  • 우리는 전체 엔지니어링 조직에 대한 기본 교육을 받고 조직의 개별 구성원이 Agile에 대해 가지고 있는 지식에 대해 가정하지 않고 시작하기를 원했습니다.
  • 마지막으로, 우리 조직의 모든 사람이 앞으로 프로세스를 유지 관리할 책임이 있다는 것을 분명히 하기 위해 코치가 특정 시점에 떠나도록 하고 싶었습니다.

우리는 많은 조직에서 효과가 입증된 Agile 프레임워크인 Scrum을 사용하기로 결정했습니다. 널리 알려져 있고 확장 가능하며 Agile 프로세스를 구현하려는 경우 안전한 기본 선택입니다.


브라이언 휠러
Braze의 제품 엔지니어링 부사장

계획 실행

몇 달 간의 계획 끝에 우리는 우리가 하려는 모든 것을 자세히 설명하는 큰 문서를 얻었고 피드백을 위해 조직 전체와 공유했습니다. 그런 다음 여러 공급업체를 평가한 후 Eliassen을 애자일로의 여정에서 파트너로 선택했습니다. 그 여정은 Eliassen이 운영하는 2일의 애자일 교육으로 시작되었으며, 그 후 Eliassen이 우리를 연결해 준 전문가로부터 3개월 간의 애자일 코칭이 이어졌습니다.

처음부터 우리는 Jira와 Scrum으로 이동하는 것에 대해 상당히 신중했습니다. 인터넷과 우리 팀의 개인적인 경험은 지나치게 독단적인 접근의 위험, Jira가 "반 패턴"으로 기능하게 되는 방법, Scrum이 조직에서 잘못될 수 있는 모든 방법에 대한 경고 이야기로 가득 차 있습니다. 우리가 컨설팅한 사람들은 이러한 변경에 시간이 걸릴 수 있으며 Agile의 진정한 이점을 보기 전에 성장통이 있을 수 있다는 경고를 많이 받았습니다.

고맙게도 우리는 새로운 프로세스에서 즉시 가치를 찾았습니다. 이 전환의 좋은 점 중 하나는 스크럼의 특정 측면을 맹목적으로 따라야 한다는 압박감을 전혀 느끼지 못했다는 것입니다. 더 나은 작업을 위해 몇 주에 한 번씩 상황을 회고한 다음 수정해야 할 사항을 수정합니다. 그리고 3개월의 코칭 기간 동안 우리는 엔지니어링 조직 전반에 걸쳐 다음과 같은 전면적인 변경 사항을 구현했습니다.

  • 모두가 사용자 스토리를 작성하고, 정리하고, 지적하고, 분류하고, 선택하는 방법을 배웠습니다.
  • 스탠드업은 당면한 작업을 마무리할 때 새로운 초점을 찾았습니다.
  • 제품, 디자인 및 엔지니어링은 모두 동일한 언어로 말하는 법을 배웠고 인터페이스는 점점 더 잘 설계되었습니다.

결과

이제 약 6개월 간의 노력의 반대편에 있으므로 변경 사항은 분명하고 극적입니다. 이러한 노력으로 이어진 문제가 크게 감소했습니다. Agile을 통해 우리는 이제 사인오프, 협업, 백로그 생성 및 정리에 대한 명확하고 이해하기 쉬운 메커니즘을 갖게 되었으며 개선해야 할 사항에 대한 회고를 정기적으로 실행합니다.

우리는 또한 디자인 아티팩트를 위한 훨씬 더 일관된 위치를 가지고 있을 뿐만 아니라 주어진 프로젝트에서 실제로 "완료"된 것이 무엇인지에 대한 더 나은 정렬된 기대치를 가지고 있습니다. 다른 팀이 어떤 작업을 하고 있는지 보는 것이 쉬워지고 사람들이 함께 잘 일하는 방법을 이해하는 것이 그 어느 때보다 간편해졌습니다.

이 전환의 마지막 단계에서 내가 알아차린 것은 우리가 더 많은 일을 하고 팀 규모를 성장시켰음에도 불구하고 주어진 시간에 조직의 총 공개 풀 리퀘스트 수가 감소했다는 것입니다. 작은 증분으로 작업하고 마무리 작업에 집중함으로써 비행 중인 항목의 수가 크게 줄어들었습니다.

우리 조직에서 거둔 성공은 다른 사람들에게도 영감을 주었습니다. 우리는 Braze의 다른 부서에 있는 팀이 자체 Agile 혁신을 시작하는 것을 보기 시작했습니다. 따라서 곧 더 많은 사람들이 동일한 언어를 사용하고 협업을 정의하고 개선하는 데 필요한 도구를 갖게 될 것입니다.

테이크아웃

우리 노력의 두 가지 주요 요소가 성공을 보장했습니다.

첫째, 엔지니어링 조직과 다양한 관점에서 의견을 수렴하기 위해서는 대표 위원회가 주도한다는 사실이 필수적이었습니다. 회사 전체에서 사람들은 일상 업무에 영향을 미칠 문제에 대해 의견을 듣고 대표되는 느낌을 받았습니다. 팀과 공유할 수 있는 Agile 전환에 대한 동기와 계획을 설명하는 철저한 문서의 후속 작성도 매우 유용했습니다. 우리는 컨텍스트를 제공하고 피드백을 제공할 아티팩트를 설정하기 때문에 의사 결정이 내려지는 방식을 보여주고 피드백을 위한 명확한 경로를 도입한다고 믿습니다.

둘째, 우리 팀의 코치를 도울 제3자를 구하는 결정이 필수적이었습니다. 객관적이고 경험이 풍부한 파트너를 통해 프로세스를 빠르게 개선할 수 있었습니다. 우리 코치는 좋은 것이 무엇인지 알고 있었고 편견 없이 추천할 수 있었습니다. 우리는 여러 번 "팀이 일반적으로 X를 어떻게 합니까?"라고 질문할 수 있었습니다. 즉각적이고 실행 가능한 솔루션을 얻을 수 있습니다. 반면에 내부 리소스를 사용했다면 우리가 받은 피드백이 편향된 당사자로부터 제공되고 기존 책임에 대한 리소스 경합이 증가할 위험이 있었습니다.

다른 건 없나요?

우리가 우리 제품에 대해 어떻게 생각하는지, 그리고 그것을 만드는 데 필요한 작업에 대해 더 알고 싶으시다면 Building Braze를 확인하세요. 우리 팀에 합류하고 싶으십니까? 현재 채용 공고를 확인하세요.