viernes, 25 de marzo de 2016

¿Qué tal easyBacklog como software para gestionar la pila de producto y los sprints?

Gertrudis, una asistente a uno de mis cursos de ingeniería de requisitos ágiles, entregó uno de los ejercicios en que hay que escribir 10 historias de usuario en forma de un documento obtenido por easyBacklog. Me encantó la forma en que lo hizo y le eché un vistazo a ese software y descubrí una opción simple y completa, gratuita y on-line, para gestionar de forma virtual una pila de producto y ejecutarla en sprints.

En su página lo definen como:
  • easyBacklog IS: An intuitive time saving backlog management tool for Agile practitioners working in or with agencies.
  • easyBacklog is NOT: Yet another all purpose project management, Agile or collaboration tool for teams.
Cómo se puede observar en la pantalla de configuración pone énfasis en la estimación de historias, información clave para que el Propietario del Producto pueda hacer una buena gestión de la pila de producto.
easyBacklog - Configuración
Lo que no me gusta:
Lo que me gusta:
easyBacklog - La pila de producto
easyBacklog - Pilas de producto y sprint
easyBacklog - Los gráficos
easyBacklog es un software mínimo para la gestión virtual de un proyecto Scrum. Desde mi perspectiva, y en consonancia con el primer valor del Manifiesto Ágil "Individuos e interacciones sobre procesos y herramientas" pienso que una herramienta minimalista, como esta, es la mejor opción para no quitar el foco de lo que importa, las personas.

Mis agradecimientos a Gertrudis por descubrirme este software.

domingo, 20 de marzo de 2016

¿Cómo generar un contexto compartido para una buena comunicación en un proyecto?

Incepción Ágil, el dado a nuestro favor
El 90% de proyectos fallidos ocurren por la falta de comunicación, y el 90% de proyectos exitosos lo son por las personas que han participado. Por tanto generar un contexto compartido, para que los comprometidos e involucrados se comuniquen mejor a lo largo de la ejecución del proyecto, es apostar por el éxito del mismo. Desde la Agilidad Jonathan Rasmusson nos propone la Incepción Ágil en su libro "The Agile Samurai" para lograr este fin.

Tal como define José Manuel Beas en su artículo "La Incepción Ágil, es un conjunto de dinámicas orientadas a enfocar a todas las personas involucradas en un proyecto hacia un mismo objetivo, reduciendo muchas de las incertidumbres, ayudando a explicitar los riesgos más evidentes y poniendo en común las expectativas de todos".

Por tanto se trata de una técnica de conceptualización para emplear en el proceso de iniciación de un proyecto y así aumentar la probabilidad de éxito del producto resultante, con el objetivo de construir una visión completa sobre el concepto de producto, una visión compartida y comprendida de idéntica forma por los comprometidos, involucrados e interesados, de manera que se eviten los sesgos personales. Tal como recoge Alfons Corrales en su artículo sobre la Incepción Ágil, la utilidad de las técnicas viene fundamentada por los siguientes aspectos:
  • Distintos interesados tienen distintos intereses y necesidades sobre un producto o proyecto concretos. Generando la conversación adecuada entre ellos emergerán aspectos que de otra forma podrían haber quedado descuidados.
  • Hay requerimientos y necesidades difíciles de explicitar. Hay necesidades que a veces son difíciles de comunicar, incluso porque a veces no somos conscientes de las mismas. Mediante técnicas como el incepción podemos lograr que emerjan a la superficie.
  • El proceso de comunicación suele ser imperfecto. Con una misma frase, dos personas pueden entender cosas completamente distintas. Es necesario trabajar en profundidad el concepto de un proyecto para asegurar una visión y comprensión común.
  • La Incepción Ágil permite poner en valor nuestro expertise. Se trata de una oportunidad única para aportar valor añadido a nuestros clientes y mejorar la calidad de las relaciones, consiguiendo que el producto se centre en lo que el cliente necesita en lugar de en lo que dice que quiere.
La práctica más popular para generar este contexto común y comenzar a definir la pila de producto es el taller colaborativo Agile Inception Deck. Viene a ser una baraja con 10 actividades, que son opcionales e incluso se pueden sustituir por otras actividades con el mismo objetivo. Han de estar presentes todas las personas comprometidas e involucradas para considerar las 10 preguntas y llegar a la verdadera esencia del producto, y definir y comunicar esa visión a todos los miembros del equipo e interesados.

