Una de Scrum

Escrito el 26 de Julio de 2007 a las 11:23 

Me encanta Scrum. Me parece elegante en su simplicidad, pero que nadie se lleve a engaños, es un framework muy poderoso siempre que se respeten a rajatabla sus reglas. En este sentido, ocurre como decía el ScrumMaster Miyagi:

ScrumMaster Miyagi

Tu Scrum “sí”…Vale. Tu Scrum “no”…Vale. Tu Scrum “supongo”, tarde o temprano…¡Chof! Aplastado como uva.”

Supongo que eso fue lo que le ocurrió a Chuidiang en su fallido intento por implementar Scrum. Tal como comenta Rodrigo Corral en el más que recomendable blog sobre programación “La masa, el ladrillo, la bota, el bocadillo…“, nadie dijo que Scrum no requiriese un esfuerzo. Y es que uno lee cosas como Scrum en cinco minutos o explicando Scrum a mi abuela y parece que esto es coser y cantar, pero no se debe confundir simplicidad con inmediatez: si uno se aventura por las aguas de Scrum sin contar primero con la experiencia necesaria en gestión de proyectos se puede acabar convirtiendo en el Scrum Master Jar Jar Binks (lectura MUY recomendada a la que llegué vía Navegápolis, igualmente recomendable).

Y no quiero decir que los documentos anteriores no sean estupendos (yo los tengo guardados y los uso). Pero no es lo mismo leer un artículo sobre física cuántica que ponerse a acelerar partículas al frente del CERN. En este sentido, a los que queráis profundizar en el uso y ventajas de Scrum os recomiendo fundamentalmente dos lecturas (aunque posiblemente no descubra nada a los que ya estáis metidos en el ajo): Agile Project Management With Scrum de Microsoft Press es el clásico, y tiene una definición muy concisa de los procesos y reglas de Scrum. No obstante, la parte relativa a las anécdotas y experiencias implementando Scrum es un poco oscura para mi gusto, quedándose en la superficie del proceso y no entrando en los detalles del día a día. En ese sentido es muchísimo más revelador el documento Scrum and XP from the trenches que, además, podéis descargar grauitamente.

Este último es sin duda magnífico, ya que está imbuido de la misma simplicidad que destila Scrum pero además te muestra al detalle cómo implementaron Scrum en una organización real, justificando cada una de las decisiones. Por ejemplo, comentan que sus Sprint duran tres semanas, y explica que es la longitud óptima a la que llegaron después de hacer varias pruebas, en las que comprobaron que si los sprint eran muy cortos, como prefieren los dueños de producto, se conseguían más entregas, más ciclos de realimentación pero también un mayor costo en términos de gestión (más reuniones de sprint, más documentación). En cambio, si los sprints eran muy largos, como prefieren los desarrolladores, había más tiempo para desarrollar, documentar y probar, además de tener menor carga de gestión, pero a cambio los desarrollos eran menos ágiles. Al final, comentan, la longitud del Sprint es un compromiso entre desarrolladores y dueño del producto, y ellos llegaron al compromiso de las tres semanas. Finalmente recomienda que, una vez escogida una longitud de Sprint, esta se mantenga inalterable para todos los equipos, de forma que se vaya formando a los mismos y acostumbrándolos a trabajar en esos plazos. Así es más fácil estimar qué se puede hacer en el Sprint y qué se saldría de las capacidades reales del equipo.

Bien, eso es gestión de proyectos en estado puro. Es incluso más, entra en el ámbito de la cultura corporativa y la madurez de las organizaciones en la gestión de proyectos. Y todo ello sin complejas fórmulas, tremendas herramientas ni farragosas burocracias. Además está mucho más justificado que el “los sprints duran 30 días y uno debe mantener el plazo” del libro de Microsoft. A lo largo del libro explican desde “trucos” para gestionar las reuniones de sprint hasta los campos que debería tener una lista de tareas de sprint o de producto, pasando por cómo mantener un “cuadro de mandos” físico del proyecto y como interpretarlo a simple vista. Genial.

Otra cosa que me encanta de este último documento es el uso que hacen de los paneles en las paredes, las tarjetas adhesivas y las pizarras. A lo largo de mi experiencia como gestor de proyectos, he encontrado que una pizarra en blanco y un taco de post-its son de las herramientas más poderosas con las que uno puede contar, y no estoy exagerando. Lo que pasa es que, y de nuevo entroncamos con Scrum, su elegante simplicidad hace que muchos no se las tomen en serio y piensen que uno está jugando a los consultores y perdiendo el tiempo cuando encierra al equipo a cal y canto y entre todos se dedican a pegar post-its por todas las paredes como si quisieran cambiar la decoración del edificio.

En cualquier caso, ¿Está Scrum orientado sólo a los desarrollos de software? ¿Podría usarse Scrum como método de productividad personal, en una especie de “Scrum de a uno“? ¿Son equivalentes el perfil de ScrumMaster y el del ProjectManager? ¿Merece la pena la certificación ScrumMaster? Creo que son preguntas interesantes a las que iré dedicando algo de tiempo en el futuro.

