martes, 23 de agosto de 2016

¿Cómo mantener la motivación de los miembros de los diversos equipos de la compañía?

Cartas Moving Motivators con las motivaciones intrínsecas
Recordando el quinto principio del Manifiesto Ágil este habla de la importancia de personas motivadas:

Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea

¿Pero cómo hacer que nuestros empleados estén motivados? Así en frío y pensando en nuestra cultura empresarial parece algo que entraña cierta dificultad.

Pensemos en como nos sentimos cuando nos incorporamos en una compañía nueva: si todo es correcto y cuando el salario nos permite no preocuparnos del dinero para nuestras necesidades cotidianas, las personas nos sentimos motivadas con los nuevos retos que nos esperan y sentimos ilusión por una nueva etapa en nuestra vida profesional. Por tanto el punto de partida es excelente, las personas cuando nos incorporamos a una compañía venimos motivadas de per se, lo único de lo que hay que hacer mantener la motivación.

La motivación más fuerte es la motivación intrínseca, la que ocurre cuando nuestro ambiente profesional permite desarrollar nuestro trabajo de forma correcta, bien hecha y con el sentimiento de que aportamos. Fijémonos en los bloggers que irradian su conocimiento, en los ingenieros de TI que participan en proyectos open-source como Linux, en los moderadores de foros y muchos otros que de forma gratuita aportan al mundo o a comunidades de práctica o de intereses comunes... y lo hacen gratis, y lo hacen por la mayor de las motivaciones, la de aportar con un trabajo bien hecho.

Scrum propicia el desarrollo de personas motivadas, esto ocurre por ejemplo cuando un equipo planifica el próximo sprint, y basándose en las mediciones de su velocidad media decide dónde poner el corte en la pila de producto. Recordemos que Scrum prohibe romper sprints, por tanto el espacio para la construcción de sprints se ajusta a la capacidad del equipo y no varía, una situación correcta de principio a fin. En la revisión del sprint, cuando los interesados ven y dan feedback sobre el incremento construido, es cuando el equipo siente que aporta, y cuando el Propietario del Producto comprueba el trabajo de forma objetiva mediante los criterios de aceptación, se produce un reconocimiento implícito, todos ellos elementos motivadores aportados por las prácticas de Scrum.

Por un lado Scrum propicia personas motivadas y por otro Scrum Masters, coaches ágiles y líderes ágiles deben de interesarse activamente por el desarrollo de las personas que integran los equipos de la compañía. Para perfilar lo que motiva a nuestros compañeros de trabajo, Jurgen Apello ha concebido la baraja de cartas con los Moving Motivators que presento en este post. Esta baraja se basa en los diez deseos intrínsecos que derivan de las obras de Daniel Pink, Steven Reiss, y Edward Deci.

Para averiguar qué factores de motivación son importantes para una persona el ejercicio consiste en colocar las cartas en el orden de importancia de izquierda (menos importante) a derecha (lo más importante). A partir de estos factores podemos mantener la motivación de nuestros empleados colocandolos en el lugar más adecuado, darles las herramientas y los retos correspondientes... entre las tareas del coach ágil está la de crear conexiones entre las personas y ser catalizador para que estas vayan siendo motivadas y desarrolladas cada una según sus factores de motivación.

Los factores de motivación también pueden ayudarnos en la contratación de un nuevo miembro del equipo, sabiendo lo que motiva a una persona podemos conocer su perfil y tomar una mejor decisión. Para un perfil ágil tipo T una buena incorporación podría ser alguien que diera más importancia a las relaciones, la curiosidad, la libertad, la meta...
Juego completo de cartas Moving Motivators de Managment 3.0
Ah, y algo más, la felicidad no es incompatible con la productividad... más bien al revés :-)

miércoles, 17 de agosto de 2016

¿Cuáles son las interacciones principales entre los roles de Scrum?

Interacciones entre roles - cortesía de José
Como ya sabemos los roles de Scrum son cuatro: Scrum Master, Propietario del Producto, equipo de desarrollo e interesados, pero ¿cómo interaccionan entre si?

