Journey to Agile: cómo Braze reinventó su proceso de gestión de proyectos de software

hacer un plan

Después de reflexionar, decidimos avanzar hacia una metodología comprobada para los equipos de ingeniería: decidimos que queríamos ser más ágiles.

Para abordar este nuevo desafío, queríamos formar un grupo que representara y aprovechara el conocimiento de toda nuestra organización de productos e ingeniería, por lo que creamos un comité con ocho miembros que representan la gestión, el diseño y la ingeniería de productos. Incluimos tanto gerentes como colaboradores individuales, así como personas con diferentes niveles de antecedentes, antigüedad y experiencia en Agile.

Este Comité Ágil, como lo llamamos, abordó la situación con algunos principios clave firmemente en mente:

• Queríamos utilizar soluciones comprobadas siempre que fuera posible, tanto en metodologías como en software. Se necesita mucho esfuerzo para ser único y queríamos ser únicos solo en áreas necesarias y estratégicas. También queríamos que las personas pudieran buscar en Google las mejores prácticas sobre cómo administrar su trabajo o, mejor aún, que las personas se unieran a Braze y que ya supieran cómo hacerlo.
• Queríamos que los equipos de ingeniería de productos de Braze fueran en gran medida coherentes en su forma de operar, porque poder hablar el mismo idioma es valioso.
• No queríamos hacer nada dogmáticamente, o sin pensarlo bien. Simplemente elegir un método y luego seguir el libro no era lo suficientemente bueno; era importante para nosotros que el sentido común y la iteración reflexiva gobernaran el día.

Armados con esas pautas, decidimos hacer uso de Scrum, que es un marco Agile que ha demostrado ser efectivo para muchas organizaciones. Es ampliamente conocido, es escalable y es la opción segura y predeterminada cuando busca implementar un proceso Agile.

A continuación, nos enfrentamos a dos decisiones principales: (1) qué herramientas deberíamos usar para respaldar nuestro nuevo proceso y (2) cómo deberíamos implementar los cambios en nuestro proceso. Hablamos, evaluamos y demostramos varias piezas de software y, en última instancia, Jira de Atlassian demostró ser la opción correcta para nosotros. Es una solución bien probada, varias personas de nuestro equipo ya tenían experiencia en su uso y otros equipos dentro de Braze ya la estaban usando, lo que abre una oportunidad para una mejor colaboración entre equipos porque todos trabajaríamos dentro de un solo sistema.

Cuando se trataba de seleccionar un plan de implementación para Agile, teníamos que tomar algunas decisiones clave. Primero, ¿cómo entrenamos/capacitamos al equipo? Podríamos contratar a un entrenador Agile, hacer que personas con experiencia en el equipo hagan el trabajo de capacitar a los demás o conseguir consultores para ayudar. En segundo lugar, ¿deberíamos hacer que los equipos de ingeniería que tenían algo de experiencia con Agile esperaran a recibir capacitación antes de implementarlo?

Al final, decidimos dejar que los equipos que estaban familiarizados con Jira y Scrum comenzaran en la medida en que se sintieran capaces, y contratamos a un consultor para ayudar con la transición en toda la organización. No estábamos interesados ​​en que personas de nuestro equipo o un jugador independiente fueran los principales responsables de entrenar a los miembros del equipo durante la transición porque:

• No queríamos que ningún equipo individual se hiciera cargo de cómo hacemos Agile y sentimos que la capacitación sería mejor recibida y las sugerencias serían más inclusivas si vinieran de un tercero.
• Pensamos que un negocio de consultoría sería más estable y más confiable que un entrenador Agile individual
• Queríamos tener una capacitación básica para toda la organización de ingeniería y comenzar sin hacer suposiciones sobre el conocimiento que los miembros individuales de la organización tenían sobre Agile.
• Finalmente, queríamos que los entrenadores se fueran en un momento determinado, para dejar en claro que todos en nuestra organización eran responsables de mantener el proceso en marcha.

Ejecutando el Plan

Después de un par de meses de planificación, teníamos un gran documento que detallaba todo lo que pretendíamos hacer y lo compartimos con la organización en general para recibir comentarios. Luego, después de evaluar a varios proveedores, seleccionamos a Eliassen para que se asocie con nosotros en el viaje hacia Agile. Ese viaje comenzó con una capacitación Agile de dos días dirigida por Eliassen, seguida de tres meses de entrenamiento Agile de un experto con el que Eliassen nos conectó.

