La historia del proyecto Phoenix: DevOps y Agilidad para salvar un proyecto fracaso

“The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win” es una novela escrita de 2013 por Gene Kim, Kevin Behr y George Spafford, que, además de haber sido un “best seller” en el área de tecnología, debe ser en estos últimos años el libro más citado cuando se habla de DevOps. Así, el libro se ha merecido un post.
La novela cuenta la historia de un manager de TI, llamado Bill, que trabaja para una empresa llamada Parts Unlimited, que se dedica al área de la automoción, etc., y al que le dan noventa días para rescatar a un proyecto que va muy retrasado y por encima de presupuesto, cuyo nombre es el proyecto Phoenix. Vamos, la vida misma.

El CEO le pide a Bill que le informe directamente y que arregle el lío que hay montado en el proyecto Phoenix, y le da al pobre hombre noventa días más una amenaza: sino lo arreglas todo el departamento de Bill será externalizado.
La novela, quizá un poco exageradamente, o demasiada “estereotipadamente”, cuenta como la compañía sufre la falta de colaboración entre equipos, una cultura de culpabilidad, dependencia de héroes, imposición de herramientas, etc., con el personaje de Sarah, gerente de marketing, como figura destacada de los numerosos líos que se montan.
Gracias al Lean, a la Agilidad y DevOps, Bill y su equipo van cambiando poco a poco su forma de trabajar. Si bien, más allá del DevOps, la novela se centra en el cambio cultural, la ruptura de barreras entre departamentos y la visión de conjunto.

Algunas frases del libro

Me parece interesante dejarte (translated by jgarzas) algunas frases del libro que me han parecido interesantes y que tenía marcadas:
En referencia a Kanban y los WIP… Ser capaz de terminar el trabajo es más importante que ser capaz de poner más trabajo. Para ello, necesitas saber qué es importante para lograr de los objetivos del negocio, si se trata de proyectos, operaciones, estrategia, el cumplimiento de leyes y regulaciones, seguridad, o lo que sea. (pág. 162)
Un gran equipo no implica tener a las personas más inteligentes. Lo que hizo a los equipos grandes fue que todos confiaban el uno en otro. (pág. 184)
Mejorar en el trabajo diario es aún más importante que hacer el trabajo diario. (pág. 212)
Me recuerda mucho a una cita de Kent Beck… hasta que el código no esté en producción, en realidad no se está generando ningún valor, porque es meramente WIP atrapado en el sistema. (pág. 297).
Deuda Técnica… Significa que no estás entregando la negocio todo lo que eres capaz. Probablemente significa que no estás pagando deuda técnica, tus problemas crecen y el trabajo no planificado continua incrementándose con el tiempo. (pág. 162)
Estamos escuchando mucho últimamente algo que se llama DevOps. Tal vez todos los asistentes a esta fiesta son parte del DevOps, pero sospecho que es algo más que eso. Es product management, desarrollo, operaciones, e incluso seguridad, todos trabajando juntos y apoyandose mutuamente. (pág. 337)

Terminando

El libro es muy del estilo a aquel, que ya tratamos, de la “La Meta”, La meta, la teoría de las restricciones, agilidad y testing , de hecho, en “The Phoenix Project” hay referencias al mismo. Sí te leíste La Meta te gustará el proyecto Phoenix.

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024