Se nos va relajando Scrum…. por decirlo suavemente.

 

Hace tiempo empezamos a intentar hacer Scrum un grupo de cuatro para atender seis proyectos, con sprints de una semana. Los sprints tan cortos eran necesarios para poder reorganizar el product backlog mezclado con historias de varios proyectos y poder cambiar de unos proyectos a otros en función de sus prioridades. Pero esos sprints tan cortos nos hacían perder mucho tiempo, ya que organizar todos los viernes una o dos demos, era demasiado para enseñar un pequeño incremento de funcionalidad.

Así que intentamos aproximarnos a algo más como Kanban. Teníamos nuestras historias, nuestras reuniones diarias, nuestras tareas, planificación por poker, pero no haciamos las demos.

Y ya no queda ni eso. Uno de los proyectos ha entrado en sus fases finales, así que estamos los cuatro liados con ese proyecto. Nuestro trabajo día a día consiste en probar, encontrar incidencias y corregirlas. Nuestro product backlog es "probar tal tema y corregir". Planificar eso es complejo, una incidencia nunca se sabe cuánto se puede tardar en corregir y menos una semana antes, cuando todavía no la has encontrado.

Así que nada, consideraremos este periodo como un descanso de Scrum, seguiremos con nuestras reuniones diarias (han gustado a todos los miembros del equipo) y a la vuelta de vacaciones retomaremos el Scrum/Kanban.

Esta entrada ha sido publicada en scrum y etiquetada como , , . Guarda el enlace permanente.

10 respuestas a Se nos va relajando Scrum…. por decirlo suavemente.

  1. Jose M Beas dijo:

    ¿Qué dice el equipo en las retrospectivas?

    Es importante que hagáis el esfuerzo de conseguir un ritmo de trabajo sostenible. En realidad, Scrum, Kanban, XP, Lean… todas las metodologías ágiles se basan en buscar este ritmo sostenible.

    Esperemos que a la vuelta del verano hayáis podido reflexionar sobre qué es lo que está fallando y retomar Scrum con la autodisciplina y la paciencia necesarias. Recuerda que Scrum se explica en 5 minutos pero luego toma tiempo hacerlo bien.

    Un abrazo,
    JMB

  2. Chuidiang dijo:

    Hola Jose M Beas

    ¿Cómo harías tú Scrum en este caso?. Fase final del proyecto que puede durar un mes (es la fecha prevista para que venga el cliente a pasar pruebas) en el que el trabajo a hacer «sólo» es probar y corregir las incidencias que vayan saliendo.

    Veo muy difícil hacer una planificación de ningún tipo. No tienen sentidos demos. Lo único que veo con sentido (y es lo que hacemos), es la reunión diaria para comentarnos qué incidencias vamos viendo y corrigiendo, o una mini-retrospectiva, quizas los viernes, para analizar el trabajo de la semana y ver en qué se puede hacer más eficiente.

    Se bueno.

  3. atreyu dijo:

    Mmm desde mi ignorancia de la agilidad: lo ideal no es que en cada uno de los sprints se solucionen las incidencias hasta que en los ultimos no haya casi?? O sea que los prototipos o demos se acerquen mas a la realidad con incidencias solucionadas incluidas…
    Supongo que en la practica no sera asi claro

  4. Chuidiang dijo:

    Hola:

    Atreyu, tienes razón, no debería haber incidencias. Sin embargo, tenemos dos problemas:

    – El primero es que el proyecto lleva ya casi dos años en marcha y sólo llevamos aplicando scrum un par de meses escasos. Muchas de las incidencias las tenemos de antes.
    – El segundo es que en nuestros sistemas el software es lo de menos. Llevan montones de equipos hardware con los que integrar (radioenlaces, gps, etc, etc y casualmente, los equipos hardware más complejos, son de fabricación propia). Así que estamos en la fase de integración con esos equipos, muchos de los cuales están también siendo depurados (su firmware). Eso también hace que durante estos casi dos años de software, nunca hemos podido probar en las condiciones reales (con los equipos de verdad).

    Se bueno.

  5. ilcavero dijo:

    Hola Chuidian, dos cosas:
    1) por lo que cuentas lo que no entiendo es por que elegiste SCRUM desde un principio, si no puedes hacer releases funcionales al final de cada sprint y elegir las siguientes funcionalidades a desarrollar basado en el negocio y feedback del cliente estas tirando por la ventana 90% de lo bueno de SCRUM.
    2) el link de kanban que mandas esta muy bien, pero eso poco tiene nada que ver con SCRUM. Lo que te dice JMB sobre que dominar SCRUM toma una vida es cierto, pero en mi opinión tu lo que tienes es que olvidarte de eso para estos proyectos. No es que tenga nada malo la metodología o tu proyecto sino que no son compatibles. Las metodologías clásicas tipo RUP no sonaran tan guay pero siguen tan vigentes como siempre.

    PD: sigue contando como te va, esto va muy interesante y lo que estas tratando de hacer es difícil.

  6. atreyu dijo:

    @ilcavero caminante no hay camino, se hace camino al andar 😉

  7. Jose M Beas dijo:

    Hay algo que dice @ilcavero que no está desencaminado: quizás la elección de Scrum no fuera la idónea (no lo sé). Pero, la verdad, considerar que RUP es una opción mejor que Scrum para el problema de @chuidiang me parece «recoger velas» para ir a terreno conocido. Cuanto más prescriptivo es el proceso, menos flexible resulta y es más complicado de implantar con éxito. (Para mi éxito quiere decir que las funcionalidades llegan al cliente en tiempo y coste y cubriendo las expectativas)

    Lo importante de Scrum (o cualquier otro método ágil) es que, siguiendo los principios ágiles, tienes un momento al final de cada entrega (la retrospectiva) en el que reflexionas con todo el equipo sobre cómo mejorar, eliminar obstáculos que durante el día a día no ves, etc.

    Quizás la opción de @chuidiang de adoptar un método menos prescriptivo aún que Scrum (Kanban) sea una buena opción para ir cambiando la cultura del equipo y, más adelante, adoptar Scrum «by-the-book». Es razonable, mucha gente está intentando este camino.

    Como dice @atreyu, se hace camino al andar…

  8. Pingback: Diario de Programación » Blog Archive » ¿Por qué elegí Scrum?

  9. Pingback: Diario de Programación » Blog Archive » Primero Scrum, luego Kanban

  10. Pingback: Diario de Programación » Blog Archive » Al final, ni Scrum ni Kanban

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.