Progreso de la reimplementación de Scrum

A unos dos o tres Sprint desde que comenzamos a aplicar Scrum, hemos evolucionado bastante. Se nota el progreso de cada Sprint con respecto al anterior. Comencé este post como un resúmen general de todas las cosas que hemos ido cambiando, pero quedó bastante largo, por lo que decidí ir publicando de a uno los aspectos de Scrum que han evolucionado, y de qué manera. Así resulta mas cómodo de leer, y cada aspecto queda atomizado en su post.

Estuve leyendo Scrum and XP from the Trenches (Scrum y XP desde las trincheras) de Henrik Kniberg. Saqué muchas ideas de ahí, quienes lo hayan leído las podrán detectar. El libro es bien práctico y explica como Kniberg aplicó Scrum en su equipo. Es sumamente recomendable, una vez que hayamos adquirido la teoría de Scrum, darle una leída para ver cómo solucionó distintas partes de aplicar Scrum. La otra opción es buscar más libros, comunidades y blogs de Scrum (como éste 🙂 ) que comenten sobre sus aplicaciones para aprender y nutrirse de la experiencia de otros. Hay una versión gratuita para descargar en InfoQ (también ahí pueden comprarlo) o en español.

Todavía no estamos utilizando estimación ni burndown charts, pero ya habrá tiempo. Cada Sprint ha sido mejor que el anterior, tanto en la gestión del Scrum, como la agilidad del equipo. Así que habrá tiempo para ir perfeccionándolo.

Pizarra Scrum

Me compré una pizarra de corcho para usar de Task Board y comenzar a implementar Scrum en casa. Como comenté en el post anterior, pienso aplicar Scrum para estudiar. Para empezar, compré unos post-its amarillos, y esta pizarra de 45×60 cm:

Pizarra Scrum
Pizarra Scrum

Estamos avanzando bien con la implementación de Scrum en el trabajo. Hemos ido aplicando algunas cosas interesantes, y se viene mejorando el proceso de a poco. Ni bien tenga tiempo, escribo un  resúmen de cómo ha ido.

En cualquier momento empezaré a trabajar en la aplicación de Scrum para mis estudios, y ahí empezaré a contar cómo lo voy manejando y qué voy aprendiendo.

Estudiar con Scrum

El siguiente post es solo una idea, que pienso probar de poner en práctica, y ver si me funciona. Estoy retomando los estudios en la Facultad de Ingeniería. Además de eso, estoy trabajando y tengo unos cuantos proyectos más en la lista de cosas para este año. Si bien pienso dedicarle tiempo a la facultad, soy conciente que con la cantidad de cosas que tengo arriba, no voy a poder dedicarle una cantidad importante de tiempo.

Por esto, tengo que exprimir el tiempo que le dedique a los estudios, usándolo de manera efectiva y aprovechando cada minuto. Se necesita una buena gestión de la cantidad de trabajo, priorizándolo según el retorno de inversión de tiempo que tenga cada tarea. Así que sin pensar demasiado el tema, puedo perfectamente aplicar Scrum para organizar de manera efectiva mis estudios.

Esto sería una aplicación de Scrum personal, donde yo mismo ocuparía el rol de Scrum Master, Product Owner y equipo. Como Product Owner, voy a saber cuáles son las tareas que me interesan más, según su retorno de inversión, poniéndolas por delante de aquellas que me resulten más fáciles o simples. Como Scrum Master voy a ser responsable de que mi Scrum se realice de manera positiva, y como equipo, voy a estar encargado de realizar mis tareas.

Es algo que estoy considerando, debería probarlo por un tiempo. Tendría además que obligarme a cumplir las instancias de Scrum: Sprint Planning, Daily Meeting, Retrospectiva y Reflexión.

Sprint – Debería hacer los Sprints de corta duración: 1 semana; ya que de a poco voy a ir viendo qué hay por estudiar por cada materia. Además, podré priorizar los temas a estudiar según los resultados que vaya obteniendo: «En esta materia me fue mal en el parcial, tengo que dedicarle más tiempo». El Sprint Planning debería hacerse todos los lunes o domingos, ya que es cuando comienza la semana de clases. Incluso podría hacer un burn chart, donde detectaría qué materias me cuesta más estudiar basado en los resultados que obtenga.

Daily Meeting – Como en un equipo de trabajo, se trataría de verificar la cantidad de tareas estimadas contra las realizadas, detectar problemas, y comprometerse con nuevas tareas.

La retrospectiva y reflexión serían bastantes personales, ya que yo mismo estaría revisando si los resultados obtenidos son satisfactorios.

Es importante tener un backlog, donde pueda ir pegando tareas «por realizar», para ir incluyendo en Sprints siguientes.