Desde el principio, fuimos bastante cautelosos a la hora de cambiarnos a Jira y Scrum. Tanto Internet como las experiencias personales de nuestro equipo estaban llenas de advertencias sobre los peligros de los enfoques demasiado dogmáticos, sobre cómo Jira puede llegar a funcionar como un "antipatrón" y todas las formas en que Scrum puede fallar en las organizaciones. Las personas a las que consultamos nos advirtieron en gran medida que estos cambios probablemente llevarían tiempo y que bien podría haber dolores de crecimiento antes de que viéramos los beneficios reales de Agile.

Afortunadamente, instantáneamente encontramos valor en el nuevo proceso. Una de las cosas buenas de esta transición es que nunca sentimos la presión de seguir ciegamente ningún aspecto particular de Scrum; para que las cosas funcionaran mejor, hacíamos una retrospectiva de cómo iban las cosas cada dos semanas y luego modificábamos lo que había que modificar. Y a lo largo de los tres meses de entrenamiento, implementamos cambios radicales en toda la organización de ingeniería:

• Todos aprendieron a escribir, preparar, señalar, desglosar y recoger historias de usuarios.
• Standups encontró un enfoque renovado cuando se trataba de terminar el trabajo en cuestión
• Producto, Diseño e Ingeniería aprendieron a hablar los mismos idiomas, y las interfaces estaban cada vez mejor diseñadas

Los resultados

Ahora que estamos del otro lado de este esfuerzo de aproximadamente seis meses, los cambios son claros y dramáticos. Hemos visto una reducción significativa en los problemas que llevaron a este esfuerzo. Con Agile, ahora tenemos mecanismos claros y fáciles de entender para la aprobación, la colaboración, la creación de trabajos pendientes y la preparación, y realizamos retrospectivas periódicas sobre qué mejorar.

También tenemos ubicaciones significativamente más consistentes para los artefactos de diseño, así como expectativas mejor alineadas sobre lo que realmente es "hecho" para un proyecto determinado. Ver en qué están trabajando otros equipos se ha vuelto fácil y es más simple que nunca para la gente entender cómo trabajar bien juntos.

Algo que noté al final de esta transición es que la cantidad total de solicitudes de extracción abiertas en la organización en un momento dado había disminuido, incluso cuando estábamos haciendo más y aumentando el tamaño de nuestro equipo. Al trabajar en incrementos más pequeños y concentrarse en terminar las cosas, la cantidad de artículos en vuelo se redujo significativamente.

El éxito que hemos tenido en nuestra organización también ha inspirado a otros. Estamos comenzando a ver equipos en otros departamentos de Braze comenzando sus propias transformaciones ágiles, por lo que pronto más personas hablarán el mismo idioma y tendrán las herramientas que necesitan para definir y mejorar la colaboración.

comida para llevar

Dos elementos principales de nuestro esfuerzo aseguraron su éxito.

Primero, el hecho de que fuera dirigido por un comité representativo fue esencial para obtener aportes de toda la organización de ingeniería y desde una variedad de perspectivas diferentes. En toda la empresa, las personas se sintieron escuchadas y representadas en un tema que afectaría su trabajo diario. La subsiguiente creación de un documento completo que presenta las motivaciones y los planes para una transición Agile que podría compartirse con el equipo también fue muy útil. Creemos en mostrar cómo se toman las decisiones e introducir caminos claros para la retroalimentación, porque proporciona contexto y establece un artefacto sobre el cual dar retroalimentación.

En segundo lugar, la decisión de contratar a un tercero para ayudar a entrenar a nuestro equipo fue fundamental. Tener un socio objetivo y experimentado nos dio la capacidad de realizar rápidamente numerosas mejoras en nuestro proceso. Nuestro entrenador sabía lo que era bueno y pudo hacer recomendaciones sin prejuicios, varias veces pudimos preguntar: "¿Cómo harían normalmente los equipos X?" y obtener una solución inmediata y viable. Si, por otro lado, hubiéramos utilizado recursos internos, habríamos corrido el riesgo de que la retroalimentación que recibimos viniera de una parte sesgada y aumentara la disputa de recursos con las responsabilidades existentes.

¿Algo más?

Si desea obtener más información sobre cómo pensamos sobre nuestro producto y el trabajo que se requiere para fabricarlo, consulte Building Braze. ¿Interesado en unirte a nuestro equipo? Echa un vistazo a nuestras ofertas de trabajo actuales.