Las rutinas que se establecen con SCRUM (Daily Scrum, Sprint Review, Sprint Planning, Sprint Restrospective), los valores que se promulgan (compromiso, coraje, enfoque, apertura y respeto) y la práctica de esta metodología de agilísimo permiten una buena gestión en las áreas de tecnologías y logra permear las diferentes áreas de una compañía, estableciendo unas dinámicas diferentes.
Sin embargo, cuando se trabaja con Software como Servicio SaaS y sobre todo en B2B, se tiene “al otro lado de la mesa” un cliente con una gestión más tradicional, donde requieren un único entregable, funcional para iniciar las operaciones y no se contemplan etapas parciales, generalmente.
Esta situación supone un reto donde se deben gestionar proyectos de una forma de cara al cliente final con PMI y de otra forma internamente con SCRUM y adicionalmente hay que hacerlos funcionar sincrónicamente para que sean compatibles e imperceptibles para ambos equipos.
Diagrama de SCRUM
Como se ve en la gráfica se muestra el “cascarón” del PMI para gestión con el cliente y al interior la gestión del agilismo con SCRUM como protagonista, en la gestión del equipo interno.
El formalismo que ofrece PMI con rutinas como el Kickoff, definición de Alcance, Gestión de Riesgos, transfer meeting, entre otros, se convierten en los insumos perfectos para Scrum, ya que se tiene un Backlog de tareas bien definidas y con un detalle de lo requerido disponibles para programar dentro de los Sprints.
Finalmente, la sumatoria de los incrementos resultado de la ejecución de los Sprints, tendrán un resultado que se le entregará al cliente para validación y aprobación.
Factores a tener en cuenta en el SCRUM
Una vez que se vaya a iniciar el Sprint se tienen claros los objetivos de las tareas a cumplir. La gran dificultad es poder ajustar la EDT (estructura detallada de trabajo) y el cronograma de actividades del cliente en gestión PMI, con la programación de entregables de los Sprints, el cual debe conversar bien con lo que espera el cliente en fechas específicas.
Es un verdadero desafío ajustar ambas metodologías y transmitir en ambas puntas de la ecuación, cliente y equipo interno, que todo hace parte de un esfuerzo único que permite un mismo objetivo: poner en vivo una funcionalidad.
Esto implica tener a un PO-PM, Product Owner – Project Manager, es decir que el dueño del producto tiene que gestionar el Backlog con un cronograma tradicional de entrega única, donde el producto debe cumplir con los solicitado y tiene una única fecha de salida en vivo. Por otro lado, como Gerente del Proyecto debe gestionar todos los aspectos del proyecto, control de riesgos en el avance de los desarrollos, corrección de posibles indefiniciones, gestión de recursos necesarios, planes de acción para corrección de desviaciones del cronograma, entre otras.
Finalmente, mantener las dos gestiones de forma imperceptible, es un quehacer constante del día a día, es alimentarse de los retos del Daily para poder realizar los respectivos controles de cambio del proyecto, y por ejemplo, la materialización de un riesgo debe convertirse en una tarea del Backlog adicional que permitan ejercer un plan de acción efectivo.
