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.