jueves, 17 de noviembre de 2011

Un buen SCRUM Master / A good SCRUM Master



Mucho se habla (sobretodo en los procesos de selección) sobre las cualidades que un buen SCRUM Master debería tener, aparte de los conocimientos técnicos.

Es un tema de vital importancia y como tal, se discute también en trainings, cursos de certificación y en muchos foros. Porque, como en todos los trabajos, a veces son las "soft skills" las más difíciles de evaluar. Cuando contratamos a un desarrollador de software, tenemos claro las habilidades técnicas que requerimos (Java, C++, SQL, lenguajes de scripting, etc...), pero a la hora de identificar las “soft skills”, muchas veces nos limitamos a listar una serie más o menos estándar, porque tampoco somos capaces de darles la justa importancia: Queremos a alguien con capacidad de comunicación, entusiasta y "team player". Seguro que las habéis leído en las ofertas miles de veces.

En el caso de un SCRUM Master, estas "soft skills" son aún más importantes si cabe. Precisamente son sus "soft skills" las que le harán tener éxito. Si el SCRUM Master ha sido en un pasado (o es todavía) jefe de proyecto, muchas de las cualidades que necesitará ya las ha tenido que poner en práctica. Pero si el SCRUM Master es un técnico, la cosa se complica.

Según mi experiencia, las cualidades que van a hacer que un SCRUM Master tenga éxito son:
  • Ser un buen comunicador.

    La comunicación no es una parte importante... ¡es esencial! Se calcula que un 90% del tiempo de un jefe de proyecto es la comunicación. No conozco datos sobre qué % aproximadamente pasa un SCRUM Master comunicando (cuando ejerce como tal, no cuando hace otras tareas), pero me atreviría a decir que es un porcentaje similar.

  • Ser "bueno" con la gente.

    Puesto que esta definición es demasiado amplia y abstracta, me concentraré en los rasgos que más importantes me parecen: Ser paciente, ser capaz de entender que cada persona es diferente, saber tratar con diferentes caracteres, saber escuchar y saber razonar. A veces se dice que ser SCRUM Master es un poco como ser el padre/madre del grupo. Y para los que tienen background de jefes de proyecto, este símil no les parecerá extravagante.

  • Conocer bien la teoría de SCRUM.

    Sí, es importante. Por eso es recomendable que quien ejerza de SCRUM Master esté certificado o haya atendido alguna formación. Por ejemplo, es básico conocer y ser capaz de explicar la importancia del SCRUM diario. Si tenemos un miembro del equipo que sistemáticamente no atiende el SCRUM diario, no dejarlo pasar ("lo importante es que saca el trabajo adelante"), sino hacer hincapié, razonando, en que ciertas "reglas" de SCRUM hay que seguirlas. Por algo hay pocas.

  • Y finalmente, ser expeditivo, o en otras palabras, ser bueno resolviendo problemas.

    Tener esa capacidad de "arreglar las cosas", y no me refiero a arreglar descalabros técnicos, sino situaciones comprometidas, obstáculos, dificultades de todo tipo. No en vano, una de las tareas más habituales del SCRUM Master (que se cita y se practica al obtener la certificación) es la de "quitar obstáculos" (en inglés "remove blockers / remove impediments"). Por cierto, que en este ámbito, tener una "lista de obstáculos pública" muchas veces ayuda. Da visibilidad.

viernes, 21 de octubre de 2011

Estimaciones / Estimations



Es de sobras conocido que la estimación es una de las áreas más problemáticas en todo proyecto de software. Pero en esta entrada no quiero centrarme en los problemas más habituales cuando estimamos (cómo conseguir estimaciones lo más cerca de la realidad posible), sino en un punto directamente relacionado con SCRUM. Un punto en el que he visto, muchas veces, que hay confusión.

Por si fuera poco con los problemas intrínsecos de la estimación, cuando estamos empezando a trabajar con SCRUM surgen dudas, que yo llamo "logísticas", sobre cómo vamos a estimar. ¿En horas? ¿En puntos de historia? ¿Qué relación hay entre las unidades de estimación y estimar en tareas o historias de usuario?