Todo esto requeriría un compromiso personal con el trabajo (el estudio), y demandaría bastante disciplina de mi parte. Es algo bastante complejo, creo, pero sencillo a la vez. Me mantendría fuera de la zona de confort, y como siempre digo: usar Scrum para gestionar el trabajo es mejor que no usar nada.

En fin, realmente lo estoy considerando aplicar. Voy a ver si consigo un pizarrón, unos post-it, y empiezo. También voy a incluir tareas de otros proyectos, reuniones y demás, para gestionar el tiempo completo de forma realista. Al igual que en los proyectos de software, en la vida diaria aparecen muchas tareas no planificadas. Por esto, estoy pensando si usar una referencia de colores de post-it según el área a la que involucren: estudio (incluso por materia), trabajo, otros, etc. o según tareas planificadas, no planificadas, etc.

Creo que podría usar post-it amarillos para tareas que se desprenden de la planificación y post-it rojos para tareas que surjan de apuro. Como referencia, puedo usar los post-it más chicos que hay de distintos colores, para identificar a qué área pertenecen. En fin, por ahora esto es solo una idea, pero creo que por lo menos voy a probarlo…

Nuevo curso de Certificación Scrum Master en Montevideo, Uruguay

La empresa AQuA.it, encargada del primer curso de Certified Scrum Master en Uruguay, está realizando una segunda instancia este año. Alan Cyment vuelve a cruzar el charco, lo que seguramente de lugar a algún otro tipo de evento con la gente que ya hizo el curso el año anterior:

Estamos organizando el segundo curso en Uruguay con certificación internacional otorgada por la Scrum Alliance de la metodología ágil de gestión de proyectos llamada SCRUM.

La palabra SCRUM fue utilizada como nombre para esta metodología con el mismo significado que tiene ella en el Rugby. En este deporte se utiliza a la unión de todos los integrantes del equipo, como si fuera un solo hombre, para “cruzar” la cancha y poner la pelota en meta contraria. Para ello se basan en táctica y estrategia. De manera análoga un equipo de trabajo que utiliza SCRUM debe ir generando “puntos” durante el proyecto hasta finalizarlo. La metodología es un framework que describe el camino para poder lograrlo, es decir, la táctica y la estrategia.

Contenido del curso

Enseñar todos los fundamentos y conceptos de Scrum: Roles, Rituales y Artefactos.

Existen 3 roles en Scrum: Team, Product Owner y ScrumMaster. Se explicará las funciones de cada rol y su interacción, dependencias, etc. Dedicando más tiempo al rol del ScrumMaster.

Los Rituales se describirán detalladamente, respondiendo; ¿qué son?, ¿para qué sirven? ¿cómo se implementan? ¿cuál es la agenda de cada una? ¿y su frecuencia? ¿cuál es su input/output? ¿cuál es el objetivo concreto de cada una? Todas éstas respuestas determinarán el buen uso de la metodología y el éxito de su aplicación.

El ciclo de vida de Scrum está basado en Sprints, éstos permiten hacer entregas periódicas del producto en lapsos muy breves, en donde se parte de la base que el producto nunca está definido completamente, por el contrario, es entiende que su definición es evolutiva. Por tal razón será una parte fundamental del curso comprender y practicar el ciclo de vida que propone esta metodología.

Se mostrarán los documentos y gráficas que existen en Scrum para poder mostrar datos del proyecto que permitan tomar métricas de gestión.

Aunque no es parte de Scrum, también se explicará como combinar este framework con otras metodologías ágiles, por ejemplo XP. Dentro de este marco se utilizaran las User Stories, ¿cómo aplicarlas? ¿cuál es su formato? etc.

Se expondrán las grandes diferencias, ventajas y desventajas de esta metodología y las tradicionales.

Dada la experiencia del entrenador internacional, responderá cualquier consulta que los participantes tengan y enriquezcan el curso.

Dinámica

Es un curso totalmente interactivo, en donde se forman equipos para ir aprendiendo Scrum para practicar los conceptos. Asimismo el entrenador utiliza novedosas técnicas para sugerir cómo abordar los cambios de paradigma que se necesitan.

No se pueden utilizar teléfonos celulares ni portables durante el dictado del curso.

Entrenador Oficial

El Sr. Alan Cyment estará encargado de dictar este curso. Tiene varios años de experiencia en Scrum, en varios proyectos desarrollados en diferentes países. Es un entrenador certificado por la ScrumAlliance quién es la entidad que evalúa y otorga las certificaciones en esta disciplina. Alan es un investigador graduado en Ciencias de la Computación, título otorgado por la Universidad de Buenos Aires. Actualmente está escribiendo un libro con uno de los practicantes más reconocidos en éstas metodologías, el Sr. Tobias Mayer. Además, Alan es el único entrenador oficial de Scrum de habla hispana, con cualquier otro el curso sería dictado en inglés.