1- Aunque no se trate de una interacción en si, el guiado por valor de negocio, poniendo el foco principal en los resultados empresariales, en otras palabras que la compañía venda más pensando a largo plazo, es el objetivo que debe de subyacer a todas las interacciones.

2- El equipo de desarrollo interacciona en dos momentos clave con el Propietario del Producto; la reunión de planificación de sprint, donde debe de comprender libre de dudas el "qué" ha de construir y decidir "cómo" lo va a hacer, y en la reunión de revisión de sprint, donde debe de entregar a los interesados un incremento con quality built-in, en otras palabras en Scrum la calidad no es una variable y la velocidad es la medición de capacidad el equipo construyendo siempre con calidad.

3- El Propietario del Producto es el responsable de explicar en la reunión de planificación de sprint de manera clara y concisa el "qué" ha de construir el equipo de desarrollo, basándose en la conversación sobre historias de usuario de calidad y apoyándose en todo tipo de documentos, diseños, prototipos y artefactos que le puedan ayudar.

4- Scrum sólo funciona con equipos pequeños que permitan a los miembros estar conectados e integrados como una unidad, es tarea del Scrum Master velar por y acompañar al equipo para que estén formados y desarrollen la autoorganización y multifuncionalidad en toda su magnitud.

5- El Propietario del Producto no está solo, forma equipo de negocio con los compañeros de su área (analistas de negocio) para el que se está construyendo el producto. Por tanto está apoyado por y es el representante de este equipo de negocio, y deben de existir todas las interacciones necesarias (reuniones, simulaciones, talleres, ...) para buenas tomas de decisión para una construcción guiada por valor de negocio. Por otro lado es responsabilidad del Propietario del Producto hacer la correcta gestión de interesados del proyecto/producto.

6- La parte crucial de la participación de los interesados está en su feedback continuo, feedback al Propietario del Producto para incluir o refinar elementos de la pila de producto, y feedback en uno de los puntos de clave de Scrum, feedback sobre el incremento entregado en la reunión de revisión de sprint.

7- La tarea por excelencia del Scrum Master es interactuar con todos y acompañarles en la correcta aplicación del marco de Scrum, sus valores y principios, y garantizar un correcto guiado por valor de negocio.

martes, 9 de agosto de 2016

¿Existe algún ejemplo de elementos funcionales de las diferentes pilas del marco SAFe®?

Dispositivos Responsive - cortesía de Freepik
Recientemente en una charla sobre SAFe® mi compañero José preguntó si existían ejemplos para los diferentes elementos de los backlog de SAFe. Estuvimos buscando ejemplos en la web pero no encontramos ninguno que recorriera todas las pilas. Con este post me aventuro a dar ejemplos alrededor de un proyecto de conversión de una web a responsive.

Recordemos que en SAFe hay cuatro niveles de pilas que comprenden el modelo: la pila de la cartera (Portfolio Backlog) que contiene epics y que emergen de temas estratégicos, la pila de la solución (Solution Backlog) que contiene capacidades, la pila de programa (Program Backlog) que contiene funcionalidades y la pila de equipo (Team Backlog) que contiene historias de usuario, pila que finalmente se descompone en tareas en una quinta pila, la pila de iteración (sprint).
Las pilas de SAFe - diapositiva de SAFe 4.0 in 8 Pictures
Temas estratégicos (Strategic Themes)

Los temas estratégicos son los objetivos de negocio que proporcionan diferenciación estratégica y que afectan a una solución de cartera particular, el tema estratégico en nuestro ejemplo sería:

Captar y conectar con una clientela más joven
Epics

Los epics son los elementos de negocio más grandes que capturan las mayores iniciativas transversales que se producen dentro de la cartera y que tratan temas estratégicos, estas entregan directamente valor de negocio y cruzan múltiples flujos de valor y trenes (ARTs). Los epics se escriben basados en el patrón para la visión de producto, nuestro epic de ejemplo sería:


PARA nuestra comunidad de clientes más joven
QUIEN entra a nuestra web a través de múltiples dispositivos
EL proyecto responsive
QUE ES UNA nueva visión de la comunicación, clave en la transformación digital
QUE permite que se adapten los formatos y contenidos tradicionales
para responder a las nuevas necesidades de los dispositivos de nuestros clientes
A DIFERENCIA DE nuestros competidores, cuyas webs
están diseñadas y concebidas para acceder a través de ordenadores de sobremesa
NUESTRO PRODUCTO estará dotado de la tecnología necesaria
para dar una experiencia de usuario con un nivel de escalado y personalización nunca vistos

Capacidades (Capabilities) y Funcionalidades (Features)

Dada la luz verde para la implementación de un epic, este se descompone en el nivel correspondiente (value stream o programa) en funcionalidades o capacidades. Las funcionalidades son un servicio proporcionado por el sistema que satisface alguna necesidad de los interesadosLas capacidades son similares a las funcionalidades, describen comportamientos de soluciones de nivel superior y a menudo requieren múltiples trenes (ARTs) para su construcción. Estas se escriben utilizando la matriz de Features and Benefits (FAB):

Ejemplo de capacidad:

CAPABILITY: homepage con diseño responsive
BENEFIT: una página principal atractiva y adaptable a diferentes dispositivos para ofrecer la mejor experiencia de navegación a nuestros usuarios
DESCRIPTION: debe de tener un menú desplegable y adaptable, un banner central, una zona central para contenido corporativo y un pie con links a contacto, nuestras apps y a las redes sociales

Ejemplo de funcionalidad:

FEATURE: menú flexible
BENEFIT: un menú desplegable y adaptable a diferentes dispositivo que facilite la navegación y permita dejar más espacio para el contenido
DESCRIPTIONmenú hamburguesa en que los elementos del mismo estén ocultos, liberando así espacio para el contenido, y mostrándolos al interaccionar con él, de forma horizontal u vertical según la resolución del dispositivo

Historias (Stories)

Las historias de usuario son una descripción breve de una funcionalidad contada desde la perspectiva del usuario y escrita en el lenguaje común del usuario, y que son resultado de descomposición de las funcionalidades por parte del equipo. Para formularlas se utiliza en patrón de Cohn, tal como describimos en el siguiente ejemplo:
COMO cliente registrado
QUIERO poder seleccionar la opción para ver artículos en el menú principal
PARA PODER leer los diferentes artículos disponibles en la web

Tareas (Tasks)

Las tareas definen los trabajos o actividades necesarias para llevar a cabo la construcción de una historia, ejemplos de tareas serían:
  • Maquetación menú versión escritorio
  • Maquetación menú versión móvil/tablet
  • Incluir las funcionalidades de Bootstrap (CSS base) en el tema
  • Codificación del menú
  • Comprobación del comportamiento del menú
Mis agradecimientos a Rivera, un compañero especialista en responsive que ha revisado los ejemplos desde la perspectiva responsive, gracias ;-)

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

sábado, 6 de agosto de 2016

¿Las historias de usuario son casos de uso?

Siempre que se mencionan casos de uso e historias de usuario se produce algo de confusión. Hay quien ha logrado incluir casos de uso en su proceso ágil pero eso no quiere decir que las historias de usuario sean equivalentes a los casos de uso.

Un caso de uso es una técnica para capturar la funcionalidad deseada desde la perspectiva de como los usuarios (actores) interactúan con el sistema. Se utiliza en UML (Unified Modeling Language) en los diagramas de casos de uso, un lenguaje de modelado que se utiliza para describir un sistema desde sus perspectivas estática y dinámica. Este resulta en un lenguaje descriptivo pensado inicialmente para sencillez en la comunicación pero que no es cercano a la comunicación humana. En cambio una historia de usuario está escrita en un lenguaje coloquial, que funciona a modo de recordatorio de una conversación con el cliente.

