Etiqueta: scrum

City Building Game @ UNTreF

El martes pasado en mi curso de Ingeniería de Software hicimos este juego como actividad para poner en práctica un proceso «Scrum-like». Este juego fue diseñado por mis colegas Alejandra Alfonso y Emilio Gutter.

En general veníamos usando el juego del Pajarraco Scrumero porque teníamos grupos chicos (no más de 10 alumnos), pero este cuatrimestre tenemos 30 alumnos y nos pareció que el City Building escalaba mejor que el Pajarraco. Y creo que no nos equivocamos. Si bien en alguna conferencia hemos hecho el Pajarraco con unas ~80 personas, en ese caso contábamos con muchos materiales y varios facilitadores. El Pajarraco requiere de materiales muy específicos (ladrillitos tipo Rasti) mientras que el City Building básicamente requiere de elementos de librería (tijeras, papel y pegamento) que son más fáciles de conseguir.

Lamentablemente Emilio y Alejandra no hay publicado el juego aún. Sin embargo cuando le comenté a Emilio que estaba escribiendo este post, me prometió en breve publicar todos los detalles del juego, así que los interesados pueden contactarlo directamente a él.

Cierro con algunas modificaciones que hicimos al guión original del juego:

  1. Descartamos el papel glase, lo reemplazamos por papeles de colores (tipo los de taquitos de oficina), hojas blancas y lápices.
  2. De la mano de lo anterior agregamos un nuevo rol a los equipos: el pintor.
  3. Solo 4 minutos de iteración nos pareció muy poco, creemos que sería mejor hacer iteraciones de 5 o 6 minutos.
  4. Redujimos el número de tijeras por equipo, creemos que salvo el cortador de círculos, los otros cortadores se pueden arreglar para cortar «a mano».

La hora del Scrum Master técnico

Una publicación reciente de la Scrum Alliance sobre las habilidades en mayor demanda en la actualidad dice textualmente, entre otras cosas, «Delivery-facing agile roles, such as Scrum Masters, are being expected to be technical experts in addition to their agile responsibilities.» Esto está muy en línea con lo que yo mismo he observado en algunos de mis clientes.

Ocurre que en muchas organizaciones se toma el rol de Scrum Master como «exclusivo», o sea: se contrata una persona con habilidades de Scrum Master (y tal vez algunas otras habilidades «blandas») pero sin habilidades técnicas. Esto no está mal, pero tampoco pidamos peras al olmo: una persona sin habilidades técnicas será poco lo que podrá aportar en cuestiones técnicas de desarrollo/delivery. Creo que justamente en línea con este fenómeno (personas que solo saben de Scrum trabajando como Scrum Master) la última versión de la guía de Scrum no habla del Scrum Master como un rol sino como un conjunto de responsabilidades. Esto, a mi parecer, explicita el hecho de que las responsabilidades de «Scrum Mastering» puede ser tomadas por un Developer o algún otro rol (siempre que no haya conflicto de intereses).

Situación recurrente: una persona en el rol de Scrum Master con formación de Scrum Master pero sin formación en sistemas. La organización que lo contrata quiere «delivery» y en parte por ello espera que la persona en el rol de Scrum Master haga más que Scrum dicta del Scrum Master. Pedir que programe puede sonar mucho, pero pedirle habilidades de gestión suena bastante más razonable y aquí está muchas veces la cuestión. La gente que estudio sistemas estudio algo de gestión de proyectos pues es tema presente en todas las carreras de sistemas y hoy en día es muy posible que también haya estudiado Agile en general y Scrum en particular.

En parte fue esta situación la que me llevó a armar el Taller de Prácticas Técnicas para Scrum Masters que tan buena aceptación viene teniendo. En este taller vemos algunas cuestiones técnicas y también algunas cuestiones básicas de gestión de proyectos.

Siguiendo en esta línea de trabajo, estoy empezando a armar un Taller de Técnicas de Facilitación & Gestión para Tech Leads. el cual estará destinado a gente técnica que quiera tomar responsabilidades de facilitador de equipo, Scrum Master, etc. Obviamente tendrá algunos puntos de contacto con los del otro taller pero será un taller diferente y orientado a una audiencia diferente.

