Cosas que hacen que Scrum funcione

Escrito el 30 de Noviembre de 2007 a las 13:11 

Que sí, que sí: que scrum es muy sencillo. Que se explica en cinco minutos. Que se lo puedo explicar hasta a mi abuela. Pero que algo más tendrá Scrum cuando en el último curso hemos estado dieciséis horas analizándolo (sin contar almuerzos) e incluso nos ha faltado tiempo.

Scrum es indudablemente más sencillo que los frameworks pesados para la gestión de proyectos como puedan ser el PMBOK o Métrica V3 (¡ergs!), e incluso más sencillo que las versiones “lite” que se han diseñado de los frameworks pesados, como puede ser Prince2. Pero eso no quiere decir que si echamos a andar los famosos tres procesos, tres artefactos y tres roles ya lo tengamos todo hecho. Hay muchos aspectos que son los que hacen que Scrum funcione, y la atención a estos aspectos marca la diferencia entre el 66% de empresas que consiguen implantar Scrum efectivamente y el 33% que abandona por el camino (datos de la Scrum Alliance).

Ahora que empieza el iweekend (que rabia habérmelo perdido) y sabiendo que Raúl está mirando metodologías ágiles para aplicarlas, me he decidido a escribir este post. En base a mi experiencia y a literatura existente (que la hay como para enterrar a un gran danés en papeles), las cosas que hacen que Scrum funcione son las siguiente:

  1. Scrum es sencillo, pero muy duro. Como un canto rodado, vaya. Si pensamos que Scrum no nos va a requerir un esfuerzo, es más que probable que la gente abandone cuando se de cuenta de que exige una importante dedicación, un proceso de gestión del cambio que puede llegar a ser muy complicado y un nivel de foco superior al que se habitualmente se tiene en las organizaciones. Aun así, los resultados que Scrum proporciona en términos de productividad, calidad, satisfacción, éxito y rentabilidad de los proyectos hacen que el esfuerzo merezca la pena.
  2. Scrum no es una bala de plata. Esto, junto con lo de las gallinas y los cerdos, es uno de los principios más citados de Scrum. Cuando la gente se sumerge en el mundo de las metodologías ágiles y ven lo que pueden llegar a conseguir siente la tentación de recetar “café para todos” (en palabras de Mario). Y eso no es así. Scrum tiene su territorio: proyectos complejos, con un requisitos cambiantes, organizaciones flexibles, implicación del cliente… En otros entornos es mejor usar otras cosas. Por otra parte, Scrum no va a solucionar todos los problemas de la organización. Si falta compromiso de la gerencia, si hay compañeros obstruccionistas., si el cliente es un explotador…Bueno, Scrum no va a solucionar todo eso. Si pensamos que sí y fallamos, sentiremos la tentación de abandonar Scrum. Por eso es importante recordar constantemente que Scrum no es una bala de plata.
  3. Scrum es iterativo e incremental. Repetid conmigo: iterativo e incremental. Iterativo e incremental. Eso quiere decir que liberamos código (o producto) frecuentemente, y cada liberación representa un incremento sobre la anterior. Pensad más en “Casa 0.1″, “Casa 0.2″ hasta “Casa 1.0″ que en “cimientos” seguido de “paredes” seguido de “techo”. No podemos liberar una casa sin techo, pero a lo mejor sí una casa con paredes de chapa y techo de uralita (version “chabola”… Todo tiene un mercado).
  4. El producto que funciona es la única medida del avance del proyecto. Si me tuviera que tatuar una frase sobre Scrum, sería esta. No cuántas horas hemos echado. No cuántos recursos llevamos consumidos. No cuántas tareas llevamos hechas. Producto que funciona. Si no hay producto que funciona, no avanzamos. Lease el punto anterior.
  5. Todo en Scrum tiene un límite de tiempo. Para esto me gusta mucho la expersion inglesa time-boxed, que lo expresa mejor. Nada de “alargamos la reunión un poco más”. Nada de “El lunes, tal vez el martes”. La reunión acaba a las cuatro, y trabajaremos con lo que tengamos al final de la misma. La entrega es el lunes, y entregaremos lo que tengamos el lunes. Scrum cambia el enfoque tradicional del PMBOK de recursos+funcionalidades deseadas = fecha de entrega y lo convierte en recursos + fecha de entrega = funcionalidades que podremos entregar. Si se nos cae una funcionalidad de la lista, vaya por Diox. Pero entregamos.
  6. Las entregas son productos potencialmente utilizables y/o comercializables. Shippable, que dicen los ingleses. Eso significa que nada de power point y nada de planos o documentos describiendo lo que hará la aplicación: queremos tocar, ver y usar algo, aunque sea un prototipo de la funcion de login.
  7. Definir qué significa terminado. Terminado puede querer decir “rula” o puede querer decir “rula, ha pasado los tes de calidad, se ha documentado, se ha añadido al repositorio y hemos formado a soporte técnico”. No es lo mismo. El trabajo no se acaba hasta que se acaba.
  8. Mantener Sprints de duración fija. Al principio es muy tentador andar tocando la longituds de los sprints para adecuarlos al producto, en vez de adecuar el producto a los sprints. Pero si hacemos lo primero nunca seremos capaces de obtener una sensación correcta en el equipo de cuánto trabajo podemos abarcar en un Sprint. Scrum es disciplina: quien piense que las metodologías ágiles on una especie de hacking institucionalizado, se equivoca.
  9. 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”.
  10. Hacer retrospectivas. Lo más importante de las retrospectivas es asegurarse de que se celebran. Las retrospectivas son lo que nos permite detectar impedimentos de alto nivel en el proceso y mejorar constantemente. Si nos enfocamos demasiado en los sprints y en producir y no nos paramos de vez en cuando a reflexionar, todo el enfoque empírico y adaptativo de Scrum se nos viene abajo. Como decían por ahi, “si siempre estás sprintando, en realidad acabarás haciendo jogging”.
  11. Respetar los roles: Sólo el Dueño de Producto puede tocar la pila de producto. Solo el euipo puede tocar la pila de Sprint. Permitid que los Jefes manoseen la pila de producto o que el dueño de producto trastee con la pila de sprint y acabaréis con unos equipos que mandarán Scrum a hacer gárgaras hartos de que no se les deje trabajar ni se confíe en ellos. Scrum es adaptativo, pero eso no quiere decir que todos los días peguemos volantazos: es más bien hacer pequeños movimientos de volante constantemente para mantener al coche en la carretera. Aquí es donde viene bien la historia de las gallinas y los cerdos: distingamos también entre miembros del proyecto y stakeholders.
  12. El Scrum Master no es un jefe. Es un “siervo-lider”. No le dice a la gente lo que debe hacer. No divide las tareas entre los miembros del equipo. No acepta o rechaza las funcionaldiades. El equipo es quien decide, y el dueño de producto el que evalua. El Scrum Master sólo debe preocuparse de que el proceso Scrum siga en marcha y de eliminar los impedimentos en el camino del equipo. Tiene más de Coach que de Project Manager.
  13. No interrumpir constantemente a los equipos durante los Sprints. Si no confiamos en los equipos y les dejamos trabajar, ¿qué estáis esperando que ocurra? Una terminación anormal de Sprint debería significar que algo muy gordo está pasando en la empresa o en el proyecto. Y si hay que hacer re-priorizaciones, que afecten al próximo sprint en la medida de lo posible, no al que está ahora mismo en marcha.