Categorías: Blogs, Creatividad, Formación, Gestión de Proyectos, Libros
Tags: ,
Compártelo

Comentarios

7 comentarios a “Una de Scrum”

  1. Consultor Anónimo , el 4 de Agosto de 2007 a las 19:25 | Trackback

    Supongo que esto me desacredita como lector de este post, pero… ¿qué leñes es SCRUM?

  2. Consultor Anónimo , el 4 de Agosto de 2007 a las 19:25 | Trackback

    Perdón por la ignorancia, pero… ¿qué narices es SCRUM?

  3. Ángel , el 4 de Agosto de 2007 a las 19:56 | Trackback

    Sr. Hernández, al fondo de la clase… ;-)

    Es un sistema de gestión de proyectos bastante orientado a los desarrollos de software, aunque exportable a otro tipo de proyectos. Echa un vistazo al de “Scrum in cinco minutos” y, si te falta lectura de verano, leete el Scrum and XP from the trenches, que es muy ameno no solo para gestores de proyectos sino para cualquiera que tenga que liderar o gestionar un grupo de trabajo.

  4. El Jefe de Proyecto tiene la culpa (o parte de ella) » Presión Blogosférica , el 18 de Septiembre de 2007 a las 18:05 | Trackback

    […] Otra posible opción que se me ocurre a mi al ver esta chapuza es que el Jefe de Proyecto no distinga una hoja de estilo de las vías del tren, y que no sea capaz de arrancar dos navegadores para hacer las pruebas funcionales porque no tenga pajolera idea de en qué consiste supervisar un proyecto de desarrollo basado en web. Y aunque el Jefe de Proyecto no tenga que ser el tío que más sabe de la materia que gestiona, que para eso ya están los técnicos y los expertos, si tiene que ser capaz de enfrentarse al equipo técnico y argumentar que le están tomando el pelo y que lo que le han entregado es una chapuza. Por otra parte, si se hubiera usado una metodología de gestión de proyectos adecuada, como por ejemplo Scrum, es dificil que las cosas hubieran llegado a este extremo a menos que el Jefe de Proyecto sea un ScrumMaster Jar Jar Binks. […]

  5. Look Ma’, I’m a Certified ScrumMaster! » Presión Blogosférica , el 21 de Septiembre de 2007 a las 20:50 | Trackback

    […] Pues sí. Estoy en Atocha después de dos días intensivos de curso CSM en Madrid de la mano de la increible Stacia Broderick (Thanks so much, Stacia!). El nivelazo de la ScrumLady estuvo a la altura del de los colegas con los que he compartido estos dos días, entre ellos el gran (en todos los sentidos) Rodrigo Corral: - ¿Tu eres Rodrigo Corral? ¡Jo macho! Yo te leo… - ¡Ah, si! Tu eres el que escribió lo del ScrumMaster Miyagui… Te leí también… […]

  6. Que malos somos los Jefes de Proyecto » Presión Blogosférica , el 23 de Septiembre de 2007 a las 17:09 | Trackback

    […] Hace un tiempo os hablé del artículo del ScrumMaster Jar Jar Binks , que sinceramente me hizo bastante gracia por cómo estaba escrito y realmente refleja a determinados profesionales (por llamarles algo) que se han visto ascendidos a Jefe de Proyecto o ScrumMaster por casualidad o por su ambición política más que por sus habilidades, conocimientos o experiencia. Evidentemente, este tipo de profesionales aportan muy poco a los equipos de trabajo, y encima suelen ser vistos como unos trepas inútiles que se pasan el tiempo solicitando informes de progreso y estableciendo controles, preocupados solo por el tiempo y el coste como dimensiones únicas del proyecto. […]

  7. Cosas que hacen que Scrum funcione » Presión Blogosférica , el 30 de Noviembre de 2007 a las 13:11 | Trackback

    […] Realizar los Scrums diarios. Es una de la sprimeras cosas que se abandona, como decían en su día en el blog de chuidiang. Pero el Scrum diario es la unidad atómica de Scrum, y si empezamoscargándonos esto, no podemos esperar que los ladrillos se mantengan unidos. El Scrum diario es lo que consigue que podamos controlar a tiempo, que tengamos visibilidad efectiva, que el equipo sincronice sus tareas… Hay que protegerlo a capa y espada, y ser muy estricto con su celebración. Por eso lo de “todos los días en el mismo sitio, a la misma hora”. Si empezamos a cambiar las horas todos los días, acabaremos por no celebrearlo un día. Entonces pensaremos “anda, no ha pasado nada” y empezaremos a saltárnoslo cada dos por tres. Y entonces estaremos en la situación sobre la que nos previene el ScrumMaster Miyagi: haremos “Scrum supongo”. […]

Deja tu comentario




Buscar:

Suscriptores:

Kisei Dojo Aikido

Pastafari!

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter

    Fotos

    www.flickr.com
    angel.medinilla fotos Más fotos de angel.medinilla
    Cerrar
    Enviar por Correo