Como comenta Alistair Cockburn en 2001 en su libro Agile Software Development, realmente las historias de usuario están más cerca de la captura de requisitos, la fase que sirve para extraer las necesidades del usuario, que la especificación de requisitos, como son los casos de uso. Describe la diferencia entre historias de usuario y casos de uso de la siguiente manera:

Una historia de usuario es sinónimo de "característica"
como se usaba en la década de los noventa,
un marcador de lo que se debía construir, lo suficientemente detallado
para que se ajuste a una iteración moderna/los periodos del sprint.
Un caso de uso proporciona una visión contextual de lo que se va a construir,
y sirve para unir a la organización, entre otras cosas.

Podríamos decir que una historia de usuario representa el "qué" quiere el cliente o usuario y un caso de uso es el "cómo" lo quiere.
Historias de usuario versus casos de uso
En los criterios de aceptación también hay diferencias de concepto, a diferencia de los casos de uso que requieren matrices de seguimiento de requisitos con porcentajes de terminado, las historias de usuario, que incluyen criterios de aceptación, incluyen el terminado de forma binaria, o vale o no vale.

La propia Agilidad se hace patente en el hecho de que las historias de usuario son vivas. El análisis funcional y técnico se hace poco antes del desarrollo, en la reunión de planificación de sprint en caso de Scrum, por tanto el desglose en tareas lo hace el equipo, con lo que nivel de detalle y previsión supera en mucho al que pueda hacer un único arquitecto o analista funcional en los casos de uso.

Cuando un proyecto comienza a seguir una metodología ágil se deberían de olvidar completamente los casos de uso y el equipo debería de centrarse solo en la realización de historias de usuario.

Para los que estén interesados en complementar historias de usuario con casos de uso les invito a leer el libro de Cockburn, en él describe los problemas que pueden surgir y como les dio solución para sobrellevarlo.

sábado, 30 de julio de 2016

¿Cómo obtener de forma ágil una primera aproximación a la solución técnica?

Esquema con una solución de arquitectura técnica BI
Recordándo el undécimo principio del Manifiesto Ágil:

Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados

el equipo o equipos de desarrollo deben de participar en en el diseño de la solución desde el primer momento. Como primer paso expongo la primera de las actividades de la Incepción Ágil que se centra en el cómo, denominada mostrar la solución.

Trata de alinear a la gente en la forma de pensar sobre la construcción del producto, se hace en en el momento en que se forma el equipo y trata la arquitectura técnica para asegurarnos de que todos están de acuerdo con la solución antes de empezar.

Sus objetivos principales son:
Mostrar la solución del Agile
Inception Deck de Jonathan Rasmusson
La solución incluirá un cierto conjunto de herramientas, unas posibles librerías u APIs y una determinada arquitectura, y la mejor forma para alinear a todos es tratarlas de forma colaborativa por adelantado y enumerarlas en esta actividad.

Si hay riesgos o temas no resueltos, la actividad brinda la oportunidad para que se traten, quizá se aclaren, o si no hubiera todas las respuestas, se conozcan y se gestionen a lo largo del proyecto.

En la actividad el Propietario del Producto expone la visión del producto para que los demás participantes traten y debatan sobre el reto de encontrar una solución técnica. La dinámica está facilitada por el Scrum Master y como entregable se obtiene un esquema de la solución.

jueves, 21 de julio de 2016

¿Cómo impactan las historias de usuario en la toma de requisitos?

El "Druazo"
Recientemente descubrí un nuevo término que me ha arrancado más de una sonrisa y evidencia la problemática propia de las metodologías que no absorben el cambio de forma natural. Se trata del "Druazo", término que deriva del DRU "Documento de Requisitos de Usuario", documento también conocido en otros ámbitos como DDR "Documento de Definición de Requisitos".

El Druazo se produce cuando el usuario o interesado de negocio ve el producto construido y da feedback en forma de ajustes y cambios necesarios, y entonces el analista o jefe de proyecto esgrime el DRU argumentando que "en la página 67 en el segundo párrafo el usuario escribió hace 6 meses que lo que quería era..." y de forma figurada recibe un carpetazo en toda la frente.