En fin, probablemente no estén todos los que son, pero son todos los que están. Espero que esta lista os sea de utilidad implantando Scrum, y vigilaré ansioso los twitter del iweekend este fin de semana. ¡Animo tíos! ;-)

PD: Para los supersiticiosos, cogéis el punto 11 y lo dividís en “solo el dueño de producto toca la pila de producto” y “solo el equipo toca la pila de sprint”…¡Voila! 14 puntos. :twisted:

Categorías: Blogs, Emprendedores, Eventos, Gestión de Proyectos
Tags: ,,,
10 comentarios | Compártelo

Certificación PMP

Escrito el 15 de Noviembre de 2007 a las 18:30 

Recibo cierta cantidad de mensajes preguntando por los pasos necesarios y recursos disponibles para obtener la certificación PMP (os recuerdo que estoy en ello). Recuerdo que en su día ya me resultó algo confuso obtener información sobre la forma en la que solicitar el exámen, dónde hacerlo, el coste del mismo o cómo prepararlo. Ervin me ayudó en su momento a solucionar varias de estas dudas, así que os resumo a continuación lo que conozco al respecto:

Una vez obtenido el PMP hay que mantenerlo a lo largo del tiempo obteniendo PDU’s (Personal Development Units) a razón de unos 60 al trienio… Pero eso, amigos míos, es otra historia ;-)

Categorías: Formación, Gestión de Proyectos
Tags: ,,,
5 comentarios | Compártelo

Buscar:

Suscriptores:

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