Artículos Boletín TenStep

Scrum es una metodología altamente viable para desarrollo de software y creación de nuevos productos, y los equipos que implementan Scrum rara vez experimentan fracasos. Sin embargo, sería un error asumir que Scrum es una panacea para todo tipo de problemas e impedimentos que emergen durante el desarrollo de los procesos.

De hecho, si el equipo que implementa Scrum fracasa en la entrega, no se le puede culpar a Scrum pues como proceso, en sí mismo, no está errado; más bien las deficiencias y defectos recaen en la implementación de esta metodología. Para ponerlo en otras palabras, existe una cantidad de trampas en los que el equipo Scrum puede caer y como resultado de ello las cosas pueden colapsar y todo el propósito de implementar Scrum puede sucumbir.

A continuación se menciona algunas de las trampas comunes de Scrum:

• Excesiva planificación inicial.- Los equipos Scrum no deben darse el gusto de planificar por adelantado, en su lugar, el equipo debe empezar a codificar y desarrollar inmediatamente. No tiene sentido desperdiciar tiempo en decidir el Backlog del Producto con mucha anticipación debido a que para planificar los subsecuentes Sprints es importante la retroalimentación recogida durante los Revisiones y Retrospectivas del Sprint.

• Enfocarse en las herramientas.- Las herramientas no son lo importante; la gente y los procesos son importantes. Así que, no existe necesidad de preocuparse acerca de las herramientas. “Encontrar la herramienta adecuada” es solo un obstáculo para iniciar y los equipos deben iniciar de inmediato el trabajo.

• Resolver Problemas en la Reunión Diaria de Pie (daily standup).- La Reunión Diaria de Pie no es para discutir problemas o para encontrar soluciones a esos problemas. Las Reuniones Diarias esencialmente deben limitarse a 15 minutos y a contestar las tres preguntas.

• Gerencia o Interesados gestionando al equipo.- Scrum requiere que los equipos sean auto-organizados y auto-gestionados; por lo tato, ni la gerencia ni los interesados deben tratar de manejar al equipo o de asignarles tareas. Por otro lado, el equipo tampoco debe esperar a que el Director de Proyecto o el Líder del Equipo deleguen tareas a los miembros del equipo.

• Scrum Máster como colaborador.- El Scrum Máster es un rol especializado; se supone que es un observador y un facilitador, no un desarrollador o comprobador. Así que no se le debería asignar ninguna otra responsabilidad. De igual manera, no debería dirigir al equipo acerca de qué hacer y qué no, debido a que ésto le distraería de monitorear si el equipo se adhiere a los principios de Scrum.

• Imponer plazos y recursos.- Los equipos Scrum saben muy bien qué completar en un Sprint en particular, así que ni el interesado ni la gerencia deben tratar de imponer fechas tope u ordenar recursos, puesto que ello no solo desmotiva al equipo, sino que reduce su productividad y la calidad del trabajo producido.

• Equipo disperso.- Scrum prefiere co ubicar juntos a los miembros del equipo puesto que la dispersión geográfica de los miembros impide la comunicación directa y efectiva, lo cual reduce la productividad y la calidad.

Scrum es el marco de trabajo más popular y prometedor de Ágil. Practicar Scrum de la manera adecuada es crucial para la construcción de productos y entregarlos más rápido al mercado. Los equipos Scrum deben asegurarse de seguir las mejores prácticas y evitar estas trampas comunes de Scrum.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, STC, SPOC, SMC, SDC

Los principios de Ágil declaran que “El método más eficiente y efectivo de transmitir información es mediante la conversación cara a cara”. Esta es la razón por la que Scrum recomienda “co-ubicar” a los equipos. Pero, con las realidades empresariales cambiantes y la globalización, co-ubicar equipos se está volviendo más y más difícil, y esta práctica se está reemplazando con equipos dispersos.

Puedes peguntarte: ¿qué aportan a la organización los equipos dispersos? La respuesta es: alcance global y costos distribuidos, equipos culturalmente inclusivos que entienden mejor el mercado, adquisiciones globales de otros negocios pequeños para ayudar a la organización principal, etc; las posibilidades son infinitas. Con este alcance global y el ingreso de recursos eficientes, trabajar con equipos dispersos se ha vuelto una parte importante del rol del Scrum Master.