Si alguien está interesado en este taller puede contactarme por este formulario y le compartiré más información.

Guía Oficial de Scrum, ¡chau!

En mis materias vengo utilizando la Guía Oficial de Scrum pero a partir de dos charlas distintas que tuve con colegas en la última semana he decidido dejar de usarla.

Resulta que una de las modificaciones «recientes» de la guía oficial de Scrum es que elimina los roles. En realidad no elimina los roles conceptualmente, sino que elimina el término «rol» y en su lugar habla de responsabilidades (accountabilities), o sea: «Scrum Master» es un conjunto de responsabilidades, «Product Owner» es un conjunto de responsabilidades, etc. Según me comentaban mis colegas expertos en Scrum (cosa que yo no soy) es para evitar la usual creencia de que las responsabilidades de Scrum Master deben ser tomadas por una única persona y que esa persona debe dedicarse de forma exclusiva a ello. Pero precisamente eso es un rol, «un conjunto de responsabilidades». Entonces si conceptualmente hablamos de roles pero no queremos usar el término roles, creo que lo que se está haciendo es una «precarización» del vocabulario y al mismo tiempo se genera ruido y confusión para aquellos que sabemos lo que es un rol.

Por otro lado tengo la sensación que la guía cada vez tiene menos cuestiones relacionadas al desarrollo de software, posiblemente consecuencia del uso de Agile/Scrum fuera de contexto de IT. Pero dado que lo que estudiamos en mi materias es desarrollo de software, estas nuevas versiones de la Guía de Scrum, me resultan cada vez menos útiles.

Es por esto que de ahora en más ya no usaré la guía oficial de Scrum como material de estudio sino (algunos de) los siguientes materiales:

  • El artículo «Scrum Development Process» de Ken Schwaber de los años 90
  • El libro «Scrum and XP from the treches» de Henrik Kniberg
  • El resumen de Scrum de mi libro «Construcción de Software»

Prácticas técnicas para Scrum Masters

Desde 2006 vengo trabajando con equipos desarrollo que intentan trabajar en una dinámica «tipo Scrum». Sin embargo son contadas con los dedos de una mano las ocasiones que he trabajado con un Scrum Master que aporte valor al equipo desarrollo más allá de los rituales estrictos de Scrum. Lo que ocurre es que a medida que el equipo va ganando experiencia en Scrum el aporte del Scrum Master se va diluyendo si el Scrum Master se limita a aportar estrictamente desde Scrum.

Sin embargo, los equipos de desarrollo afrontan diversos desafíos que van más allá de las reglas de Scrum y de las cuestiones de programación. Muchos de esos desafíos representan oportunidades para que un Scrum Master agregue valor al equipo. Pero para eso es necesario que el Scrum Master se familiarice con algunas cuestiones de indole técnica que típicamente no forman parte del camino de formación de un Scrum Master. A esto se suma una situación cada vez más habitual: gente desempeñándose en rol de Scrum Master que no viene del mundo IT. No resulta extraño hoy en día encontrarse con equipos de desarrollo cuyo rol de Scrum Master es ocupado por una persona con formación en psicología, arte, marketing o ciencias sociales.

Es por esto que hace un tiempo, junto a Martín Alaimo, comencé a trabajar en el diseño de un entrenamiento para Scrum Masters de cara a ayudarlos adquirir conocimientos y habilidades para poder sumar valor a sus equipos de desarrollo más allá de lo que propone Scrum.

El curso está pensado para personas en el rol de Scrum Master (o facilitador de equipo en términos más generales). No es necesario tener formación el IT/programación pero sí es necesario tener experiencia de campo trabajando con un equipo de desarrollo.

El curso será en modalidad online, con 4 encuentros en vivo (uno por semana) y varias actividades semanales a lo largo de las 4 semanas del curso. Pueden encontrar más información aquí.