Recordemos que un proyecto es para construir algo nuevo, algo que ampliará la herramienta con la que la compañía gestiona su core-business, mejorando algún aspecto o para incorporar una nueva linea de negocio. Por tanto un proyecto siempre es algo sobre lo que negocio no tiene experiencia y cuyas necesidades se dibujan y maduran a medida que aprende a lo largo de la construcción del producto. Nuestros usuarios no pueden saber a priori lo que necesitan, aún no tienen experiencia ni de la gestión ni de como el producto funcionará en el mercado, sólo tienen una imagen de lo que saben y la visión de lo que quieren.

Una de las dinámicas que hago en mis cursos sirve para traer a la luz los problemas corrientes en los proyectos de TI. Pido a todos los asistentes que escriban cada uno tantos post-its como problemas usuales hayan vivido, para luego consolidarlos en un tablero. El problema por excelencia, como podemos observar en la imagen de arriba a la derecha, se refiere a la presunta falta de definición en los requisitos iniciales, se pueden ver post-its como:
  • Indefiniciones de usuarios, DRU con cambios constantes
  • DRU escaso y poco definido
  • Cambio de requisitos durante el desarrollo
  • Especificaciones imprecisas de usuarios
  • Falta de definición
  • Poco esfuerzo para definir el alcance inicial
  • Especificaciones de usuario incompletas o no claras
Viñetas del columpio, un clásico en TI
Intentar definir al detalle todos los requisitos de usuario a principio de proyecto lleva invariablemente a la situación que nos muestran las famosas viñetas TI sobre la construcción de un columpio.

Lo que hay en el trasfondo de este problema es la falta de comunicación, que como sabemos Scrum resuelve con la comunicación cara a cara, la comunicación a lo largo de todo el proyecto y mediante tableros o pizarras, que no son otra cosa que una herramienta de pura comunicación y conexión de las personas que participan en el proyecto.

Para resolver una toma de requisitos progresiva, centrada en lo que da valor en cada momento y de forma que aproveche el conocimiento tácito y la empatía que todos tenemos, la Agilidad utiliza las historias de usuario, una promesa de un conversación cara a cara posterior basada en la fórmula de las 3 C's.

En uno de los cursos sobre historias de usuario hicimos un ejercicio final con la composición de un collage para mostrar lo que cada uno de los asistentes se lleva consigo. Uno de los alumnos compuso el collage que sigue, que describe tan bien como la toma de requisitos a través de las historias de usuario da solución al problema principal de la comunicación negocio-informática. Para mi el mensaje más importante del Manifiesto Ágil es "personas sobre procesos", y este collage lo muestra con toda su profundidad en relación a la toma de requisitos:
Collage que muestra como a través de las historias de usuario la agilidad da solución a un problema tan común
Gracias José Félix :-D

sábado, 9 de julio de 2016

¿Cuál es la manera ágil de concebir y acometer las tareas de los sprints?

Patrones de estrategia de sprint
Una de las cosas que aprende un Scrum Master con recorrido es a leer los tableros de los equipos. Un paseo por la sala dónde trabajan estos y con un vistazo a los tableros aprendemos a leer el nivel de autoorganización y multifuncionalidad de los diferentes equipos

Los equipos recién aterrizados en Scrum suelen comprender el proceso, las reglas y artefactos de Scrum, suelen no tener interiorizada la mentalidad ágil y tienden a aplicar comportamientos clásicos de pensamiento en cascada a las prácticas de Scrum, convirtiendo estas el algo así como un Frankenstein, hecho a pedazos de ambas metodologías, práctica que recibe el nombre de ScrumFall.