Por supuesto, trabajar con equipos distribuidos tiene sus propios retos, siendo el primero la comunicación. Un equipo culturalmente diferente necesita un acercamiento distinto para comunicarse entre unos y otros. Si todos en el equipo comprenden un mismo lenguaje se elimina un gran escollo, de otra manera este tema se vuelve un impedimento. Existen diferentes zonas horarias, horarios de trabajo, cronogramas de entrega, etc. Todos ellos pueden ser manejados con la comunicación apropiada hacia el equipo, de tal manera que todos trabajen en pos de una misma meta.

La reunión de planificación del sprint requiere la comunicación apropiada dentro del equipo para llegar a consensos acerca de cómo proceder con los requisitos del cliente. Las reuniones Diarias de Scrum deben ocurrir en las respectivas locaciones, el Scrum Master debe consolidar la información de los diferentes equipos y encontrar cómo se puede mantener la eficiencia en niveles competitivos.

Si la comunicación es perfecta y los equipo están trabajando eficientemente, las revisiones finales del Sprint ayudan a consolidar y definir las cosas para las Retrospectivas del Sprint. La Retrospectiva del Sprint ayuda a analizar el Sprint. ¿Qué salió mal?, ¿Qué se pudo haber hecho mejor? Todo esto ayuda a hacer al equipo más eficiente y fluido. Una mejor coexistencia entre los equipos conduce a una entrega más rápida del producto final.

El entrenamiento juega un rol importante en configurar a los equipos individuales dentro de los equipos Scrum. La colaboración entre equipos es el criterio primordial que éstos deben alcanzar para empezar a lanzar entregables en el proyecto. Los equipos autoorganizados son mejores entregando productos que aquellos en los que sus miembros tratan de sobresalir unos sobre otros.

Todos estos puntos conducen a lograr un equipo mejor distribuido para un alcance global y una entrega final rápida, al tiempo que se adhiere al marco Scrum.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, STC, SPOC, SMC, SDC

Una vez que el equipo Scrum ha seleccionado las Historias de Usuarios para un determinado Sprint, ellos deberían considerar todas las dependencias, incluyendo aquellas relacionadas con la disponibilidad de las personas, así como cualquier dependencia técnica.  Documentar apropiadamente las dependencias ayuda a los Equipos Scrum a determinar el orden relativo en el cual deberían ejecutarse las tareas para crear los Entregables del Sprint.  Las Dependencias también subrayan la relación e interacción entre las Tareas, tanto aquellas en las que el Equipo Scrum está trabajando dentro de un determinado Sprint como las de otros Equipos Scrum en el proyecto. 

Existen numerosos tipos de dependencias: obligatorias y discrecionales, internas y externas, o alguna combinación de estas dependencias.  Por ejemplo: una dependencia puede ser ambas, obligatoria y externa.

• Dependencias Obligatorias: Las dependencias que son inherentes a la naturaleza del trabajo, como una limitación física, o que se deba a obligaciones contractuales o requerimientos legales.  Por ejemplo: el trabajo en el primer piso no puede ser terminado hasta que se complete los cimientos del edificio.  A las dependencias obligatorias se las conoce también como “lógica dura”.

• Dependencias Discrecionales:  Las dependencias que se ubican en el flujo de trabajo por elección.  Normalmente, el Equipo Scrum determina las dependencias discrecionales sobre la base de las experiencias pasadas o las mejores prácticas en un campo o dominio en particular.  Por ejemplo: el equipo puede decidir completar una tarea antes de trabajar en otra porque así es la mejor práctica, pero no se lo requiere así.  Por ejemplo: el equipo puede escoger construir los marcos de las puertas y ventanas antes de que se haya terminado la totalidad de la mampostería. 

• Dependencias Externas: Son aquellas que se relacionan con tareas, actividades o productos que están fuera del alcance del trabajo para que el Equipo Scrum las ejecute, pero se las requiere para completar una tarea o crear un entregable del proyecto.  Generalmente, las dependencias externas están fuera del control del Equipo.  Por ejemplo, si el Equipo Scrum no es responsable de obtener los materiales requeridos para construir las paredes, entonces esos materiales y tareas relacionadas con su compra se consideran dependencias externas.

