Uso de Scrum

Introducción a Scrum en Agile in Africa 2015 [ENG]

Cómo es ser Professional Scrum Trainer

En Marzo de este año, me hice Professional Scrum Trainer de Scrum.org, después de un proceso un poco largo que comenzó en Diciembre. Todo empezó cuando mi buen amigo Nana Abban, al que conocí haciendo Agile Coaching en Capital One UK, me picó con Evidence Based Management y Agility Path. Agility Path es un software diseñado por Scrum.org para tener métricas de las implantaciones ágiles en organizaciones, y algo que, en definitiva, es muy necesario.

En Noviembre tuve una primera conversación con Daphne Harris y Patricia Kong, donde me dijeron que ahora mismo no estaban aceptando nuevos EBMgt, pero que si me había planteado tomar el camino de hacerme Professional Scrum Trainer. Con mi experiencia y conocimiento podría ser un buen añadido a la comunidad de Scrum. La verdad es, que aunque si había pasado por mi cabeza algunas veces, siempre lo había descartado por distintos motivos.

Para ser Professional Scrum Trainer hay que:

Pasar el test PSM I (80 Preguntas, 60 Minutos) con un mínimo del 95%. No es sencillo, yo lo probé justo después de hablar con Daphne y Patricia y saqué un 93%. Algunas preguntas realmente te hacen pensar. Para el PSPO o el PSD varía.
Asistir a un curso Train The Trainer. Yo asistí en Holanda con Gunther Verheyen y otros 13 candidatos a Professional Scrum Trainer que además era un curso PSM abierto al público. El último día es sólo para candidatos a Trainer donde se discuten temas del curso y del material.
Pasar el test PSM II -Ahora PSE- con un 95% (40 Preguntas, 60 minutos). Si el test PSM I es de respuesta múltiple, el PSM II es tipo ensayo basado en situaciones y es realmente complicado. Requiere de un gran conocimiento de Scrum para pasarlo. Yo lo hice a la primer y por los pelos, con un 96%.
Asistir a un Peer Review con al menos otros tres Professional Scrum Trainer. Éste Peer Review dura al menos una hora y se le hacen preguntas al candidato que podrían salir en clase, además de intentar entender su estilo personal. Los otros Trainers tienen que estar de acuerdo en que es un buen añadido a la comunidad.
Pagar la licencia. Al final de todo, queda pagar la licencia ($3500) para convertirse en Professional Scrum Trainer.

Lo que me aporta ser Professional Scrum Trainer

Ser PST no es solamente dar cursos, sino que hay un compromiso personal con la evangelización de Scrum, además de una presión hacia seguir aprendiendo cómo profesionalAdemás de lo más evidente, que es poder hacer cursos de certificación y tener un servicio en mi cartera que es bastante demandado, hay muchísimos más beneficios de ser Professional Scrum Trainer.

La comunidad de Trainers es espectacular. Empezando por la oportunidad de compartir comunidad con uno de los creadores de Scrum, Ken Schwaber, que participa activamente, y pasando por gente como Gunther o Steve, además de otros casi 100 PSTs que tienen un perfil bajo pero que aportan increíblemente a la experiencia. Es una de esas comunidades donde lees todos y cada uno de los mensajes de la lista de correo y donde todas las aportaciones son útiles.
Los materiales suplementarios. Una de las estrategias diferenciadoras de Scrum.org es la elaboración de sus propios materiales para favorecer la estandarización a lo largo de todos los cursos PSM, PSPO, PSD y SPS. Esto, a pesar de parecer problemático, es uno de los sellos de calidad. Cuando yo, cómo Trainer, elaboro mi propio material, puedo estar dejando pasar determinados aspectos que pueden ser importantes para el aprendizaje.
Acceso al mundo Agile. Los PSTs somos miembros de la Agile Alliance, tenemos acceso a mucho material adicional, como el informe CHAOS del Standish Group, publicamos nuestros cursos en la Agile Alliance, tenemos acceso a conferencias, varios encuentros privados anuales y un largo etcetera.

¿Y la calidad?

Yo he aprendido mucho sobre Scrum en este proceso. Me doy cuenta como en España han faltado formaciones y trainings de calidad que hagan hincapié sobre aspectos fundamentales de Scrum. En grado de divertimento de aquellos a los que he asistido, diría que todos han sido muy divertidos y con muchos juegos, pero en general, falta conocimiento profundo sobre el tema. Conocimiento que se adquiere pensando más que jugando. Y no soy el único que piensa así.

