Por Frank Rios
Los gerentes de proyectos de TI tradicionales han luchado durante décadas para utilizar la metodología del PMI cuando se trata de desarrollo de software. Utilizar la metodología tradicional de gestión de proyectos para el desarrollo de software es similar a tratar de encajar una pieza cuadrada en un agujero redondo; se puede forzar, pero simplemente no encaja tan bien como debería. En los últimos años, la metodología ágil ha ganado impulso. Esto se debe en gran parte a la popularidad de Scrum, aunque Agile ha existido durante casi dos décadas. Scrum es uno de varios marcos que se encuentran bajo el paraguas de Agile. Algunos de los otros incluyen Extreme Programming (XP), Rational Unified Process (RUP) y Design for Six Sigma.
Teoría del control
Generalmente hay dos tipos diferentes de teoría del control. El primero es el proceso definido (o teórico). Esto es lo que sigue la gestión tradicional de proyectos; se trata de comando y control. Hay mucha planificación. Planificas lo que esperas que suceda, luego aplicas el plan; a veces sin importar las condiciones. Finalmente, este proceso utiliza el control de cambios. A menudo encontrarás una junta de control de cambios que supervisa cualquier solicitud de cambio. Scrum, por otro lado, emplea lo que se conoce como el proceso empírico. En este proceso, aprendes a medida que avanzas. En lugar de planificar todo de antemano y planificar cómo manejar el cambio, el proceso empírico establece “planificar para el cambio”. De hecho, el proceso empírico abraza el cambio a través de la inspección y adaptación; dos de los tres pilares que sustentan cada implementación del control del proceso empírico.
Los tres pilares
La gestión tradicional de proyectos durante años ha seguido el “triángulo de hierro”; tiempo, costo y calidad. Estos siguen siendo los tres pilares que todo gerente de proyectos debe equilibrar. En un mundo ideal, los proyectos se entregarían a tiempo, dentro del presupuesto y con la máxima calidad. En realidad, esto rara vez sucede. Para proyectos de desarrollo de software, obtener los tres nunca sucede. Un ScrumMaster también sigue tres pilares. Sus pilares son transparencia, inspección y adaptación. La transparencia implica una comunicación abierta con todos los miembros del equipo de proyecto Scrum, y el ScrumMaster muestra con orgullo los gráficos de reducción de trabajo de su equipo donde todos pueden verlos. También revisan qué tan bien les fue durante su sprint en lo que se conoce como una Revisión de Sprint. Finalmente, la adaptación implica realizar cambios y mejoras en las tareas que se pueden mejorar.
Iniciando la transición
Para muchas empresas que intentan hacer la transición a Agile, lo primero que deben entender es que un buen gerente de proyectos no necesariamente será un buen ScrumMaster. No son directamente intercambiables. Contrariamente a lo que se piensa, un buen ScrumMaster no tiene que tener experiencia en gestión de proyectos. De hecho, los mejores ScrumMaster son generalmente muy técnicos. Los antiguos expertos en la materia y líderes técnicos son excelentes ScrumMaster. Esto se debe a que pueden empatizar mejor con los desarrolladores, entienden la gran diferencia entre el nivel de esfuerzo y la duración, y pueden ayudar mejor a priorizar las características junto con el Propietario del Producto.
Conoce tu rol
Hay tres roles principales en Scrum: el ScrumMaster, el Propietario del Producto y el Equipo. A menudo, escucharás que se refieren a las personas como “gallinas” o “cerdos”. Las personas que forman parte de cualquiera de los tres roles principales se llaman “cerdos”, mientras que todos los demás se llaman “gallinas”. Un “cerdo” es alguien comprometido con el proyecto, mientras que una “gallina” es alguien simplemente involucrado. El origen de estos términos proviene de la siguiente historia: “Un pollo y un cerdo están juntos cuando el pollo dice: ‘¡Vamos a abrir un restaurante!’ El cerdo lo piensa y dice: ‘¿Cómo llamaríamos a este restaurante?’ El pollo dice: ‘¡Jamón y huevos!’ El cerdo dice: ‘No gracias, yo estaría comprometido, pero tú solo estarías involucrado'”.
ScrumMaster
El trabajo principal del ScrumMaster es adherirse a los valores, prácticas y reglas de Scrum. Son defensores de Scrum y ayudan a que sea aceptado y adoptado en toda la organización. También actúan como el “escudo” figurativo. El ScrumMaster protege al Equipo del ruido político externo y se asegura de que nadie se acerque directamente a ningún miembro del equipo sin seguir la cadena de mando adecuada. Esto permite que el equipo se mantenga enfocado en el trabajo en cuestión, y si algún problema es una prioridad, el ScrumMaster y el Propietario del Producto lo discutirán y lo priorizarán dentro del Backlog del Producto según corresponda.
Propietario del Producto
La responsabilidad principal del Propietario del Producto es gestionar el Backlog del Producto. El Propietario del Producto es una sola persona, no un comité. La colección de partes interesadas puede influir en el Propietario del Producto, pero el Propietario del Producto tiene la última palabra. El Propietario del Producto establece la prioridad de cada característica/solicitud. Para los nuevos Propietarios del Producto, el ScrumMaster trabajará en estrecha colaboración para enseñarles cómo hacer su trabajo.
Equipo
El Equipo es responsable de convertir los elementos del Backlog del Producto en funcionalidad potencialmente entregable en cada Sprint. El Equipo Scrum es multifuncional. En otras palabras, está compuesto por personas con una o más especialidades, incluyendo, pero no limitado a control de calidad, desarrollo, diseño de bases de datos, análisis de negocios. El equipo se autoorganiza y se autogestiona. Como tal, todos tienen el mismo título: Miembro del Equipo Scrum. El tamaño del equipo debe ser de alrededor de siete (7) personas, más o menos 2. Este tamaño no incluye al ScrumMaster y al Propietario del Producto (a menos que sean cerdos que trabajen en tareas incluidas en el Backlog del Sprint).
Desafíos de la transición
La metodología ágil no se ajusta a la metodología del PMI. Este es absolutamente el mayor obstáculo a superar y donde ocurre el conflicto interno de los gerentes de proyectos; aún más para los PMP experimentados. Para completar con éxito la transición, el departamento debe elegir uno u otro cuando se trata de desarrollo de software. No cumplir con los principios ágiles conducirá a una transición fallida.
Rol dual o dos recursos diferentes
Cualquier transición a Agile es en sí misma un proyecto. Por lo tanto, se debe elegir a un Gerente de Proyecto para liderar esta transición. Además, el ciclo de vida del ScrumMaster se centra en el desarrollo de software, que es solo una parte del ciclo de vida del proyecto completo. Como cualquier Gerente de Proyecto sabe, ser un Gerente de Proyecto es un trabajo a tiempo completo. Ser un ScrumMaster también es un trabajo a tiempo completo. La gran pregunta es si un solo recurso puede desempeñar con éxito ambos roles. La respuesta, como tantos requisitos que se les dan a los desarrolladores, es “depende”. Algunas empresas intentarán cubrir ambos puestos con un solo recurso debido a restricciones presupuestarias u otras razones. Esta es una razón perfectamente aceptable, pero no necesariamente la mejor. Un Gerente de Proyecto que sea un ScrumMaster Certificado puede desempeñar este rol dual, pero esto no se recomienda.
Desprogramando a los Gerentes de Proyectos
Los gerentes de proyectos planificados tradicionales deben ser desprogramados antes de que puedan convertirse en un gerente de proyectos ágil exitoso. El presidente Eisenhower lo dijo mejor cuando dijo: “La planificación es esencial, los planes son inútiles”. Esa frase resume la mayor diferencia entre Agile y PMI. El éxito ya no se mide por lo bien que se equilibran las triple restricciones; solo se mide por el Cliente. El alcance del proyecto ya no es el impulsor; el alcance está determinado por el tiempo y el presupuesto. El éxito ya no se mide por la finalización de tareas y revisiones de fase, sino por la entrega de características y funciones. Finalmente, aprende a abrazar el cambio; ámalo, vívelo.
Trabajando juntos
El Gerente de Proyecto y el ScrumMaster deben ser tratados como iguales si el proyecto quiere tener éxito. El Gerente de Proyecto está a cargo de todo el proyecto, mientras que el ScrumMaster está a cargo de la parte de desarrollo de software del proyecto. Es muy importante que la gerencia respete la diferencia. Durante el desarrollo de software real, el gerente de proyectos debe permitir que el ScrumMaster ejecute Scrum utilizando la metodología ágil, no la metodología del PMI. Como Gerente de Proyecto, la parte complicada es “dejar ir” y confiar en el ScrumMaster. Esta parte del grupo de procesos EJECUTAR debe considerarse una “caja negra”. El Gerente de Proyecto ahora se considera una “gallina”; puede escuchar, pero no tiene peso.
Convertirse verdaderamente ágil
Muchas empresas sienten que son ágiles simplemente porque están haciendo desarrollo de software iterativo. Sin embargo, hacer Waterfall de manera iterativa definitivamente no es ágil. Ágil es mucho más que desarrollo iterativo y lanzamientos rápidos. La forma tradicional de pensar del PMI no puede ser la guía al implementar Agile; se convertirá en un impedimento. Es una forma completamente nueva de pensar; una filosofía completamente nueva. Para convertirse verdaderamente ágil, todo el departamento de TI debe experimentar un cambio de paradigma.
Frank Rios es fundador y consultor de Protean IT Management, LLC. (http://proteanitmanagement.com/). Es un consultor técnico, líder y gerente de proyectos con experiencia en los sectores público y privado, con una sólida formación en gestión de proyectos de TI, arquitectura de aplicaciones y desarrollo de aplicaciones. Sus especialidades son la gestión técnica de negocios y proyectos ágiles, la supervisión de la gestión de programas y la mejora de procesos. A través de su combinación de experiencia empresarial y técnica, Frank ha podido agregar valor a equipos y empresas, aumentando la comunicación entre los departamentos de negocios y técnicos, reduciendo los requisitos ambiguos y aumentando el tiempo de comercialización. Su educación formal incluye dos maestrías; una Maestría en Ciencias de la Computación (MCS) y una Maestría en Administración de Empresas (MBA) con una concentración en Gestión de Proyectos. Sus certificaciones profesionales incluyen Project Management Professional (PMP), Six Sigma Green Belt (SSGB) y Certified ScrumMaster (CSM).