• Dependencias Internas:  Son aquellas que entre dos tareas, productos o actividades que están bajo el control del Equipo Scrum.  Por ejemplo: se debe completar la instalación del drywall antes de iniciar la pintura de paredes.  Este es un ejemplo de una dependencia interna porque las dos tareas son parte del proyecto.  En este caso, es también obligatorio porque se basa sobre una limitación física.  No es posible pintar una pared antes de que se la construya.  

En proyectos grandes, la correcta definición de las dependencias ayuda a los Equipos Scrum a determinar cuál de sus decisiones puede impactar a otros equipos.  También puede influir sobre el orden relativo en el cual un solo Equipo Scrum ejecuta sus respectivas tareas para crear los Entregables del Sprint.

Autor: SCRUMstudy

Traducción: Adela Vega, TSPM, SMC, SDC

Adaptación: Enrique Ledesma M.Sc., PMP, STC, SPOC, SMC, SDC

La Justificación del negocio demuestra las razones por las cuales se emprende un proyecto. Responde a la pregunta: ¿Por qué se necesita este proyecto?. La Justificación del Negocio dirige toda la toma de decisiones relacionadas con el proyecto. Por lo tanto, es importante evaluar la viabilidad y factibilidad de un proyecto, no solamente antes de comprometerse con gastos considerables o inversiones en etapas iniciales del proyecto, si no que también es necesario verificar la justificación del negocio, contínuamente, a lo largo del ciclo de vida del mismo.

Se debe cancelar un proyecto si se encuentra que no es viable. La decisión debe elevarse a los interesados relevantes y a la gerencia sénior. La justificación del negocio para un proyecto debe evaluarse al inicio del proyecto, a intervalos predefinidos a lo largo del proyecto, y en cualquier momento en el que se presenten problemas o riesgos que atenten contra la factibilidad del proyecto.

Los siguientes pasos capturan la manera cómo se determinar la justificación del negocio:

1. Evaluar y Presentar un Caso de Negocio

Normalmente, el Propietario del Producto confirma y analiza la Justificación del Negocio. Se documenta y presenta en forma de un Caso de Negocio de proyecto antes de la fase de Inicio, e implica considerar los diferentes factores. Una vez documentado, el Propietario del Producto debería crear una Declaración de la Visión del Proyecto y obtener la aprobación por parte de quienes toman las decisiones clave en la organización. Generalmente, estas personas son ejecutivos y/o una especie de panel de directores de proyecto o programa.

2. Justificación Continua de Valor

Una vez que quienes toman las decisiones aprueban la Declaración de la Visión del Proyecto, se establece la línea base y la Justificación del Negocio. La Justificación del Negocio se valida a lo largo de la ejecución del proyecto, normalmente en intervalos predefinidos, o hitos, tales como: durante las Reuniones de Revisión del Portafolio, del Programa y del Backlog del Producto, y cuando se identifica problemas y riesgos que pongan en peligro la viabilidad del proyecto.

A lo largo del proyecto, el Propietario del Producto debería mantener actualizada la Justificación del Negocio, en la Declaración de la Visión del Proyecto, con información relevante del proyecto para permitir que quienes toman las decisiones importantes lo hagan de manera informada.

3. Confirmar la Consecución de los Beneficios

El Propietario del Producto confirma el logro de los beneficios para la organización a lo largo del proyecto, así como al término de las Historias de Usuarios del Backlog Priorizado del Producto. Los beneficios de los proyectos Scrum se alcanzan durante los procesos de: Demostración y Validación del Sprint, Retrospectiva del Sprint, Enviar Entregables y Retrospectiva del Proyecto.

La siguiente figura resume los pasos para determinar la justificación del negocio:

Autor: SCRUMstudy

Traducción: Adela Vega TSPM, SMC

Adaptación: Enrique Ledesma M.Sc., PMP, TSPM, STC, SPOC, SMC, SDC