Esto es lo que decían José Manuel Beas y Antonio de la Torre, dos conocidos Agilistas en España, sobre el curso PSM de Madrid:

Sí puedo decir que el material que entrega Scrum.org y el nivel de debate que provoca Jerónimo durante el curso es bastante bueno. Dada la dinámica del curso, fuertemente basada en el “training from the back of the room”, es muy importante la implicación de los alumnos en el debate.

Es un curso muy profesional, orientado a que empleemos el pensamiento crítico para entender los fundamentos de Scrum y no incorpora nada de “show”. Si esperas jugar con legos, con pegatinas y tal, olvídalo. Este curso no es para ti. Se supone que ya has leído qué es Scrum y vienes a aprender de verdad sus fundamentos.

José Manuel Beas

Lo hice en la pasada edición de Madrid. Es un curso con un buen material ya preparado, tanto diapos como la copia que te llevas.

A mi me gustó, porque es lo que es, un curso sobre el framework. Te enseña a separar lo core , de lo accesorio, haciendo que el cargo cult que suele haber detrás en equipos que empiezan se minimice. O por lo menos lo entiendas mejor.

No es un curso en el se vaya a jugar a las sillas, ni se profundiza en los valores ágiles con dinámicas. Se trabaja en equipo sobre casos reales y se trata de darle al coco entre todos.

Antonio de la Torre

El día a día de un Professional Scrum Trainer

Siendo Professional Scrum Trainer no te haces rico. Es algo más que puedes añadir a tu portfolio de servicios y que complementa lo que yo, personalmente, he venido haciendo durante los últimos años. Llenar los cursos no es fácil y requiere de una labor comercial que probablemente no todo el mundo está dispuesto a hacer.

Obviamente, estar representado en la página de Scrum.org y de la Agile Alliance da una cierta visibilidad; las personas que vienen a mis cursos lo hacen porque ya me conocen de otras formaciones o porque me han visto en acción en eventos y conferencias.

Por otro lado, siempre hay oportunidades de colaborar haciendo cosas dentro de la comunidad. Desde participando en Peer Reviews hasta dando feedback en la nueva guía de Nexus.

Personalmente, yo el año que viene renovaré mi licencia para seguir siendo Professional Scrum Trainer.

Creando espacios físicos de trabajo para equipos ágiles

A pesar de todo lo que escuchamos sobre agilidad y auto-organización de equipos de trabajo ágiles, estamos todavía muy lejos de construir entornos que realmente reflejen esa realidad. Scrum está basado en el empirismo: Transparencia, Inspección, Adaptación y vuelta a empezar. Incluso en grandes empresas que invierten en crear buenos espacios de trabajo, parece que la idea no ha calado lo suficiente. Hay que dar a los equipos la oportunidad de ser autónomos y tomar decisiones -a pesar de que haya voces que digan que la auto-organización es un mito- sobre como crear sus propios espacios de trabajo.

El secreto está en manejar restricciones, no en hacer planes

Muchas organizaciones, cuando se trata de remodelar espacios de trabajo, contratan a una empresa externa que les diga como hacerlos. Esta empresa elabora un plan y hace lo que cree que es mejor. En la mayoría de los casos, lo que es mejor es buscar lo que hacen las grandes del sector tecnológico y copiarlo sin el más mínimo atisbo de vergüenza.

Cuando los equipos empiezan a trabajar en los nuevos espacios, es cuando se descubre que hay pocas -o muchas- salas de reuniones. Que no hay espacios que permitan la comunicación abierta y el trabajo de 20 o 30 personas en un LiftingOff o que algún lumbreras pensó que lo mejor era optimizar el espacio y sentar a los distintos miembros de un equipo a 300 metros unos de otros.

Para realizar una reestructuración del espacio en organizaciones ágiles, se atiende a varias restricciones: Número de equipos (no de personas), Número de espacios de los que los equipos son dueños y número de espacios adicionales que necesitamos, prevención de riesgos, etc. En muchas ocasiones me encuentro con que la respuesta es: Es que así organizamos la empresa alrededor de la Informática. Bien, precisamente esa es la idea. Si tu empresa depende de la tecnología para funcionar, entonces asegúrate de que la tecnología está bien cuidada.

Los equipos son dueños de su espacio