Scrum: en general no alcanza pero en ocasiones es incluso demasiado

Scrum es el marco de trabajo ágil más utilizado en la actualidad. Es al mismo tiempo en muchos casos el punto de partida para equipos que pretenden comenzar a trabajar de forma ágil. A simple vista Scrum parece simple, la guía oficial de Scrum tiene apenas 15 páginas y un curso típico de Scrum ronda las 16 horas.

Sin embargo esta simplicidad aparente en la teoría resulta bastante distinta en la práctica. Que sea fácil de entender no implica que resulte fácil de poner en práctica.

Scrum es un marco de trabajo para gestión y colaboración que puede utilizarse tanto en proyectos de software como también en otro tipo de proyectos. El hecho de que sea un marco de trabajo es lo que permite utilizarlo en contextos muy distintos pero implica al mismo tiempo que al utilizarlo en un escenario concreto es necesario «completar alguno huecos». Algunos de esos «huecos» son muy explícitos pues son simples parámetros, por ejemplo la duración de los sprint. Pero de esos huecos son mucho menos explícitos, por ejemplo la forma en que estimaremos y que forma tendrán nuestros items de backlog. Es así que para un equipo que desarrolla software no alcanza con Scrum en abstracto, es necesario «llenar huecos» con prácticas concretas. Un complemento que ha resultado muy efectivo es utilizar Scrum con Extreme Programming(XP), o sea, «llenar los huecos» de Scrum con las prácticas de XP. XP es una propuesta de trabajo concreta para desarrollo de software y como tal contempla tanto cuestiones de gestión/colaboración como cuestiones de programación/prueba/despliegue, etc.

Pero por otro lado, para un equipo que viene de trabajar en una dinámica desordenada de «code-and-fix» meterse de lleno con Scrum puede resultar demasiado. Pasar de la nada a iteraciones time-boxed, gestionar explícitamente el backlog e incorporar todas las ceremonias de un día para otro, no me parece un apropiado. Es así que para esos escenarios yo suelo proponer una adopción gradual de Scrum y en ese sentido el mi recomendación es comenzar haciendo retrospectivas. La retrospectiva tiene la particularidad de ser una práctica sin dependencias, o sea, uno puede hacer retrospectivas sin utilizar ninguna otra práctica de Scrum. Al mismo tiempo la retrospectiva debería guiarnos en nuestro proceso de mejora. Dicha mejora podría llevarnos a incorporar otras prácticas de Scrum o no, tal vez podríamos terminar incorporando otras prácticas. O sea, tal vez arrancamos con la intención de hacer Scrum pero terminamos haciendo algo distinto. Pero esto no está mal, porque Scrum no debería ser un fin en sí mismo, sino un medio para lograr un fin de nuestro equipo/organización que en términos de Agile es agregar valor.

Sobre Scrum Masters & Project Management

Sobre Scrum Masters & Project Management

Continuando con la cuestión de planteada previamente (el sospechoso rol del Scrum Master…) sobre las responsabilidades extra que suelen recaer en aquellas personas que ocupan el rol de Scrum Master en las empresas de desarrollo de Software, hoy quiero referirme puntualmente al Project Management.

Antes que nada hago algunas aclaraciones sobre Management según Agile:

  1. El manifiesto ágil dice explícitamente que el equipo es auto-organizado, lo cual implica que la estrategia de management es distinta a la tradicional (muchas veces taylorista) y que varias tareas de management recaerán en el propio equipo. No está completamente claro cuales de las tareas de management toma el equipo y cuales caen fuera, eso habilita a que cada equipo/organización lo maneje de forma distinta.
  2. Más allá de que el equipo sea auto-organizado es razonable que el equipo tenga que interfacear/reportar/coordinar en algún punto con la organización a la cual pertenece. Una cuestión clave aquí es como de implementa esa interface respetando la auto-organización del equipo.

Más allá de de estas cuestiones conceptuales lo que suelo encontrarme muy frecuentemente en empresas de desarrollo de software es que una misma persona concentra el rol de Scrum Master y también varias tareas de management. En particular hay 2 escenarios muy comunes: 1) Scrum Masters haciendo Project Management y 2) Project Managers haciendo de Scrum Masters.