Voy a explicar mi punto de vista, basado en mi experiencia. Pero quiero dejar claro que no hay un método estándar. Es cierto que algunas herramientas (estoy pensando en TFS) pueden predeterminar cómo entrar las estimaciones (por ejemplo en horas), pero no hay una fórmula mágica. Y esto es bueno, porque es flexible.

SCRUM te da la posibilidad de adaptar cómo estimamos a nuestra necesidad. En general, las historias de usuario se estiman en puntos de esfuerzo mientras que las tareas en horas.

Las historias de usuario forman el Product Backlog. Del Product Backlog, las escogeremos para nuestro Sprint (el Product Backlog está ordenado por prioridades del negocio) y compondremos con él el Sprint Backlog.

En la reunión de Sprint Kickoff, analizaremos las historias de usuario y refinaremos su estimación. Aquí es donde yo suelo descomponer las historias de usuario en tareas y asignar horas.

Es decir:
  • Las estimaciones de las historias de usuario son más globales y las utilizo para dar estimaciones al negocio. Es muy útil en el caso que el negocio necesite tener buenas estimaciones del proyecto en sí: cuando, por ejemplo, es crítico cumplir plazos.

  • Las estimaciones en horas por tareas las utilizaré para controlar el Sprint, con el Burndown Chart.
Esta es una forma de hacerlo, pero no la única. Por ejemplo, en un proyecto que realicé tuvimos suficiente con las estimaciones de historias de usuario, puesto que eran pequeñas, (de 1 o 2 días de duración), y no valía la pena dividirlas en tareas. Como en ese caso tampoco utilizábamos ninguna "herramienta sofisticada" para llevar el tracking del proyecto (nuestro Sprint Backlog era un fichero excel y nuestro Burndown Chart, un gráfico derivado de dicho excel), pudimos cambiar nuestro "modus operandi" y trabajar con puntos de esfuerzo sin mucha complicación.

En general es importante entender los conceptos básicos (historias de usuario, tareas, etc.), pero es más importante aún saber adaptarlas a tu entorno (necesidades del negocio, equipo, etc.). Y, muchas veces, cambiar: A veces el equipo puede tener dificultad estimando en puntos de esfuerzo por estar muy habituado a estimar en horas, mientras que otras veces, al cabo de poco, estimar en puntos de esfuerzo resultará más afinado.

lunes, 1 de agosto de 2011

Iteraciones / Iterations



Cualquier persona que empiece a leer sobre SCRUM se dará cuenta de la importancia de que las iteraciones (o sprints) tengan una duración determinada a lo largo de un proyecto. Fijar la duración de los sprints es uno de los pocos principios de SCRUM. Por ejemplo, no se puede variar, a medio proyecto, los sprints de 2 a 3 semanas, y después a 2 de nuevo. Crea confusión en el cliente y en el mismo equipo, y no ayuda a establecer un buen ritmo de trabajo.

Ahora bien, algo más complicado es decidir cuál es la mejor duración en cada caso.

Cuando me preguntan qué duración es la adecuada para una iteración SCRUM, siempre respondo que “depende del caso”. Es una respuesta imprecisa, con lo que quiero aprovechar este post para dar mis razones para no aconsejar una duración estándar de un sprint (sin conocer los detalles del proyecto).

Cuando estamos implantando SCRUM por primera vez, mi sugerencia (¡para esto y para tantas otras cosas!) es tomarnos nuestro tiempo entendiendo el entorno. Llegar como consultor expertísimo en SCRUM e intentar aplicar el proceso que te ha funcionado en otras ocasiones a un nuevo “ecosistema” es una receta para el fracaso. Muchas veces, la implantación de SCRUM se servirá de un proyecto prototipo. Considero aceptable variar la duración del sprint después de dicho prototipo (¿para qué nos sirven los proyectos prototipos si no es para probar?). Pero, cuando se haga un despliegue de la metodología a nivel departamental o de toda la compañía (o sea, incluyendo múltiples proyectos), sería adecuado mantener sprints más o menos similares, porque ayuda a una mejor comprensión a nivel organizativo de SCRUM y de cuando esperar resultados.