1. ¿Por qué estamos aquí?
Es un recordatorio del por qué estamos aquí, quiénes son nuestros clientes, y porqué hemos decidido hacer el proyecto.

2. Crear una visión general, un elevator pitch
Si tuviéramos menos de dos minutos y dos frases para describir nuestro proyecto, ¿qué diríamos?

3. Diseñar la caja del producto
Si tuviéramos que diseñar un anuncio de nuestro producto o servicio para una revista y que resaltara al hojearla, ¿qué diría? ¿atraería para comprar?

4. Crear una lista de lo que NO es
Tenemos una idea clara acerca de lo que vamos a hacer en el proyecto, ahora vamos a tratar de ser más claros y ver lo que no vamos a hacer.

5. Conocer a la comunidad
La comunidad de nuestro proyecto es siempre más grande de lo que pensamos...

6. Mostrar la solución
Pensemos en un alto nivel de la arquitectura y en las tecnologías que vamos a utilizar.

7. ¿Qué nos impide dormir?
Hay mil cosas que podrían ser erróneas en nuestros proyectos, algunas las podemos gestionar, otras no. Esta actividad trata de asegurarnos que identificamos los riesgos más importantes.

8. Estimar el tamaño
¿Es un proyecto de tres, seis o nueve meses?

9. Compensar las decisiones
Todos los proyectos tienen que estar balanceados en el tiempo, el dinero, el alcance y la calidad. ¿Cuál es de la mayor y de la menor importancia en este momento?

10. ¿Cuánto cuesta?
Hay dos cosas que preocupan a nuestros clientes¿Cuánto cuesta? ¿Cuánto tiempo vamos a necesitar?
Mapa visual del Inception Desk, para verlo al detalle máximo clickar encima de imagen - cortesía de Gertrudis :-)

sábado, 5 de marzo de 2016

¿Cómo resolver el conflicto cuando dos miembros de equipo aportan cada uno una solución?

Resolución de conflictos
A veces ocurren reuniones de refinamiento y de planificación de sprint en las que dos miembros de equipo defienden acaloradamente su solución a un problema o requisito. Si el Scrum Master no interviene y no modera la discusión esta puede escalar a un "y yo más..."  y menguar el entorno que propicia y estimula la generación de buenas ideas y soluciones, y en definitiva debilitar al equipo como unidad.

Recientemente estuve haciendo co-training con Marcos Garrido en una clase de CSM en la que aprendí esta dinámica, que de forma simple y elegante ayuda a resolver conflictos, y que pretendo describir en este post.

La dinámica se basa en tablero muy simple, como el de la foto de la izquierda:
  • En la cabecera se ponen las soluciones, en este caso A y B, y en los encabezados de fila, en la primera, las ventajas (ADV), y la segunda, las desventajas (DISAD).
  • El facilitador pregunta y anota en la primera fila las ventajas que cada uno de los contrincantes ve en la solución del otro.
  • De modo similar el facilitador pregunta y anota en la segunda fila las desventajas que cada contrincante ve en su propia solución.
Acto seguido el equipo vota con un punto la solución que le parece más idónea, pero no importará únicamente la naturaleza de la solución, en el ejemplo el equipo votará con mucha probabilidad la solución A porque piensan que quién ideó B no colaborará igual, y saben que justamente la colaboración hace la diferencia entre una solución buena y una excelente.

martes, 1 de marzo de 2016

¿Puede trabajar cualquier equipo con Scrum?

Estuve hablando con un miembro de un equipo clásico que se interesó por saber qué era eso de Scrum. El concepto de equipo que se siente propiedad colectiva de un software no le convenció, decía que si trabajas mucho tiempo con el mismo equipo te acabas acomodando y pierdes la motivación. Por otro lado él estaba encantado con saltar de cliente en cliente, de proyecto en proyecto, decía que el hecho de variar de entorno le estimulaba y le motivaba, y que rompía con el inevitable sabor boca del proyecto anterior entregado fuera de plazo. Pensando en una compañía sin directivos ágiles que velen por un personal motivado, llegué a comprender su perspectiva, así que me animé a escribir este post que dibuja lo que significa para un miembro de equipo trabajar con Scrum.