Agenda

Fecha de comienzo: Jueves 22 de julio de 2010.

Fecha de finalización: Viernes 23 de julio de 2010.

El curso se dictará en dos días consecutivos en el Hotel Ibis de Montevideo (A Confirmar).

Cada jornada comenzará a las 9am en punto y finalizará a las 6pm.

Mecanismo de evaluación

Examen escrito al finalizar el curso. Quienes lo aprueben recibirán una notificación por mail para descargar el certficado oficial de la ScrumAlliance y además una membresía gratis por un año.

Costos

El costo del curso son 600 dólares americanos +  impuestos.

(No está incluído el almuerzo, solo coffee break)

Única forma de pago: Depósito en la cuenta dólares 8640416, Banco ITAU, Sucursal Aguada.

CSM Gabriel Ledesma

Primer planificación de Sprint

El lunes pasado tuvimos el primer Sprint Planning de la reimplementación de Scrum. Estuvo bastante bueno, como siempre, una de las principales ventajas de Scrum es que se comience una nueva etapa en la comunicación y colaboración del equipo. Ese cambio de cabeza, de perder el rol de «jefe», y pasar a que el trabajo de cada uno sea responsabilidad del equipo hace a un cambio general en el ambiente, no tanto en el plano personal del trato entre los miembros del equipo, sino la forma de encarar el trabajo en sí. Se hace mucho más dinámico y efectivo, además de organizado. Estoy hablando de un equipo donde anteriormente no se usaba una metodología específica de desarrollo, sino que se iba sacando el trabajo.

Va costando un poco, uno de los temas complicados es que un equipo pase de no tener horarios a cumplir con el timeboxing. Si bien los horarios de las reuniones se eligen en equipo, a algunos les sigue costando, por lo que a veces caemos en el error de esperar 5 minutos a que llegue un miembro u otro al Daily Meeting.

Algo que me dió la impresión durante esta primera planificación, es que el Product Owner cayó en la idea que su trabajo no es para nada trivial, sino que acarrea una responsabilidad bastante grande. Si bien demuestra que se nutrió bastante con la metodología, leyendo varias documentaciones y recursos, dió la impresión de que en ese momento realmente asimiló la cantidad de trabajo. Recordemos que el rol del Product Owner conlleva muchas funciones. Debe actuar como filtro y representante de los stakeholders, así como negociar y priorizar elementos del backlog. En fín, al igual que el resto de los integrantes, irá aprendiendo en el camino.

Y es que Scrum es una metodología ideal para ir aprendiendo sobre la marcha. Hemos estado pasando enlaces con documentos y demás y transmitiendo la idea, pero es un proceso evolutivo. Somos dos los que venimos oficiando de Scrum Master, retroalimentándonos en el rol, y tratando que los demás asimilen la esencia de Scrum para aplicarlo en armonía con el ideal que lo hace tan efectivo y productivo.

Todavía falta transmitir algunos conceptos fundamentales, y el equipo se va a ir amoldando. Algunos puntos importantes que quedaron en el tintero para ir mechando durante las reuniones fue la visión del equipo y el working agreement. Si bien no son imprescindibles para implementar la metodología, creo que sirven para afianzar la confianza y el respeto entre los miembros del equipo, y permite concretar un primer proyecto en común.

Pero ya estamos usando la gestión visual del proyecto con un task board. Usamos un pizarrón con 4 columnas:

  • Backlog: En esta columna pegamos post-its amarillos grandes, con varias tareas (a alto nivel) que se fueron determinando en el primer planning. Obviamente está abierto a más post-its en el futuro, ya que es el backlog general del producto.
  • Sprint Backlog: Es el «TO DO», lo que hay por hacer, las tareas comprometidas para este Sprint.
  • En proceso: Las tareas en las que se está trabajando.
  • Terminado: Tareas prontas.

Como referencia, ya que no estimamos esfuerzo por cada tarea, vamos marcando un punto rojo por día transcurrido de la tarea en la columna «En proceso». Al no haber estimado, no tenemos todavía un Burndown chart, pero los puntos rojos van a ayudar a empezar a estimar más adelante.

Este primer Sprint, como experiencia, lo hicimos de corta duración. Empezamos el lunes y terminamos el viernes. El lunes siguiente haríamos una retrospectiva y review del sprint, y un nuevo planning. Dependiendo de cómo nos vaya, lo haremos de una o dos semanas de duración. Iré comentando nuevas experiencias y observaciones a medida que vayan surgiendo.