En general, se debería tener en cuenta:
  • Procesos organizativos y entorno

    • ¿Es un producto interno o para un cliente externo?

    • ¿Qué procesos de autorización existen para ponerlo en producción? Por ejemplo, los complicados procesos que pueden existir en un entorno bancario o en según qué clientes externos, incluyendo departamentos de operaciones, etc.

  • Disponibilidad del cliente

    • Número de usuarios

    • Necesidades de formación cada vez que se lanza una nueva release

    • Localización / disponibilidad en general

  • Naturaleza de la solución (producto realizado)

    • ¿Cuán urgente es la necesidad de nuevas funcionalidades?

  • Madurez del equipo de desarrollo

    • Conocimiento de SCRUM, cómo de multidisciplinares sean sus miembros, etc.

    • ¿Cuál es la capacidad de utilización / reacción / tolerancia de los usuarios a las nuevas iteraciones?

En resumen, no es lo mismo realizar un producto para un grupo de usuarios internos que lo conozcan bien y sólo necesiten una mínima formación que no, por ejemplo, una release de software bancario para un cliente externo en el que son necesarios un par de días de pruebas más formación y documentación para los usuarios, etc. En el primer caso se podría pensar en iteraciones de incluso 1 semana, en el segundo, de 1 mes. Y según mi opinión, ninguna sería más correcta que la otra.

jueves, 30 de junio de 2011

Introducción a Agile Testing / Introduction to Agile Testing



El tema de cómo testear software siempre levanta mucha polémica, pero cuando entramos en un desarrollo Agile, hay además bastante confusión. La pregunta que he escuchado en más ocasiones es la de: ¿Cómo vamos a involucrar a un testeador desde un principio, si el desarrollo no está acabado?

Para resolver esta duda, hay que empezar mencionando que Agile es una metodología que pone mucho énfasis en la calidad. La calidad entendida no sólo como calidad del código (sin bugs, bien diseñado, etc.) sino como proceso global: Lo desarrollado es útil al negocio, responde a las expectativas cambiantes, se pone en producción en iteraciones relativamente cortas, etc.

Por eso, porque la calidad es algo que se mantiene en todo momento, un testeador se involucra desde el principio de la iteración. No se pone a trabajar sólo los dos últimos días del ciclo (como he oído en algunas ocasiones).

En general, un testeador:
  • Colabora con el Product Owner para definir las condiciones de aceptación.

    • Muchas veces, en esta fase se descubren "puntos oscuros" que ni el Product Owner tiene del todo claro. ¡Considero que esta parte es vital!

    • El testeador se encarga de que las user stories sean claras y tengan sentido. Es en esta parte donde cobra importancia lo mencionado antes de la calidad no sólo entendida como código bien escrito.

  • Crea los planes de test, los casos de test y los planes de regresión, a partir de dichas condiciones de aceptación.

  • Se encarga de los entornos de test y del proceso de build (y muchas veces de los repositorios de código).

  • Se encarga de la automatización del test.

  • Testea.

  • Informa de los resultados para estadísticas, análisis, etc. ¡Los testeadores suelen ser una parte importante de las sprint retrospective!

Por supuesto, hay múltiples variaciones, dependiendo del perfil de los testeadores con los que se cuente, pero los puntos mencionados antes son los que yo considero básicos cuando se habla de test en un entorno Agile.

miércoles, 23 de marzo de 2011

Introduciendo SCRUM / Introducing SCRUM



Hace poco me pidieron crear un plan para introducir una metodología ágil (SCRUM) a nivel de toda una organización. Puesto que resumí en un plan de 5 pasos mis experiencias (y las mejores prácticas de otros autores), quiero compartirlo en el blog por si a alguien le resulta útil.

Así que, ¿quieres cambiar tu organización? Si eres un agile coach o evangelist, yo te sugeriría...

1) Estudia la situación
  • Identifica quién está a favor y quién en contra: ¿Quién quiere el cambio? Y, por otra parte... ¿qué es lo que se quiere cambiar? A veces, algunas personas sólo quieren dejar de hacer "tanta documentación", otros quieren "una gestión más libre", mientras que otros quieren... todo lo contrario!

  • Establece espacios abiertos, cuestionarios, foros. En este punto, toda la información que se obtenga es extremadamente valiosa.

  • Obtén ayuda! Lo ideal es conseguir consultores externos (estos consultores no tienen miedo a ser despedidos y suelen decir lo que piensan!) y buenos agile trainers (a veces, los consultores serán los trainers!). Aportarán experiencia (ellos ya han estado allí antes) y darán confianza al equipo cuando tenga problemas.

  • Establece las expectativas correctas: Seas tú o un consultor externo, se necesitará algún tiempo para analizar la situación y diseñar la mejor estrategia. No se pueden cambiar las cosas desde el primer minuto!