Scrum implica una forma diferente de trabajar y el equipo que vaya a hacerlo tiene que ser consciente de ello y estar alineado en actitud y mentalidad. Equipos que nunca han trabajado con Scrum han de pasar por una adaptación a otra forma de trabajar, con ciclos cortos, con absoluta transparencia, construyendo confianza y estar abiertos a mucha comunicación. La pregunta que debe de plantearse cada miembro de un equipo que vaya a iniciarse en Scrum es la siguiente:

¿Hasta qué punto me gustaría ser libre?

Equipo de Scrum trabajando
Como libertad se entiende que el equipo decide cómo se construye, tiene libertad de moverse, tiene libertad de aceptar cambios y tiene libertad para probar y utilizar tecnologías, pero eso implica autoorganización, aprendizaje continuo, responsabilidad y compromiso en equipo. Todos deben de comprometerse por todos, tanto en las decisiones como en los errores. Se decide en equipo, por tanto todos toman la responsabilidad de cada decisión, y con cada decisión no acertada aprenden para la próxima vez. Por otro lado cada miembro debe de aceptar que sus compañeros hagan errores y apoyarlos incondicionalmente, para también aprender de los errores de todos. Scrum requiere equipos multifuncionales en los que todo miembro se interesa por lo que hacen sus compañeros, han de estar abiertos a aprender lo que hacen los demás y a ayudarles en momentos de sobrecarga. Como se puede ver hay que estar abierto a aprender en varios frentes durante todo el tiempo de construcción del proyecto/producto.

El éxito de Scrum se da en gran medida por el equipo, por la difusión y transferencia del conocimiento y la base de conocimiento común que se forma de manera distribuida en el equipo, por la confianza y conexión entre sus miembros, por la gestión de la comunicación que es elemental en tiempos tan cortos como son los sprints. Todo ello convierte a los equipos en equipos ganadores, de excelencia o hiperproductivos.

Los miembros del equipo han de reaprender a recibir feedback, capacidad innata que tenemos de niños y que de adultos tendemos a perder. Como adultos tendemos a justificarnos ante el feedback que recibamos sobre algo que hemos construido, y no es nada trivial cambiar de mentalidad para aceptar feedback y comprender que en Scrum simplemente hay que mirar para adelante y actuar, no hay premios ni penalizaciones. Scrum significa incertidumbre cosustancial y cambios constantes para el equipo, no hay nada mal hecho, todo está bien hecho; hay cosas menos bien hechas, simplemente bien hechas y más bien hechas. Cosas menos bien hechas, como que las personas hacen errores o el software vivo en cuya naturaleza están las incidencias, son oportunidades de aprendizaje, los errores e incidencias ocurren, se analizan y se corrigen. Los miembros de un equipo de Scrum han de aprender a ver los problemas y a ponerlos sobre la mesa, sin miedo, con el fin de que se arreglen cuanto antes, y no vuelvan a pasar. Quien encuentra un error o un problema, incluidos los propios, ha de exponerlo en la reunión diaria por ejemplo, y todo el equipo debe de aplaudirle, ya que un problema que ahora es pequeño podría haberse convertido en uno grande cuando inevitablemente apareciera más adelante.

En el día a día el equipo se ha de volcar y focalizar en las tareas del sprint, poniendo énfasis en lo que ofrece el momento, el sprint, y en su cumplimiento. La "solución" no existe, siempre hay varias soluciones para un problema, y estas se discuten entre todos para encontrar el camino con la solución más rápida y eficiente para llegar al objetivo del sprint.
Equipo de Scrum al completo, gracias Sergio por el dibujo
No todo equipo es adecuado para trabajar con Scrum, hay equipos que les cuesta lidiar con la libertad, el compromiso y la responsabilidad, de la misma manera que proyectos, negocio y dirección pueden hacer que no sea adecuado trabajar con Scrum. Hay personas con Scrum en su ADN, personas escépticas pero con curiosidad y personas claramente contrarias a Scrum, sólo es recomendable trabajar con Scrum con miembros de equipo de los dos primeros tipos, y aún así sólo es recomendable si todos pueden y quieren aprovechar esa oportunidad.

Agradecimientos a Thorsten Huber quién en su video "Kann jedes Team SCRUM?" plantó la semilla para este post.