Planificando con el Equipo

Teníamos como objetivo generar el plan de entregas de un release que involucraba un buen conjunto de funcionalidades.

El PO comenzó listando todas las historias, describiéndolas, definiendo el objetivo, detalle y "demo" de cada una y priorizando, en este caso por la necesidad del cliente que espera el nuevo release del producto.

Convocamos a un storytime. Reunimos al PO, SM, y a todos los miembros del equipo.

El SM explicó la técnica de "Planning Poker" a todo el equipo.

Por suerte contamos con un mazo completo de cartas, especiales para este proceso, que adquirimos en las jornadas Agiles 2008.

El team se vio muy a gusto con la técnica, y lo que realmente sorprendió fue que no sólo se sentían 100% responsables de las estimaciones, sino que en una reunión timeboxed todos se divirtieron y se logró el objetivo de lograr consenso sobre todas las estimaciones de cada nueva historia.

El resultado fue la asignación de Story Points a cada ítem del Product Backlog. Al asignar Story Points a cada item, representamos el valor relativo de tamaño entre ellos.

Para esta reunión en particular, realizamos un trabajo previo de asignar Story Points a historias que ya teníamos terminadas, para usarlas como referencia.

Al finalizar la reunión quedó como tarea pendiente del PO y SM generar el Plan de releases para ser entregado a la gerencia.

Pensamos en la posibilidad de calcular la velocidad del equipo según los resultados pasados, pero el equipo por diferentes circunstancias se vio muy afectado y el cálculo no nos parecía muy realista.

Volvimos a juntar al equipo.

Explicamos que teníamos que entregar el plan, que queríamos presentarlo a nivel de Sprints, y que por lo tanto queríamos bajar un poco el detalle.

Tomamos como base que el equipo iba a dedicar el 80% del tiempo al proyecto y Sprints de 2 semanas.

El equipo reevaluó cada item, consultaron más detalle, pensaron las tareas necesarias para cada uno, y sprint tras sprint, fue completado con el número de historias que el equipo pensaba que podría cumplir durante las dos semanas.

Lo mejor de todo, es que los Sprints quedaron todos con una carga de 30 Story Points aproximadamente, lo cual ya veremos si es la velocidad real del equipo.

Conclusión

Experiencia excelente, el equipo 100% comprometido con el plan y con las estimaciones, y los gerentes conformes con los tiempos estimados.

En unas semanas les contaremos cómo nos fue con el plan.

Agiles 2008 - CSM

A fines de octubre asistimos al curso CSM (Certified Scrum Master), dictado por Tobías Mayer en el marco de Agiles 2008, en el Hotel Bauen de Buenos Aires.

El curso fue más que interesante, se nota que Tobias tiene un gran conocimiento y experiencia sobre el desarrollo de software en general, y sobre metodologías ágiles y Scrum en particular.

Cosas que me gustaron del primer día:
- Los juegos que permiten verificar principios de Scrum mediante la experiencia.
- El intercambio de experiencias con Tobías y el resto de los asistentes.
- Los aportes de Adrián Eidelman, facilitador del curso. Yo esperaba que el facilitador iba a ser alguien que sólo se iba a ocupar de conseguir agua y traducir al español cuando no se entendiera algo, pero Adrián tiene experiencia de primera mano y sus comentarios sumaron positivamente.
- Los papers que nos dio Tobias de tarea para la 2da. parte, de los cuales paso los links a continuación:
http://www.scrumalliance.org/resources/363 (video)
http://agilethinking.net/blog/2008/09/26/scrum-its-place-in-the-world/
http://danube.com/blog/michaeljames/a_scrummasters_checklist

El foco de la primera parte fue presentarnos lo que sería Scrum idealmente, su filosofía y principios fundamentales.

El segundo día estuvo orientado a plantear y discutir Scrum desde un punto de vista de la práctica, donde no siempre se dan todas las condiciones ideales para implementar Scrum.
Durante el segundo día Tobías simuló la construcción de un producto (conocimiento sobre Scrum) bajo Scrum, donde el product backlog fueron las preguntas planteadas por los asistentes.