2) Empieza con un piloto
  • Elije el equipo adecuado para hacer el piloto. No escojas un equipo que ofrezca resistencia o un equipo con miedo al cambio. Elije un equipo que haga del piloto una historia de éxito. La idea del piloto es convencer al resto de la organización que SCRUM funciona! El primer paso (análisis) te ayudará a elegir el equipo adecuado.

3) Comunica y capacita

Establece un proceso de comunicación y formación para otros equipos desde el principio.

Comunicación:
  • Haz la buena información más visible que la mala información, con actualizaciones por correo electrónico, presentaciones, etc. Da a conocer "quick wins" y pequeñas victorias!

Formación:
  • Prepara formaciones basadas en historias de éxito de lo que está ya ocurriendo. La idea es que los otros equipos participen en el cambio y quieran empezar con SCRUM.

  • A veces, además de la formación de los equipos, es útil designar a "champions" dentro de cada equipo, personas que te ayudarán a hacer el cambio.

  • Forma a los altos directivos y mandos medios por separado. Realizan funciones distintas y tienen problemas muy diferentes!

Equipo SCRUM de introducción:
  • Algunos autores abogan por un equipo de gerentes diseñado para "eliminar los obstáculos" en el proceso mismo. Yo estoy a favor. Si estamos llevando a cabo un cambio en toda la organización, tendremos que quitar "blockers" por el camino, así que, ¿por qué no utilizar el paradigma de SCRUM a un nivel superior?

4) Despliega SCRUM a otros equipos gradualmente
  • En primer lugar, identifica la velocidad correcta de despliegue (por ejemplo, cuantos equipos por mes, etc)

  • Poco a poco ve desplegando SCRUM a los otros equipos, en consonancia con el programa de comunicación y de formación mencionados en el paso 3.

  • No te olvides del departamento técnico! A menudo es el punto de fallo de estas implementaciones!

5) Comunicación final
  • A medida que se acerca el final del despliegue a nivel organizativo... prepara bien la comunicación final de resultados: Ha sido difícil, lo que queda seguirá siendo difícil (SCRUM es un cambio constante!), pero los buenos resultados superarán los problemas!

lunes, 14 de marzo de 2011

Una Solución pre-Scrumban (II) / A pre-Scrumban Solution (II)



Como mencioné en el anterior post, voy a hablar un poco más del método pre-SCRUMBAN que he utilizado en proyectos anteriores.

Una variación era la de tener solamente 1 o 2 miembros de equipo con tareas Must y Should. Es decir, tener sólo a máximo un par de miembros como responsables de solucionar las incidencias de producción y otros problemas durante un Sprint. Normalmente, en nuestro equipo teníamos para ello a un perfil de desarrollador y a otro de testeador. A estos perfiles les llamábamos "Production Incidents Champion". Con el nombre, resaltábamos que sólo se solucionaban problemas de producción; es decir, el tipo de problemas en los que el tiempo de respuesta no puede ser de un Sprint y pico. El tiempo que se podía pasar en estas incidencias, como expliqué en el anterior post, venía predefinido con el número de story points de desarrollo que poníamos como Should.

Algunas ventajas de hacerlo así eran:
  • Seguíamos con la filosofía SCRUM de tener equipos multidisciplinares, pues durante el Sprint al que le tocaba ser "Champion" debía solucionar las incidencias del producto, hablando con quien fuese necesario si no tenía los conocimientos suficientes.
  • No "quemábamos" al equipo. Según mi experiencia, a la gente no le gusta mucho el rol de "Production Incidents Champion". Algo bastante lógico, por otra parte: generalmente ¡significa pelearse con problemas de solución difícil y urgencia muy alta! Rotando la figura entre los miembros del equipo, la carga se hacía más llevadera.
  • Se distraía menos la dinámica de desarrollo del grupo en general. La mayoría continuaban trabajando en nuevos desarrollos "olvidándose" de los incidentes de producción durante los Sprints en los que no estaban nominados como "Production Incidents Champion".