1) Sobre Project Managers haciendo de Scrum Masters

Esta es gente viene de una experiencia de Project Management y que ahora que «el mundo es Agile» se metió en Scrum y adoptó el rol de Scrum Master. Como ya tiene una experiencia en management no le resulta difícil tomar las tareas de management que le pide la organización. El gran desafío aquí es que esta persona pueda dejar de lado algunas practicas de management porque está trabajando con un equipo auto-organizado. Situaciones típicas en este escenario son:

  • La Daily Standup convertida en un reporte de estado
  • Ver al Scrum Master asignando tareas
  • Tracking y reporte en término de horas
  • Micro-management
  • Percepción del Scrum Master como Jefe del equipo

2) Sobre Scrum Master haciendo Management

En este escenario tenemos gente que se formó/entrenó como Scrum Master y que adicionalmente se encuentra con que debe cubrir tareas de management para las cuales no tiene formación. En este escenario estoy hablando de personas que llegan a ser Scrum Master luego de haberse desempañado como Developer, Tester o algún otro rol pero no Project Managers. En estos casos, si el equipo no tiene la experiencia suficiente para auto-organizarse vemos sufrir al proyecto: no hay métricas, el equipo no tiene una velocidad de delivery predecible ni estable, el cliente ve mucho post-its que en lugar de ayudar a la gestión generan una sensación de desorden y extrema informalidad, la gestión de riesgos es bastante endeble (si es que se hace), y el equipo no tiene la habilidad/capacidad de manejar imprevistos de ningún tipo, etc.

Como ya mencioné no me convence la estrategia de concentrar las tareas de management y Scrum Master en una misma persona, pero si alguna organización piensa hacerlo, espero que al menos tomen la precaución de asegurarse que esa persona que ocupe el doble rol tenga la apropiada formación tanto para las tareas de Scrum Master como también para las tareas de Project Management.

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

Una situación que veo recurrentemente en las empresas de desarrollo software para terceros es que conforman sus equipos poniendo una persona en el rol de Scrum Master y asignandole también algunas otras tareas. Esto genera que en términos generales que la persona en el rol de Scrum Master termine concentrando 3 grupos de tareas:

  • a) tareas de facilitación propias del Scrum Master que podemos resumir como ayudar a que el equipo siga la propuesta de proceso de Scrum, removiendo potenciales impedimentos, etc
  • b) tareas típicas de la gestión del proyecto desde la perspectiva de la software factory como ser: seguimiento del presupuesto, planificación del equipo a mediano/largo plazo, seguimiento de la facturación, gestión de riesgos, etc. Aclaro aquí una cuestión importante: la gestión de presupuesto y del plan son responsabilidades del Producto Owner cuando vemos el proyecto desde la perspectiva de la organización que es dueña del producto, pero estas cuestiones también están presentes desde la perspectiva del proyecto de la software factory.
  • c) tareas de gestión internas requeridas por la organización(software factory) respecto de los miembros del equipo como ser evaluaciones de desempeño, coordinación de licencias, etc.

Lo que me resulta sospecho es la concentración de estos tres grupos de tareas en un misma persona porque me parece que puede haber cierto conflicto. Un caso puntual a modo de ejemplo: se supone que el Scrum Master debería generar un contexto de seguridad para que el equipo y sus miembros puedan hablar en confianza sobre sus dificultades, equivocaciones, etc, pero al mismo tiempo esa persona Scrum Master tiene que evaluar el desempeño de los miembros del equipo ¿cuan seguro puede sentirse un miembro de equipo para hablar de sus equivocaciones cuando ese Scrum Master es también la persona que evalúa su desempeño?

Lo que yo recomendaría en estos escenarios es tener dos personas distintas: una con el rol de Scrum Master (que estaría presente en el día a día del proyecto ) y otra con el rol de gestor de proyecto (con una presencia mucho más esporádica).