Recién comprendido el marco de Scrum y su construcción incremental e iterativa a base de sprints, los iniciados suelen trasladar las fases de la gestión en cascada a los sprints. Para cada funcionalidad a construir el primer impulso es pensar en modo clásico, en división en horizontal (por capas) y asignar sprints de forma secuencial a las diferentes fases de construcción. En un primer sprint se hace el análisis, que se acaba al 100%, en el siguiente sprint se inicia el desarrollo para finalmente hacer en un último sprint o grupo de sprints el testing (tal como está ilustrado como ScrumFall inter-sprints en la imagen arriba a la izquierda). Posiblemente esta solución sea mejor que un proyecto sin iteraciones, ya que así tenemos muchos pequeños proyectos y minimizamos riesgos y tenemos puntos de feedback, pero estamos lejos aún de ser ágiles y de beneficiarnos de todo lo que aporta Scrum. Este patrón se suele corregir de forma temprana, una buena formación en que se resalte la mentalidad ágil suele evitar que los equipos noveles caigan en esta práctica.

Ejemplo de tablero ScrumFall intra-sprints
 cortesía de Joaquín
Lo que sí es muy frecuente es el ScrumFall intra-sprints. El equipo obtiene la pila de sprint en la planificación de sprint, desglosa en tareas y en ese mismo momento asigna todas las tareas a los diferentes especialistas del equipo. El resultado es una construcción por fases de la funcionalidad, entregamos la funcionalidad completa y finalizada en la revisión de sprint, pero la construcción ha sido en cascada. Construir de esta manera puede funcionar perfectamente, pero perdemos los beneficios del trabajo por parejas o en equipo, los beneficios de las diferentes perspectivas de las personas que lo forman, y de lo que no solemos ser muy conscientes, de que esas fases no siempre son lineales, suele haber retrocesos y bucles que suelen ser un gran desperdicio.

Insistí mucho a uno de los equipos que acompañé como Scrum Master que la maquetadora y el desarrollador del front trabajaran juntos, durante los primeros 5 sprints no lo comprendieron y no lo hicieron, así que las tareas iban y venían de uno a otro hasta que el resultado fuera satisfactorio. Cuando por fin experimentaron mi consejo y se sentaron juntos ante un ordenador lo vivieron de primera mano, el tiempo de construcción se redujo sensiblemente y además se habían divertido y congeniado. Me emocioné mucho cuando expusieron su experiencia en una retrospectiva :-D

Arriba a la derecha muestro un tablero que ilustra ScrumFall intra-sprints en toda su dimensión. Cada uno de los carriles está asignado a uno de los diferentes miembros del equipo y todas las tareas, en diferentes situaciones, están asignadas individualmente a esos miembros. La consecuencia de esa estrategia es que cada miembro está focalizado básicamente en sus propias tareas perdiendo de vista la perspectiva general del sprint. Una segunda lectura que podemos hacer es la de una columna "en construcción" muy saturada, vemos que algunos de los miembros del equipo tienen muchas tareas abiertas, lo que supone convivir con el desperdicio de la multitarea y probablemente tiempos de espera por dependencias de otras tareas de otros miembros. ¿No sería deseable que todo el equipo estuviera focalizado a la vez en lo mismo y se ayudasen unos a otros en todo momento?

La forma ágil de acometer tareas en un sprint es la siguiente:
  • Por historias de usuario, recorriéndolas de la más prioritaria a la menos prioritaria, y no trabajar en más de una o dos a la vez.
  • Con autogestión: el equipo va autoasignando las tareas en las dailys a medida y en función del avance de sprint, eso coordinará y alineará diariamente al equipo.
  • De forma cross funcional: el equipo intenta acometer como verdadero equipo una sola historia de usuario a la vez. Los beneficios son que todos los miembros están focalizados y participan de la historia de usuario en curso, con lo que las buenas ideas surgen de las diferentes perspectivas que tiene cada individuo, y permite que los miembros se ayuden y se apoyen entre sí.
¡Pare de comenzar y empiece a terminar!

Termino el post con un buen tablero scrumboard en el equipo está "quemando" las historias de usuario de arriba a abajo, como una unidad cohesionada.
Ejemplo de un scrumboard con un equipo integrado trabajando de manera cross funcional