¿El Propietario del Producto ha de participar en la reunión de scrum diario?

No, no es necesario que el Propietario del Producto asista al scrum diario, es una reunión propia del equipo de trabajo, en la reunión de planificación de sprint ya ha expuesto todo lo que compone la pila de sprint al detalle necesario, y no es hasta la reunión de revisión de sprint donde debe de formar parte de nuevo.

Reunión de scrum diario

Los casos en que el Propietario del Producto asiste suelen ser cuando el cliente es interno, de un departamento de la empresa, o un jefe de proyecto que representa un cliente y actúa como Propietario del Producto. En todo caso el Propietario del Producto asiste en calidad de interesado, sin voz ni voto.

Hay casos en que la asistencia del Propietario del Producto es muy positiva, puede resolver dudas del equipo y por experiencias de alguno de mis alumnos, sé de un caso en que fue muy motivante para el equipo que el Propietario del Producto los mantenga al día de las actividades comerciales relativas al proyecto y al cliente y de cómo se mueve el mercado del producto que están desarrollando.

En uno de los equipos que acompañé recientemente el Propietario del Producto venía a los scrums diarios sin interferir, y después de la reunión se quedaba un rato más mientras el equipo le enseñaba como iban avanzando con el producto, mostrando lo que estaban haciendo en un ordenador de desarrollo. No hace falta mencionar que ese proyecto fue un gran éxito, el éxito depende en gran medida de liderazgo desde el punto de vista del producto del Propietario del Producto.

Pero el Propietario del Producto que asiste debe de estar alineado con la mentalidad ágil, podría ser contraproducente que asistiera, ya que pudiera estar tentado a influir en el equipo, rompiendo la autogestión, la autoorganización, y por ende el compromiso.

¿Son más exitosos los proyectos ágiles o los tradicionales?

Uno de mis alumnos mencionó un post de Mike Cohn respecto a este tema que me pareció interesantísimo y que traduzco a continuación.

De acuerdo con el CHAOS Report de 2011 del Standish Group, los proyectos ágiles son tres veces más exitosos que los proyectos no ágiles. El informe llega tan lejos como para decir: "Los métodos ágiles son el remedio universal para el fracaso de proyectos de desarrollo de software. Las aplicaciones de software desarrolladas con métodos ágiles tienen una tasa de tres veces más éxito que cuando se aplica metodología tradicional en cascada, así como un porcentaje mucho menor en las desviaciones por exceso de tiempo y costes" (página 25).

The Standish Group define el éxito de un proyecto como entregado a tiempo, dentro del presupuesto, y con todos los requisitos y funcionalidades planificadas desarrolladas. No informa en cuántos proyectos se ha basado, pero dice que los resultados son de proyectos llevados a cabo entre 2002 y 2010. El siguiente gráfico muestra los resultados específicos reportados:

Agile Succeeds Three Times More Often Than Waterfall

¿Cómo asignar las tareas de la pila de sprint?

Decidiendo que tarea autoasignarse

Las tareas se autoasignan por el equipo o sus miembros en cada reunión de scrum diario, concretamente ocurre cuando cada miembro dice lo que va a hacer para el día siguiente. De esta forma cada miembro toma las tareas que le corresponden según su motivación, sus habilidades o su especialidad, y permite desarrollar el talento de cada persona y encontrar su lugar en el equipo.

La autoasignación también contempla que para tareas concretas, el equipo en su conjunto, decida asignar la tarea a un miembro o grupo de miembros en particular. Por ejemplo, en caso de urgencia asignarle la tarea a un experto para que la resuelva cuanto antes, o en caso de que no haya ninguna criticidad o haya tiempo, asignársela al menos experto, quizá guiado por un experto, con el fin de que el primero ruede y adquiera conocimiento (un buen nivel know-how hace, entre otras, equipos ganadores).

Cuando nos autoasignamos las tareas ante los demás miembros establecemos la conexión con los demás miembros, después del scrum diario todos sabemos lo que hacen los demás con lo que se fomentan entre otras la colaboración, la difusión y transferencia del conocimiento, el ayudar a un compañero que está en un cuello de botella y el no hacer las mismas cosas dos y más veces.

¿Cómo gestionar un bug que se ha detectado en la fase de pruebas usando un tablero Kanban con incremento continuo?

Los bugs forman parte del software