Cuando se plantea una reorganización física, lo mejor es darles a los equipos un espacio y dejarles que ellos decidan como organizarlo, contando con el apoyo necesario. La primera imagen que puede venir a la cabeza es la de un equipo que decide poner sofás en lugar de mesas o llenarlo todo de neveras de Red Bull. Ahí va un secreto: Los equipos no están formados por retrasados mentales y, además de tener las mismas ideas sobre un espacio que tu tienes, conocen mucho mejor su trabajo para entender que: Puede que necesiten espacios para colocar radiadores de información adicionales, un espacio físico para trabajar con hardware o un espacio abierto para poder reunirse sin tener que depender de un planner en Outlook.

Los equipos son responsables de su espacio

La mejor manera de reorganizar espacios es dar la posibilidad de tener un set de elementos para poder utilizar: Mobiliario, Pizarras, Televisores, Suelo, Pintura, etc.. y que el equipo haga un trabajo de adaptación a sus necesidades. Porque DevOps no va a tener las mismas necesidades que tu producto A o tu producto B.

Ser responsable del espacio significa tener la oportunidad de readaptarlo cada vez que sea necesario, de nuevo, atendiendo a las restricciones, por ejemplo, de presupuesto. Un espacio organizado así puede responder a los pilares de Transparencia, Inspección y Adaptación mucho mejor que un equipo que cada vez que tiene que cambiar una silla, tiene que rellenar un formulario pidiéndolo a mantenimiento.

Los espacios sirven propósitos, no estética

Los escandinavos lo tienen claro. El diseño sirve un propósito, no a sí mismo. Los equipos de un cliente con el que trabajé en 2012 tenían a sus miembros distribuidos por toda la empresa con arreglo a áreas funcionales. No podían hacer los Daily Scrum en el mismo sitio todos los días, ni siquiera a la misma hora, porque había tal problema con las salas de reuniones que, en un momento dado, todo estaba reservado y había una especia de mercado “negro” interno para negociar con las horas de las mismas.

El resultado era un equipo que no podía hacer lo más básico de Scrum: Tener un Daily Scrum en el que todos los miembros pudieran inspeccionar y adaptar el Sprint Backlog. La solución fue trasladar el Daily a la cafetería más cercana, hasta que el manager funcional empezó a quejarse porque estaban mucho tiempo fuera. Cuando empecé a trabajar con este cliente, le pedí a dos Senior Managers que me acompañaran durante dos días a observar Daily Scrums. Fue un caos.

El Verano siguiente, esta multinacional reformó sus oficinas para crear espacios abiertos donde cada departamento tuviera al menos 5 o 6 espacios donde poder trabajar sin necesidad de pasar por el planning. Esto supuso una reducción de salas de reuniones y ocasionó quejas de los expertos en reunirse. Durante el proceso se descubrió que había una persona que reservaba distintas salas de reuniones a lo largo del día para trabajar en ellas. Se había creado una especia de despacho móvil. Lo había hecho porque sentado en su mesa, las interrupciones no dejaban de llegar.

Una pequeña conclusión

La reorganización de espacios refleja la cultura real de una empresa. Si ésta es impuesta, sin consultar y sin tener en cuenta las necesidades reales, no se puede esperar mucho de los productos que crean. En el anterior ejemplo, el cliente me contrató bajo la premisa de que “Scrum no funcionaba”. No hizo falta más de una semana para demostrar que el problema no era Scrum, sino que Scrum hacía visibles problemas que antes estaban enquistados. Y este es precisamente su poder.

17 Mitos y falacias de Scrum

Cuando las organizaciones deciden adoptar agilidad, la mayoría opta por Scrum por ser el MÉTODO MAS POPULAR Y UTILIZADO DEL MUNDO. Sin embargo, muchas caen en los mismos mitos y falacias de Scrum. Veamos algunas de ellas y como evitarlas

Un Scrum Master por equipo

Scrum recomienda que en cada equipo exista un Scrum Master y un Product Owner, sin embargo no dice que tenga que ser una persona dedicada totalmente al equipo. Sí advierte de que si no están dedicadas al equipo, eso puede suponer un impacto en la productividad.

Mi opinión es que tener un Scrum Master por equipo es algo fundamental, sobre todo cuando se trata de nuevos Scrum Masters que requieren de tiempo antes de empezar a tener una visión holística del proceso. Hay diferencia de opiniones en este aspecto.

Debe haber un Product Backlog antes de empezar el Sprint

Mito. Aunque es muy positivo que exista un Product Backlog antes de empezar el Sprint, este puede perfectamente realizarse como parte del Sprint Planning e ir refinándose durante el Sprint. De hecho, puede ser una tarea totalmente factible para un primer Sprint.