Fue muy interesante observar cómo mediante Scrum se priorizó el product backlog según el valor de negocio (el interés en las preguntas), y se construyó el producto en 4 sprints donde el equipo fue mejorando sus estimaciones (habilidad para asignar story points a las preguntas) y aumentando la velocidad sin bajar la calidad de las respuestas.

En resumen, estoy muy conforme con el curso, y definitivamente vale la pena si uno realmente está interesado en Scrum.

Protección de entregables

A veces cuesta mucho alinear Scrum con la realidad de los clientes. Hay casos en los cuales el cliente espera un plan de releases que no evolucione, con deadlines inamovibles. No es que el cliente no cree en los beneficios de la utilización de Scrum, sino porque pueden existir restricciones del tipo "si no tengo A para la fecha B, ya no me es de valor" o "El lanzamiento está alineado a otro mundo de tareas que ya empezaron y van a terminar en fecha, por lo que la fecha de despliegue no la podemos mover aunque queramos"

Para eso trabajamos con dos técnicas de buffer, que tienen como único objetivo PROTEGER LA FECHA DE ENTREGA DE LOS RELEASES (para ver el tema en detalle no dejar de leer AgileEstimating and Planning de Mike Cohn :

1. feature buffers: cada uno de los releases se planifica con una lista de funcionalidades que el producto no puede dejar de tener y una lista de funcionalidades que el producto puede dejar de tener. De esta forma protegemos el entregable comprometiendo con el cliente para una fecha determinada todas las funcionalidades que sí o sí hay que entregar y con una lista de funcionalidades que solo se entregarán si resta tiempo luego de terminar con las historias mandatorias.


2. schedule buffers: aplicamos el concepto de estimar al 50%, esto quiere decir, realizar estimaciones en la que tenemos un 50% de probabilidad de cumplirlas. Calculamos el tamaño completo del entregable y se suma un buffer del 50% del tiempo total estimado. Es muy importante proteger los entregables y no los items ni las tareas, porque Scrum no es a prueba del síndrome del estudiante y parkinson. De esta manera nos reservamos tiempo y logramos asegurar los entregables.

Un buen ejemplo de libro sobre como justificar los buffers para que no sean confundidos con sobreestimaciones: "Cuando uno va manejando un auto, en general deja una distancia prudencial con respecto al vehículo que va delante, de tal manera de poder frenar a tiempo en caso que el primer auto lo haga. Esto no significa que no podemos ir a 120km por hora durante 5 horas a 30 centímetros y no pase nada, pero esa distancia es necesaria para asegurar que se puede llegar a destino sin chocar con el vehiculo de adelante.

De la misma forma, los buffer quizás no se usen, en ese caso agregamos ítems, pero son necesarios para asegurar el cumplimiento de un release "

Notarán una gran similitud entre la utilización de buffers en Scrum y en cadena crítica, y más adelante comentaremos cómo se aplica el principio de feeding buffers para trabajar con multiples scrums en el mismo proyecto.

S, M o L?

En distinas etapas de nuestros proyectos nos encontramos con la necesidad de estimar. Estimar una fecha de entrega, estimar el esfuerzo que demandará completar ciertas tareas...

En un proyecto ágil, tenemos que tener claro que vamos a requerir estimaciones de diferentes niveles: Release, iteración, tareas del día (Podemos identificar otros niveles, pero por ahora nos alcanza con estos, ya vamos a agregar otros cuando los necesitemos, Inspect and Adapt!). Hoy nos vamos a centrar en las estimaciones a nivel de Release e iteración.

Las primeras estimaciones que realizamos de nuestro Product Backlog, las hicimos según Ideal Days. En ese momento, pensamos que iba a ser natural para el equipo pensar en "cuánto lleva realizar estas tareas si me encierro en una pieza con suficiente comida y sin interrupciones hasta terminarla". Permitía estimar de forma parecida a cómo se hacía hasta ahora, dividiendo una funcionalidad en tareas, asignando las tareas a cada miembro del equipo, y luego estimando según cuánto llevaría cada tarea según quién la fuera a hacer. Pero encontramos varios problemas:

• Impide sacar el foco de las tareas y ponerlo en la funcionalidad (valor para el negocio)
• La estimación se hace pensando en cuál es la persona que se cree que va a hacer la tarea ("mis" días ideales no son iguales a "tus" días ideales). Esto va en contra de lograr la responsabilidad como equipo, que cualquier miembro del equipo va a realizar la tarea en el momento en que sea necesario hacerla (aunque lo más probable es que los Stored Procedures los haga nuestro gurú de base de datos).
• Observamos que desde fuera del equipo no dejaron nunca de preguntar "Cómo puede ser que un programador sólo complete 12 días ideales en un Sprint de 20 días? El resto del tiempo que estuvo haciendo?". No importa que en la demo se queden maravillados con la cantidad y calidad de funcionalidad que se completa en un Sprint, en todos los Sprints (al menos esa es la idea :)
• A través del tiempo, la unidad Ideal Days no debería ser comparable, porque el equipo es cada vez más productivo, conoce mejor la tecnología, se conoce a sí mismo, conoce el dominio, entonces las estimaciones en Ideal Days son cada vez menores.

Frente a esta situación, y luego de investigar sobre el tema (recomendado: Agile Estimating and Planning de Mike Cohn), decidimos empezar a estimar mediante Story Points.

Qué es eso de los Story Points?

• Es una medida del tamaño relativo de un item del backlog

Nada más y nada menos. Lo más importante es que mide en forma relativa el tamaño de un item del backlog. La unidad de medida no es muy importante: Podrían ser talles de remera (S, M, L, XL...), podrían ser perros (Chihuaha, Pequinés, Collie, Gran Danés), o simplemente números.

Nosotros elegimos el siguiente conjunto de números: 1, 2, 3, 5, 8, 13, 20, 40. Se parece a una serie de fibonacci, "redondeada" a medida que va creciendo para quitar importancia a la precisión (no nos importa si a un item le vamos a asignar 20, 21 o 24, nos importa saber que aproximadamente es un50% más grande que uno de 13).

Tal vez no sean los "números ideales", se suele sugerir que exista sólo un orden de magnitud entre el item más chico y el más grande (eso dejaría afuera al 13, al 20 y al 40). Nosotros vamos a ser ágiles en esto, primero vamos a probar y después ver el resultado. Inspect And Adapt.
Ya hemos realizado la primer estimación con Story Points, y observamos lo siguiente:

• El equipo tuvo que jugar inicialmente a asignar Story Points a Stories que ya fueron completadas. Con eso planteamos una base para poder comparar futuros Stories y asignarles Story Points.
• El equipo puede estimar los Stories en mucho menos tiempo que antes. Se llega a acuerdos rápidamente.
• Cuando se está estimando, no se piensa en quién va a realizar cada tarea. Lo importante es poder estimar el tamaño relativo. Ya vamos a poder saber cuánto tiempo nos va a llevar cuando sepamos nuestra velocidad. Esto es un gran avance!
• Todavía no nos enfrentamos a la difícil tarea de explicar a la "gente de afuera" esta nueva forma de estimar. Pero confiamos en que vamos a lograr que compren el concepto.

Esto es todo por hoy, más adelante vamos a contar cómo son nuestras sesiones de estimación, las distintas variantes que fuimos adoptando y los resultados.

En pocas palabras, cómo trabajamos...

Los roles en Scrum son: El scrum master(SM), el product owner(PO) y los miembros del equipo.

El Scrum Master tiene como responsablidad principal lograr que se cumpla el proceso ágil.

Propaga los principios y la metodología en todo el equipo, arma las reuniones del equipo, planifica las demostraciones, cumple el rol de facilitador removiendo los impedimentos a los que se enfrenta el equipo, y dentro de lo posible es un fuerte firewall entre el equipo y las influencias exteriores.

Es muy importante su papel en la comunicación, la facilitación, y el coaching del equipo.

El Product Owner tiene entre sus responsabilidades mantener el backlog del producto, asegurar que se maximice el ROI, y especificar las user stories.

Está 100% disponible para el equipo, se sienta próximamente y canaliza todos sus pedidos a través del SM y documentado en el BL del producto.

El equipo está creciendo, comenzó con dos desarrolladores, posteriormente incluimos gente de QA y estamos sumando más personas. Su responsabilidad es hacer todo lo necesario para cumplir con los objetivos de los sprints.

Internamente el equipo, a pesar de ser principalmente de desarrolladores, intenta ser lo más cross-funcional posible.

Todos los miembros buscan siempre cumplir con el concepto de "done", no realizamos una cascada encubierta dentro de la metodología Scrum, sino que vamos sumando prácticas de calidad, como TDD, integración continua, etc., con objetivo de lorgar un release listo para ser publicado en producción al final de cada sprint.

Todo el equipo trabaja en iteraciones de 3 semanas. Aún no estamos convencidos si esa es la duración ideal, por ahora creímos conveniente empezar a probar de esta forma (Inspect and Adapt).

Cada sprint comienza con la reunión de "sprint planning", diariamente realizamos el "scrum meeting", y finalizamos el sprint con la demo y la retrospectiva.

Posteriormente les contaremos en detalle como enfrentamos cada práctica de la metodología y como buscamos realizar una mejora continua.

Nuestros Inicios

Hace ya más de tres años, intercalado con mucho material de gestión de proyectos y calidad en desarrollo de sistemas, venimos escuchando, con un tono cada vez más fuerte la palabra ágil.

Ya la primera vez despertó nuestra curiosidad, por lo que empezamos a leer material de Scrum y XP.

Quizá por nuestra no tan larga experiencia como PMs o debido al poco peso que teníamos en ese momento en la empresa donde estábamos trabajando (en referencia a poder cambiar procesos actuales, cultura y formas de trabajo), "nuestra experiencia ágil" estaba completamente limitada a investigar.

Luego de estudiar formalmente la metodología en el ambiente universitario, de haber leído varios libros, suscribirnos a foros y comenzar a aprender de la experiencia del resto, conseguimos, donde trabajamos actualmente, armar un equipo de desarrollo con un equipo Scrum.

Nos ayudo muchísimo el apoyo de parte de la gerencia, y principalmente, aunque no suene bien, los malos resultados obtenidos con metodologías orientadas al plan.

En este momento seguimos intentando ser como equipo cada día más ágiles, adquirir nuevas prácticas y probar herramientas.


El conflicto principal que enfrentamos es adaptar el proceso actual de preventa, venta, planificación a largo plazo, seguimiento y visibilidad de los proyectos, para ser realmente ágiles, obtener el mejor retorno de inversión y al mismo tiempo brindar a todos los stakeholders de la empresa y/o proyecto todo lo que esperan.

Por qué escribimos

Ya estando en el día a día con scrum, tomando las metodologías ágiles como eje de nuestra capacitación como gerentes/líderes de proyectos, tuvimos una muy buena experiencia leyendo el libro "Scrum & XP from the trenches", nos inspiró.

Como dice en su prólogo, a diferencia de casi todos los otros libros, no describe el framework, formalidades, técnicas, manifiesto, etc, sino que cuenta cómo el autor, es ágil en el día a día junto a sus equipos de desarrollo.

Creemos que nos suma a nosotros, llevar esta pequeña bitácora, que nos ayuda a resumir y sacar conclusiones de "nuestra agilidad" y quizá les sirva a ustedes ir conociendo cómo enfrentamos los proyectos, los problemas y cómo vamos creciendo.