En Scrum simplemente se incorporaría el bug a la pila del producto, probablemente para tratarlo en el siguiente sprint. El caso de Kanban, gestionando incremento continuo y regulado por límites WIP, es distinto.

Dependiendo de la crititicidad del bug, este entraría en el backlog o pila de entrada del tablero, o, en caso de existir, en el carril "expedite".

La solución ideal es que bugs críticos entren en un carril de nado especial para elementos urgentes denominado "expedite", este tiene la característica de aumentar el límite WIP de todas las columnas de estado, usualmente en un +1. En cuanto un miembro del equipo queda libre se pone a trabajar en el bug, este tiene carril prioridad sobre las demás tareas. Adicionalmente se puede relacionar el bug con la tarea/historia/petición que lo ha puesto sobre la mesa.

Tablero Kanban con carril expedite y visualización de la petición que lo ha detectado

Si se tratara de un bug no crítico o no tuviéramos carril "expedite", este debería de entrar como tarea en la columna "in process" si el WIP de esta lo permitiese, sino en la columna de "backlog", y si el WIP de "backlog" tampoco lo permitiese consideraría aplazar la corrección del bug para más adelante, o sacar una tarea del backlog para colocar esta. Sería un error dejar el bug en "testing", no le corresponde ya, o ponerla en la columna "in process" o "backlog" cuando el WIP no lo permite, rompería el flujo de trabajo que trata de regular el tablero, estando este perfectamente regulado podrían aparecer de nuevo cuellos de botella y tiempos muertos.

¿Qué tiene que ver Scrum con la melé de rugby?

Jugadores en melé (foto cortesía de Peter Dean)

La melé es un término de origen francés, scrum en inglés, que representa una jugada de rugby en la que dos equipos compactos se empujan mutuamente para disputarse la posesión del balón. Los miembros de cada equipo están fuertemente compenetrados y se adaptan en conjunto, como una unidad, a la jugada.

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka realizaron un estudio sobre procesos de desarrollo muy exitosos utilizados en ciertos productos en Japón. Se trataba de productos que partían de requisitos muy generales y que afrontaban equipos reducidos y multidisciplinares. El estudio comparaba la forma de trabajo de estos equipos con la colaboración entre los jugadores de rugby y su formación de scrum. Takeuchi y Nonaka lo llamaron un enfoque de "rugby", "donde un equipo intenta recorrer toda la distancia como una unidad, pasando el balón hacia atrás y adelante".

Equipo de Scrum

En 1993, usando este estudio como base, Jeff Sutherland creó el proceso Scrum para el desarrollo de software adoptando la analogía con los equipos de rugby, y finalmente trabajó con Ken Schwaber para formalizar la primera versión de Scrum en la OOPSLA'95 (Object-Oriented Programming, Systems, Languages & Applications).

Destacar también que el grupo de cada equipo para la melé de rugby ha de estar formado por un mínimo de cinco y un máximo de ocho jugadores en tres líneas, y que en Scrum se recomienda que un equipo tenga entre 3 y 9 miembros, ya que más allá de 9 resulta difícil mantener la comunicación directa, primordial para mantener la Agilidad.

¿Cómo actuar en caso de equipos que varían a lo largo de los sprints por la necesidad de adquisición y liberación de especialistas?

Especialista técnico de AS/400

Este sería el caso en que se requieran especialistas en momentos puntuales para determinadas tareas, como por ejemplo expertos en un tema muy concreto como maquetadores, analistas o técnicos de sistemas como en el caso de un técnico de AS/400 de la imagen de la derecha ;-). Esta situación suscita otras preguntas como ¿invitamos a los especialistas a la reunión de planificación del sprint? ¿Forman estos parte del equipo?...

Scrum implica un cambio de chip en todos los miembros del equipo, cambio que se puede resumir en "vamos todos a la una". Un equipo multidisciplinar es clave, debe incorporar a los especialistas que hagan falta para los diferentes aspectos del proyecto y con mentalidad colaborativa y de interés por todo lo que les rodea. Recordemos que se autogestionan, por tanto un maquetador o un experto será el especialista en su campo, pero como estos sienten que forman parte de un equipo con un objetivo único y que el producto resultante es como "un hijo suyo", no les importa hacer tareas que no son de su especialidad. Son personas tipo "T" que simplemente suman.