Lo que Scrum dice es que, independientemente de como se haya iniciado el Sprint, al final de este debe haber un Incremento, es decir, Software listo para entregar al cliente, por pequeño que éste sea.

Los Sprints deben durar dos semanas

Falacia. Los Sprints deben durar lo necesario para poder entregar un Incremento completo y nunca más de cuatro semanas. El motivo es que si duran más, se pierden oportunidades para inspeccionar y adaptar. Si con Sprints de dos semanas no se consigue tener un Incremento “Listo”, entonces hay que revisar la duración del Sprint.

Debe existir una Definición de “Hecho” (Definition of Done)

Falso. La definición de “Hecho” o Definition of “Done” es una práctica recomendada pero no forma parte del núcleo de Scrum. La definición de “Hecho” recoge todas aquellas actividades recurrentes que deben de tenerse en cuenta antes de terminar un Incremento. Esta práctica mejora la transparencia de los Incrementos.

El Daily Scrum es una reunión de sincronización

Falso. El objetivo del Daily Scrum es tener una oportunidad diaria para Inspeccionar y Adaptar. El resultado del Daily Scrum es un Sprint Backlog actualizado con un plan para las próximas 24 horas y lo que va a ocurrir en los próximos días. Muchos equipos acuden al Daily Scrum y se limitan a decir lo que han hecho y lo que harán, o para comunicar impedimentos. Muy pocos realmente tienen un Sprint Backlog actualizado después del Daily Scrum.

Los ítems del Product Backlog deben estar estimados

Verdadero. Scrum dice que los ítems del Product Backlog deben estar lo suficientemente refinados y ser suficientemente pequeños para ser potencialmente entregables al final del Sprint y, además, estar estimados. Scrum no dice si esta estimación debe ser hecha en Puntos de Historia, mediante Slicing u otras técnicas. La estimación es necesaria porque mejora la transparencia y la inspección.

Esto significa que algunos ítems del Product Backlog, los que están más arriba estarán más refinados y mejor estimados y otros, los que estén más abajo, no lo estarán.

Un Product Owner por equipo

Esta es una falacia. Lo que es necesario es un Product Owner por producto. Uno. No más. Es posible tener representantes del Product Owner o Proxy Product Owners en los equipos, y siempre las decisiones serán tomadas por el único Product Owner.

Aquí es donde los Analistas de Negocio pueden jugar un papel fundamental, estando integrados en cada equipo y ayudando al Product Owner en sus tareas.

El Daily Stand-Up tiene que ocurrir con todo el equipo junto de pie

Falso. El Daily Stand-Up no existe en Scrum. Se llama Daily Scrum y puede ocurrir de pie, sentado o a través del teléfono. El Stand-Up es una práctica de eXtreme Programming.

El Scrum Master facilita las retrospectivas

Falso. No sólo no tiene obligación de facilitar las retrospectivas sino que además tiene que participar de ellas. Muchos Scrum Masters comenten el error de que facilitar retrospectivas es su responsabilidad y muchos de ellos no participan como uno más durante la retrospectiva. El Scrum Master es un miembro más del equipo Scrum y, como tal, tiene en la Retrospectiva un espacio perfecto para Inspeccionar y Adaptar el proceso.

El Scrum Master tiene que estar en el Daily Scrum

Falso. El Scrum Master tiene que asegurarse de que existe un Daily Scrum, que este dura como máximo 15 minutos y que se utiliza para mejorar la transparencia del Incremento en proceso. No tiene por qué atender físicamente al evento ni facilitarlo.

Las estimaciones tienen que estar hechas en Puntos de Historia (Story Points)

Falso. Los Story Points son una técnica más para estimar ítems en el Product Backlog. Hay muchas otras técnicas que son igual de efectivas -o más- que los Story Points. Los Story Points no se pueden cambiar de un equipo a otro y son una visión subjetiva de la estimación hecha por un equipo determinado.

Las estimaciones se pueden usar para medir la productividad y predecir cuando un producto estará terminado

Falacia. Uno de los mitos y falacias de Scrum mas típicos. La única manera de medir el progreso en Scrum es software finalizado y listo para entregar al cliente. Eso puede cambiar de Sprint a Sprint dependiendo del entorno. Scrum es genial para desarrollar productos en entornos complejos. Realizar estimaciones en entornos complejos basados en estimaciones subjetivas no sólo es infantil (o wishful thinking) sino que además es peligroso.