Otro "refinamiento" del método consistía, después de varios Sprints utilizándolo, medir el tiempo real que se pasó resolviendo incidencias, hacer estadísticas y después ajustar con ellas el tiempo de soporte que se acordaba para un Sprint.

Idealmente, el tiempo medio debía ser menor al tiempo máximo que se había destinado = el número de story points marcados como Should. Se habían dado algunos casos de incidencias muy peliagudas, de difícil resolución, que se habían "comido" algunas horas de Must, pero en general el "Production Incidents Champion" realizaba todos sus Must (su Commitment), algunos Shoulds y resolvía alguna incidencia.

Finalmente, otra variación con la que jugamos era la de introducir Coulds. Las tareas Could eran una alternativa a "tomar las siguientes en el Product Backlog", por si algún miembro del equipo acababa su trabajo antes de la finalización del Sprint. No suponían una gran ventaja respecto al método tradicional, solamente que ya las estimábamos y asignábamos de antemano (planning poker).

jueves, 17 de febrero de 2011

Una Solución pre-Scrumban / A pre-Scrumban Solution



Hace unos meses, leyendo las aportaciones de la comunidad española que trabaja con prácticas ágiles, me topé por primera vez con el término “Scrumban”. A partir de allí me leí el estupendo paper de Kanban vs SCRUM, y me alegré al saber que compartía problemas con ellos y podía leer sobre sus soluciones.

En este post, voy a centrarme en un problema que me he encontrado en el pasado y en una solución que adopté, y en siguientes posts voy a estudiar cómo se relacionan con las tendencias Scrumban que mis compañeros de agilismo están explorando.

En proyectos en los que he implantado SCRUM, había una serie de problemas recurrentes. Uno de estos problemas era qué hacer cuando el equipo de desarrollo también realiza tareas de soporte. Muchas veces, el equipo de desarrollo no sólo tiene que desarrollar nuevas funcionalidades, sino también arreglar bugs y realizar soporte puro y duro. En compañías grandes, los equipos suelen estar diferenciados, pero cuando se trata de empresas pequeñas, los desarrolladores tienen que contestar el teléfono y “apagar fuegos”.

El problema con SCRUM es que no permite incluir tareas nuevas cuando un Sprint ha empezado. Esto no es una restricción caprichosa, pues tiene un buen fundamento: hay que acotar el nivel de cambio dentro de un equipo para poder entregar el paquete de software prometido a final del Sprint. Si estamos cambiando continuamente el alcance de un Sprint, los conceptos de velocidad y compromiso por parte del equipo a entregar lo acordado para ese Sprint, se pierden. ¡No vamos a comprometernos a entregar algo que no sabemos qué es!

Pero si el equipo de software también tiene que ofrecer soporte... ¿cómo podemos decirle a un cliente (usuario, manager…) que tiene que esperar a que el Sprint se acabe para solucionar el problema? Aunque el problema sea urgente, tendrá que esperar a que el Sprint acabe, se priorice la solución en la pila de producto (por el Product Owner) y finalmente, se entregue al final del Sprint siguiente (supongo que, como el problema era urgente, el Product Owner lo prioriza). En el mejor caso, si el problema sucede el último día de un Sprint, el tiempo de respuesta seria la duración del siguiente. Y en el peor, si sucede el primer día del Sprint, dos veces esta duración. E incluso podríamos calcular un tiempo medio de respuesta, haciendo estadísticas de cuando suceden los problemas durante un Sprint en nuestra compañía, calculando su distribución temporal y obtener un tiempo medio de finalización del Sprint en curso (al que sumaríamos después la duración del siguiente). Sea como sea, esto no funciona si el problema es realmente urgente y se debe solucionar.

En un pasado, yo utilicé un método “híbrido”: bajábamos la velocidad de equipo de forma artificial para dejar un buffer para “soporte”. Hay que recordar que en SCRUM, los equipos son multifuncionales y por lo tanto todos los miembros del equipo podían realizar soporte. Definíamos una serie de tareas del Product Backlog como “opcionales”, utilizando una versión reducida del Moscow Method:

- Tareas M “Must”: conformaban el Sprint, el compromiso del equipo.
- Tareas S “Should”: estas tareas se realizarían si no había tareas de soporte. En caso de que surgieran dichas tareas, las tareas “Should” podrían descartarse. No formaban, a priori, parte del compromiso del equipo con el cliente.

Este método no es perfecto, pues también limita la capacidad de soporte del equipo, pero dicha capacidad máxima de soporte era algo que se acordaba con los clientes/usuarios. Por ejemplo, “el equipo dedicará un máximo de 20% a soporte”. Entonces “Tareas Must” = Compromiso = Velocidad - 20%. Si no se realizaban tareas de soporte, el equipo debía realizar las tareas “Must” y “Should”. Las soluciones de bugs se ponían en producción cuando el Sprint finalizaba, con lo que el tiempo de respuesta se reducía.

lunes, 31 de enero de 2011

Miedo a la libertad / Fear of freedom



El otro día oí a una psicóloga explicar que la historia de la humanidad, desde un punto de vista sociológico, viene marcada por alternancias de movimientos que, respectivamente, reclaman más libertad del pueblo o “piden” más control. Después de épocas en las que florecen las libertades, el género humano parece decantarse por regímenes dictatoriales. La explicación ofrecida me llamó la atención: ante una libertad a la que no estamos acostumbrados, sentimos una necesidad de control, un alivio al dejar que se tomen las decisiones por nosotros. La responsabilidad asociada a nuestra libertad nos abruma.

Pensé en un problema que aparece a veces en los equipos en los que se introduce una metodología ágil. El equipo experimenta una sensación de más libertad y de más responsabilidad que en un típico grupo “jerárquico” donde el líder técnico o el gestor de proyecto te dicen qué hacer y cómo hacerlo en todo momento. Equipos auto-gestionados. ¿Todos contentos? Al contrario.

Muchas veces los miembros del equipo se asustan. No se sienten cómodos, no sólo con el cambio (¡el miedo al cambio podría y seguramente inspirará otra entrada!), sino también a la novedosa libertad. Escuchar a la psicóloga hablar del miedo a la libertad a nivel sociedad me hizo darme cuenta de que es un miedo fundado, racional, que no debe ser despreciado.

Cuando se trata de miedos muy arraigados en la consciencia de cada uno, pretender que con un par de frases en una presentación de equipo se van a solucionar es un gran error (error que, sin embargo, he visto muchas veces). “Vamos a ser todos ágiles – ¡veréis qué bien!”. No; hay que hacer un esfuerzo continuado, de seguimiento, de cada miembro del equipo. Ayudarles a que vayan tomando responsabilidades de forma progresiva. Cada persona es un mundo y uno de los problemas más habituales es obviar esto por falta de tiempo y tratar al equipo como un “todo” en la delicada materia de cambiar la forma de trabajar.

Una técnica que funciona bien es tener con cierta regularidad reuniones one-to-one con cada miembro del equipo. No vale ahorrárnoslas porque todo parece ir bien o por demasiado volumen de trabajo; y sobre todo en las primeras etapas del cambio. Si el SCRUM Master es el gestor del proyecto (o sea, el jefe inmediato), este caso es ideal, porque ya se suelen tener reuniones one-to-one. Además, tendrá la autoridad para tomar decisiones si llegan a ser necesarias.

Pero todos sabemos que el SCRUM Master no siempre es el gestor del proyecto, es más, muchas veces es aconsejable que no lo sea. En este caso, debería hacerse otra reunión de frecuencia variable con el SCRUM Master, porque en el típico one-to-one con el jefe el SCRUM Master quedará fuera. Una reunión para que el SCRUM Master pueda entender, persona a persona, sus miedos respecto al cambio, las situaciones particulares en las que se sintieron demasiado presionados, etc.

Finalmente, mencionar que otro problema importante con el que me he topado al introducir SCRUM es la presión del grupo. El típico ejemplo: ¡todo el mundo parece tan encantado de trabajar ágilmente! Algún miembro tiene sus reticencias, pero no se atreve a hacerlas públicas durante una reunión con todo el equipo por la famosísima presión del grupo o peer pressure: “No quiero que me tachen de waterfall”. Otro buen ejemplo de porqué las reuniones one-to-one son tan importantes es porque en estas conversaciones es cuando se desenmascaran los miedos de cada uno y se pueden solucionar los problemas.