Scrum es una forma excelente de difundir el know-how, tanto técnico como funcional. Hay una máxima que funciona, que es "never change a winnig team", y Scrum crea justamente equipos ganadores. Entendido esto, evidentemente el equipo puede variar, un maquetador podría no hacer falta a partir del tercer sprint... aunque este es un mal ejemplo, ya que para crear un incremento que funcione, la maqueta ya es parte previa de cada incremento de producto, y el producto estará presente en todo el proyecto. Un analista hará falta siempre, ya que el producto está en constante rediseño, y un especialista posiblemente también, ya que el producto se va construyendo al mismo tiempo que se modifican y aparecen nuevos requisitos.

Es importantísimo dejar de la lado la idea de grupos de trabajo con especialistas en una tecnología y dedicados a tareas de especialista. Lo importante es el equipo, formado por especialistas, si, pero por personas con actitud de sumar al equipo y de arremangarse para lo que haga falta. Yo he hecho entrevistas a muchos candidatos, y más que buscar a personas mastersdeluniverso, para mí lo importante es una buena base técnica y "buen rollo" para integrarse al equipo. Una necesidad técnica nueva se soluciona muy fácilmente: con un curso a la persona adecuada. Construir un equipo con personas comprometidas y con la actitud adecuada es lo difícil.

A todo esto puede aparecer una tarea "atípica" e infrecuente, no habitual en el proyecto y tampoco en los proyectos de la empresa. Un buen planteamiento sería considerarla como un servicio externo, como una adquisición con un coste y una fecha de entrega que debería ser adecuada para la integración en el sprint correspondiente. En este caso la realización de la tarea es cosa del especialista, un proveedor freelance subcontratado para ese trabajo concreto.

Off-the-record mencionar que esta forma de gestionar a un especialista es la ideal para incorporar temporalmente a un gurú. Estos suelen ser tipos algo freakys y con esta manera de gestionarlo, en que estos no forman parte de equipo, se evita que resten. Es recomendable también que un miembro del equipo adquiera el conocimiento, aunque sea de forma superficial, de la solución al problema que ha requerido la intervención del especialista.

¿1 punto de historia = 1 día ideal?

En charlas, foros y otros ambientes de discusión, hay debates sobre la unidad a utilizar para estimar el tamaño de las historias de usuario. XP, eXtreme Programming, por ejemplo, utiliza el punto de historia, y lo define como la cantidad de trabajo que se realiza en un día: 1 punto = 1 día ideal.

Realmente la unidad que se utilice es irrelevante. Lo que importa es que el equipo la conozca y la tenga interiorizada, signifique lo mismo para todos y que todo miembro sepa estimar con esa misma unidad.

Usar el tiempo, en el caso de XP los días, también es tema de debate, ya que en los proyectos medimos tamaño en unidad de tiempo, usualmente en horas/hombre o días/hombre. Algún comercial o jefe de proyecto podría, o bien de forma inconsciente o bien caer en la tentación de hacerlo conscientemente, condicionar al equipo en la estimación de las tareas. Cuantas veces nos han dicho al estimar "el proyecto han de ser tantas horas aproximadamente, por encima de eso el cliente no lo aceptará....". Por otro lado solemos caer en considerar la medida de trabajo "tiempo ideal" equivalente a la medida de tiempo real o duración, no es fácil entender que por ejemplo 4 horas de tiempo ideal se han realizado en 6 horas reales, aunque eso pueda ser una muy buena productividad.

Página de login, algo común a muchas aplicaciones

Lo ideal es que cada equipo defina el punto de historia como algo que le sea representativo, cualquier elemento con el que el equipo se sienta cómodo es válido; por ejemplo en pantallas maestro-detalle, en listados de 10 columnas y totales, páginas de login... Toda aplicación suele tener una página de login, por tanto es un buen referente común de los equipos para una unidad de tamaño. He trabajado con un cliente con una buena experiencia en que un punto de historia de partida fue media jornada y que consideró la jornada de 6 horas en tiempo ideal, por tanto razonablemente realizable en 8 horas reales.

Una vez hayamos empezado a rodar el punto de historia toma su significado, y probablemente no represente ese tiempo ideal con el que el equipo ha comenzado. Es momento de desacoplar, no mirar atrás, permitir que el sistema recalibre el punto de historia a lo que le llevado la mejora continua del marco de Scrum.