Una buena herramienta para reducir la incertidumbre es usar “conos de incertidumbre”. Cuanto más grande sea el Product Backlog, más difícil será tener estimaciones precisas.

El Product Backlog solo puede contener Historias de Usuario

Mito. El Product Backlog debe contener cualquier tipo de tarea necesaria para asegurar que el producto queda como el Product Owner quiere. Esto puede incluir tareas técnicas, documentación o tipos de testing. El uso de una Definición de “Hecho” reduce la complejidad para tareas recurrentes que deben ser completadas cada Sprint

Los requerimientos no funcionales tienen que estar en el Definition of Done

Otro de los mitos y falacias de Scrum. Los requerimientos no funcionales (estabilidad, rendimiento) también pueden estar en el Product Backlog.

El Scrum Master no es un puesto de management.

Falacia. El Scrum Master es un puesto de Management, ya que gestiona el proceso Scrum.

El equipo de desarrollo o el Scrum Master no pueden cancelar un Sprint

Verdadero. El Sprint sólo puede ser cancelado por el Product Owner, cuando este ve que no tiene sentido terminarlo, principalmente debido a que los ítems del Sprint Backlog ya no tienen valor.

Equipo Scrum tiene que tener 7 +/- 2 personas

El ultimo de esta serie de mitos y falacias de Scrum. Scrum recomienda que el tamaño del equipo de desarrollo sea de 3 a 9 personas, pero no prescribe que éste sea el número necesario de personas en un equipo Scrum. El tamaño de un equipo Scrum debe de medirse atendiendo a las necesidades del Transparencia, Inspección y Adaptación

Malas implementaciones de Scrum

Llevo unos tres años trabajando con SCRUM y durante ese tiempo he implementado la metodología en 12 empresas. Creo que es un buen número para empezar a tener un poco de idea de qué va esto. La cuestión es que, de un tiempo a esta parte, me encuentro con empresas que ya han implementado Scrum y que tienen multitud de problemas para llevarlo a cabo.

Cuando viajo a la empresa para conocer cuales son su métodos, descubro que aquello a lo que llaman Scrum tiene una cierta similitud con el framework pero se aleja mucho de ser real. Eso hace que Scrum tenga mala reputación. Y eso hará que dentro de tres años, Kanban tenga mala reputación.

En este último año, ya son tres las empresas que suponían Scrum implantado y con las que llevo meses haciendo Agile Coaching para cambiar la realidad de los desarrollos.

Algunas de las razones que convierten una implementación de Scrum en una mala implementación son:

Malos equipos. No es la más habitual, pero a veces ocurre. Yo nunca me he encontrado con esta. Todos los equipos con los que he trabajado estaban formados por buenos profesionales que necesitaban una pequeña guía y encontrar su camino por sí mismos.

Mala empresa. Cuando implementas Scrum, no sólo tienes que cambiar la cultura de los programadores, sino también la cultura de los que se relacionan con ellos. Si no lo haces, en pocos meses tendrás unos programadores aún más presionados que no creerán en nada de lo que les cuentas.

Poco conocimiento. Se ha convertido en un habitual el implantar Scrum haciendo un curso de tres, dos o incluso un día. Realizar una certificación CSM y pretender extenderlo todo a todas las áreas de la empresa es posible, pero difícil. Hay que tener ganas y estómago. Hace falta un apoyo, externo o no, y un trabajo de acompañamiento hasta que el método empieza a estar maduro. Por desgracia, hay algunos consultores que pretenden implantar Scrum como quien implanta monitores, mediante un curso de tres dias y a volar. Scrum requiere de al menos 8 sprints para comenzar a interiorizar.

Deuda técnica. Esta es la más habitual. Pretender trabajar de otra manera arrastrando todo lo que hemos hecho mal antes es la mejor manera de convertir una buena implementación de Scrum en un desastre. Se puede solucionar, pero hay que saber y hacer.

No tener ganas de cambio. En casi todas las implementaciones que he hecho de Scrum, es necesario un proceso previo de gestión del cambio y un proceso posterior de acompañamiento (coaching) del equipo. Hay equipos que están bien cómo están y no quieren cambiar (los menos). Hay equipos que están mal cómo están y tienen miedo de ir a peor (los más).

Implementar Scrum es cómo hacer un buen cocido. Necesitamos poner los garbanzos en remojo un tiempo antes, luego cocinar lentamente y posteriormente emplatar adecuadamente. Obviamente puedes comprar un cocido preparado, pero hacer scrum fast-food es la práctica menos recomendable de todas.