¿ScrumBut se basa en valores y principios?

Cortesía de Pixabay

Con este post quiero poner un poco de humor en el blog :-D

Estamos viviendo unos tiempos interesantes, la Agilidad se expande a todo tipo de disciplinas y emergen Manifiestos Ágiles en algunas de ellas. Ejemplos son el Manifiesto Ágil de Marketing, el Manifiesto Ágil para el Desarrollo de RRHH (recursos humanos), el Manifiesto Ágil para Negocio, el Manifiesto Ágil para Ventas,... y los manifiestos complemento como lo son el Manifesto for Software Craftmanship, el Manifiesto para Gente Ágil, el Testing Manifesto, el Manifiesto de Sistemas Reactivos... y hasta, con mucho sentido de humor y gracias a Kerry Buckley, un Manfiesto Ágil que soporta ScrumBut, ideal para esas empresas que para tomar su camino hacia la Agilidad adaptan Scrum en lugar de adoptarlo.

A continuación la traducción del Manifiesto :-P

Manifiesto para el Desarrollo Ágil de Software a Medias Tintas

Hemos escuchado sobre nuevas formas de desarrollar software pagando consultores y leyendo informes de Gartner. A través de esto nos han dicho que valoremos:

• A los individuos y su interacción, por encima de los procesos y las herramientas
  y teniendo procesos y herramientas obligatorias para controlar cómo interactúan esos individuos (preferimos el término "recursos")

• El software que funciona, por encima de la documentación exhaustiva
  siempre y cuando ese software esté exhaustivamente documentado

• La colaboración con el cliente, por encima de la negociación contractual
  dentro de los límites de los contratos estrictos, y por supuesto sujetos a un riguroso control de cambios

• La respuesta al cambio, por encima del seguimiento de un plan
  siempre que se haya establecido un plan detallado para responder al cambio, y este se sigua de forma precisa

Es decir, aunque los elementos de la izquierda suenan bien en teoría, somos una gran empresa, y no hay forma de que dejemos de lado los elementos de la derecha.

---

Y gracias a Rafael Sabbagh de Knowledge21 reproduzco a continuación:

Los 12 Principios Frágiles (de la Gestión Tradicional de Proyectos)

1. Nuestra mayor prioridad es respetar el plan mediante de la entrega de software, dentro del plazo previsto, con el alcance comprometido.
2. No nos gusta que los requisitos cambien, incluso queremos que los cambios sean evitados o gestionados estrictamente en cualquier etapa del desarrollo. Los procesos tradicionales aprovechan el cambio para poder cobrarle más caro al cliente.
3. Entregar software funcional, entre muchas semanas y muchos meses, con preferencia al periodo de tiempo más largo posible.
4. Los responsables de negocio y los desarrolladores trabajamos separadamente de forma cotidiana durante todo el proyecto y se comunican a través de documentos y especificaciones.
5. Los proyectos se desarrollan en torno a los mejores procesos y herramientas. Hay que dirigir y controlar a los individuos, sin nunca confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es partir de documentos detallados.
7. El porcentaje de tareas cumplidas es la medida principal de progreso.
8. Los procesos tradicionales promueven el desarrollo haciendo lo necesario. Los promotores y los usuarios debemos ser capaces de mantener una presión constante sobre los desarrolladores para acelerar su ritmo de trabajo de forma indefinida y para que entreguen lo prometido.
9. La atención continua al plazo y al presupuesto mejora las posibilidades de que se produzca la entrega, incluso si deben hacerse concesiones en materia de calidad.
10. La complejidad, o el arte de maximizar la cantidad de trabajo realizado, es esencial.
11. Las mejores arquitecturas, requisitos y proyectos son definidos y detallados por gerentes y jefes antes del inicio del trabajo.
12. Al final del proyecto el equipo reflexiona sobre lo que ha ido mal y de quién fue la culpa, y espera poder ajustar y perfeccionar su comportamiento en consecuencia en algún próximo proyecto.

¿Hay alguna dinámica para la resolución de conflictos entre distintos equipos de una compañía?

El coach ante los resultados de éxito

Cuando ocurren eventos mayores en las compañías, como por ejemplo cambios del modelo de negocio o transformaciones como pueden ser la ágil o la digital, pueden producirse conflictos entre departamentos, tribus o equipos. Imaginemos por ejemplo los conflictos que puedan surgir entre un equipo tradicional y uno ágil cuando a partir del inicio de la transformación son tratados de manera distinta y obtienen recursos diferentes.

En grémio AgileGo nos juntamos unos pocos voluntarios e hicimos un ejercicio de resolución de conflictos basado en el trabajo de tierras organizacionales del modelo de coaching de organizaciones y sistemas relacionales ​ORSC™, que se trabaja el respecto, la indagación y la consciencia.

Para que la dinámica tenga éxito debe de haber voluntad por ambos lados para llegar a un consenso. Si no fuera el caso habría que empezar con una dinámica distinta para buscar los puntos y el interés que tienen en común y crear una alianza para poder buscar solución al conflicto.

Preparación de la dinámica

Para preparar la dinámica se crean tres espacios en la sala, dibujando una "Y" en el suelo con cinta de carrocero por ejemplo. Una de las cuñas será el territorio de uno de los equipos, la otra la del otro equipo, el tercer área será un territorio nuevo y común a explorar.

Se empieza educando a las personas en como funciona la dinámica. Cada equipo se sitúa en su territorio y describe como es, lo que ocurre allí y que se siente estando allí.

Como coach ágil podemos seguir el siguiente guión de preguntas:

• ¿Qué es lo que te encanta de tu equipo?
• ¿Qué te apasiona aquí?
• ¿Qué es difícil en tu territorio?
• ¿Qué quieres que conozcan los miembros de otros equipos sobre tu territorio?

Puede ocurrir que alguna persona diga que "esto es una tontería" o similares. En ese caso se le invita a apartarse y a observar sin voz ni voto. En cualquier momento puede incorporarse, y si lo hace deberá de aceptar las reglas de la dinámica y participar.

Expuestos ambos territorios, cada equipo visita el territorio del otro como si fueran turistas. Es importante adquirir esta mentalidad, el turista que va a tierras lejanas va con la mente abierta, absorbe lo que ocurre, es curioso, acepta que hay otros puntos de vista y creencias, se adapta sin dejar de ser el mismo y sin dejar de lado sus propias creencias. Es como cuando vamos de visita a Japón, cuando estamos de visita en Tokio somos conscientes de que todo es distinto, lo aceptamos y nos adaptamos a lo largo de la visita. Sabemos que estamos de visita y que el viaje acabará para volver a nuestra ciudad, de manera similar los miembros de los equipos que visiten el territorio de otro saben que pueden volver a su territorio en cualquier momento.

Guión de preguntas que el coach ágil puede hacer a los visitantes:

• ¿Cómo se sobrelleva el estar en este equipo?
• ¿Qué es importante aquí?
• ¿Cuáles son los retos y las presiones?
• ¿Qué ayuda o apoyo necesitan de otros equipos?

Los visitantes pueden ir anotando valores, perspectivas, intereses, etc. que les parezcan interesante llevarse.

A los miembros del equipo del territorio visitado, que han estado presentes como observadores, se les puede preguntar:

• ¿Qué se entendió correctamente?
• ¿Qué sentís al haber oído todo eso?

Los participantes del ejercicio exponiendo como son sus territorios plenamente sumergidos en su papel

Puntos en común y plan de acción

Cuando los equipos hayan visitado el territorio del otro, todos los participantes se deben de situar en el territorio común, el territorio de ambos. Todos ellos habrán experimentado como es vivir el territorio del equipo con el que están en conflicto, habrán sentido qué ocurre allí, qué contexto hay y como influye y con qué problemas lidian. Habremos trabajado la empatia a nivel de equipos al completo.

En el territorio de ambos cada participante expone las cosas que se ha llevado del otro territorio y se buscan los puntos en común para que ambos equipos converjan. Como coach anotamos todos los puntos relevantes en un rotafolios. Finalmente facilitamos una brainstorming para obtener un plan de acción, una serie acciones que llevarán a cabo para resolver el conflicto y que les servirá para evitar conflictos futuros.

Descargas / Downloads

El escenario con un conflicto ficticio que utilizamos para el ejercicio descrito en el post.

Mis agradecimientos a los miembros de AgilGo que participaron en el ejercicio:
José, María, Ángel, Jesús, Esther y Nayua

¿Quién es tu cliente?

La mejor métrica de éxito:
el nivel de contento del cliente

Hoy en día toda compañía basa su core-business en el software, por tanto TI es estratégico, y la forma de trabajar y la calidad de los equipos que construyen y mantienen ese software tiene un impacto directo sobre la competitividad de la compañía.

Agilidad ha acuñado el término customer centric (centrado en el cliente) para mostrar cuál debería de ser el objetivo último de cualquier compañía de software ágil: deleitar al cliente. La métrica de éxito de un producto debe de ser el nivel de "contento" de los usuarios y el cliente. Para ello es necesario:

• Equipos organizados alrededor de valor de negocio
• Equipos con visión y comprensión del producto

La Agilidad conecta a los equipos con el cliente a través de su estructura y sus prácticas:

• Pone el foco en equipos de funcionalidades: estos están alineados con la creación de funcionalidades de principio a fin que dan valor para el cliente (a diferencia de equipos de componentes).
• Proyectos muy grandes se subdividen en áreas de requisitos que están focalizadas en los requisitos del cliente y no en subsistemas arquitectónicos.
• Los Propietarios del Producto y sus roles de escalado asociados son conectores entre equipos y clientes, no son simples intermediarios.
• Los equipos participan en el refinamiento de las funcionalidades comprendiendo así mejor las necesidades y el punto de vista del cliente.
• Las pilas de producto escaladas conectadas en constante repriorización y refinamiento optimizan la entrega general de valor al cliente.

A veces hay equipos en proyectos creando código sin saber porqué, ni saben de qué participan y cuya calidad del producto final suele ser mediocre. La razón de esta disfunción suele ser el cliente final real.

Debemos de mirar la cadena de valor de la compañía, quién está al inicio de la misma y cuyas necesidades la inician, y dónde acaba, quién obtiene en valor o beneficio al final. Si no coinciden inicio y fin, la compañía no es customer centric y por tanto es disfuncional desde el punto de vista de la Agilidad. Al inicio siempre está el cliente, y si al final de la cadena está el mismo que al inicio, la compañía es customer centric, si no es así y está el inversor la compañía es investor centric.

Las compañías centradas en el inversor suelen ser compañías de recorridos a corto plazo y suelen tener una alta desmotivación entre sus empleados. Un indicador que puede evidenciar este tipo de compañías es cuando no saben como medir su time-to-market. Hay muchos modelos de negocio posibles, aquellos modelos que prosperan y pretenden ser sostenibles a través de la Agilidad deben de buscar la máxima satisfacción y deleite de sus clientes. Empezando por aquí los beneficios siempre vienen solos a medio y largo plazo.

¿Hay alguna herramienta para hacer buenas visualizaciones gráficas?

El marco de Scrum - Thanks to Sabine

Como se suele decir "vale más una imagen que mil palabras". Los seres humanos somos visuales y es por ello que en reuniones, clases y sesiones de coaching utilizamos rotafolios, pots-its y rotuladores para potenciar la comunicación y la conexión entre los asistentes.

Mis visualizaciones son eficaces, cumplen con su cometido, pero ¿son eficientes?, ¿lo hacen de una manera que aprovechan todo el potencial de una visualización en todas sus dimensiones? Para los que somos coaches ágiles, trainers y Scrum Masters es importante dotarnos de las mejores herramientas de visualización posibles.

A la izquierda vemos la visualización del marco de Scrum de Sabine, una CST que acompañé en un curso de Scrum. Su capacidad de atracción y transmisión supera en mucho lo que yo suelo hacer, así que gracias a María, que hizo que los Reyes Magos me trajeran un kid de Bikablo, voy a iniciar mi camino en la facilitación gráfica para obtener visualizaciones de calidad :-D

Si visitamos la página de Bikablo podemos leer:

"La visualización y la facilitación visual es un (nuevo) método para hacer que el contenido y el proceso sean visibles en tiempo real. Ya sea en presentaciones, talleres, sesiones de coaching, capacitaciones y reuniones: cuando las personas entablan un diálogo, trabajan juntas y quieren aprender unas de otras de manera impactante. Bikablo es nuestra marca que abre la puerta al mundo del pensamiento visual y el diálogo".

Kid con el diccionario visual y
13 rotuladores de colores variados

Diccionario visual 1

El kid consta de un diccionario visual que contiene instrucciones muy simples de como funciona el método con más de cien páginas con palabras clave relacionadas con dibujos muy simples pero impactantes para nuestras visualizaciones, más un paquete con 13 rotuladores de colores muy variados, uno de color negro fuerte y 12 de colores pastel para sombrear y dar colorido sin quitar el foco a lo importante. Este material se puede encontrar tanto en Neuland como en Amazon.

"Trabajar con el poder de las imágenes, estructurar lo complicado, pronunciar lo difícil, hacer que lo abstracto sea palpable y lo decisivo notable. Las imágenes son divertidas para todos, tienen un efecto emocional y de conexión y a menudo transportan el contenido mejor que las palabras".

Así que me animé a mi primer intento dedicado al blog :-D

¡Primer intento! :-) :-) :-)

Mis agradecimientos a María, mi pareja, que ha hecho posible que me iniciara en este mundo :-D

¿Pueden tener los coaches ágiles diferentes estilos?

Estilos de Scrum Master
Thanks Alexandre for the picture

Tanto coaches ágiles como Scrum Masters aplican diferentes estilos en su trabajo, el estilo aplicado en cada momento dependerá de la necesidad y de la madurez de los equipos con quienes trabajen.

Lyssa Adkins indentifica tres estilos en su libro Coaching Agile Teams:

"Con el tiempo he conocido tres estilos de coaches ágiles en mi misma y en los coaches de los que he aprendido: Enseñando, Entrenando y Aconsejando"

Alexandre Magno y yo identificamos 4 estilos:

• Trainer: Formador del proceso
• Coach: Entrenador de las personas
• Mentor: Introducción y consejo de Agilidad en la cultura de la empresa
• Facilitador: Garantía de cumplimiento de roles y formas del modelo

Enseñando (Trainer): Este estilo transfiere conocimiento y enseña los principios y las reglas de Agilidad y Scrum. Esto puede hacerse suavemente o con fuerza, no importa, pero debe de hacerse con intención férrea, eso importa. Hay que transmitir las reglas fuertemente, junto con la convicción de que Agilidad va a traer una manera de trabajar mejor. Es muy positivo reforzar las enseñanzas con experiencias, ilustrando por qué Agilidad es como es y porqué funciona.

Entrenando (Coach): El estilo de coaching requiere del fundamento establecido por el estilo de enseñanza anterior. Con las prácticas ágiles ya funcionando bien, el equipo habrá creado su propio conocimiento y comienza a transformar el cumplimiento de reglas a la internalización de valores en base a sus experiencias con la Agilidad. A medida que vayan más allá consideraran un poco más profundamente lo que subyace a las prácticas, y las mentes de los miembros del equipo se abrirán a las múltiples maneras de realizar lo mismo mientras se sostienen los valores y los principios. Están listos para algunas excepciones a las reglas y para experimentar con sus propias expresiones de las reglas. Algunas excepciones no serán aceptables porque violan los principios subyacentes, como coach hay que subrayar esto y luego apartarse para que aprendan de sus propios errores. Necesitan experiencia directa y feedback para poder inspeccionar realmente lo sucedido y poder evaluar si el cambio fue útil o perjudicial.

Aconsejando (Mentor): Este es el estilo de asesoría, de transferencia de expertise, viene cuando el equipo ya ha interiorizado completamente las prácticas, valores y principios de la Agilidad e irradia buena salud. Las cosas fluyen como una maquinaria bien engrasada. El equipo ya camina sin el coach o Scrum Master, pero puede que aún no se hayan dado cuenta de ello. Para dejar que se consoliden debemos de mantenernos alejados de su camino, sabiendo que van a pedir ayuda a su asesor de confianza cuando lo necesiten. Ellos son libres de encontrar sus propios caminos, se trata de permitir que a través de la experiencia y la mejora continua superen al maestro.

Facilitando (Facilitador): Un coach o Scrum Master también ha de tener el estilo de la facilitación, ser un experto en un conjunto de herramientas, técnicas y habilidades para garantizar el buen funcionamiento del equipo a través de acuerdos y políticas. Trabaja ayudando al equipo en la consecución de sus objetivos y la realización de su visión colectiva, como en la creación de un clima donde reine la confianza y una comunicación fluida, empática y transparente.

¿Cómo hacer una retrospectiva que marque dirección al equipo?

En esta ocasión tenía un equipo que llevaban mucho tiempo trabajando juntos y notaba que su campo emocional no desprendía la energía como solían hacerlo. Necesitaban reencontrar su camino y proyectarse de nuevo como una unidad hacia el futuro. Aproveché una retrospectiva para utilizar una técnica llamada constelación en papel del modelo de coaching de organizaciones y sistemas relacionales ​ORSC™.

Leyenda con los símbolos

La idea es crear una instantánea del sistema, equipo más entorno, dibujando las interrelaciones que ocurren dentro de él. A la izquierda podemos ver en la imagen la leyenda de los elementos del sistema. En la dinámica original el tachado que se puede ver en la representación de la relación fuerte significa conflicto, y el tachado es aplicable a todas las relaciones. En este caso, y por un malentendido, incorporamos el tachado como parte de la relación fuerte. Realmente mi pretensión era que todas las relaciones fueran positivas, no buscaba tratar conflictos del equipo. Si experimentáis con la constelación en papel quitadle el tachado a la relación fuerte :-)

Las instrucciones para los miembros del equipo son: dibujar un gran circulo, utilizar los símbolos de la leyenda para dibujarse primero a si mismo, dentro (o fuera) del circulo, y después incorporar todo lo demás según lo que cada uno considere importante.

Obtenido el dibujo de todos los miembros los colgamos en una pared y a la vista de todos pasamos a tratarlos uno por uno respondiendo a dos preguntas:

Antes y después de dos de los miembros

• ¿Qué estás aprendiendo?
• ¿Qué debería de cambiar?

Hicieron descubrimientos relevantes en su propio dibujo; como que les aparecían pocos eventos, o que podría haber eventos de otra índole, o que no todas las relaciones estaban claras...

Los miembros del equipo se pasearon por la galería de dibujos preguntando unos a otros por aquello que les llamaba la atención. Una vez vistos todos los dibujos se les pide que visualicen al equipo como querría cada uno que fuera y lo dibujen en una hoja nueva.

Acabadas la nuevas versiones de los dibujos las colgamos debajo de las primeras. Es interesantísimo ver como los dibujos nuevos se parecen todos entre si, son similares con algunas diferencias menores.

Finalmente se pasa a buscar un plan acción, un brainstorming de equipo sobre cosas puede hacer para llegar a esa configuración deseada del segundo dibujo. Fue una experiencia muy potente, hubo mucha complicidad entre los miembros, y aunque como coach ágil no entiendes los detalles, sientes la seguridad de que ocurrió una gran unión entre los miembros del equipo.

¿Qué son y como funcionan las historias técnicas?

Las historias de usuario consumen historias técnicas
Cortesía de Pixabay

La pila de producto contiene todos los "qués" a construir, elementos como historias de usuario, epics y temas. Pero en realidad, para poder realizar planificaciones tanto de sprint como de release, debe de contener todo el trabajo a hacer, y algunos de los elementos puede que no sean funcionales y sean necesidades de carácter técnico que no aporten valor de negocio, pero son consumidas por los elementos funcionales. También es interesante que negocio y Propietario del Producto tengan contacto con los aspectos técnicos, ya que así se forja un lenguaje común en ambas direcciones y se da consciencia de su importancia.

A estos elementos se les llama historias técnicas o enablers (habilitadores), y son cosas como preparar un webserver, implementar un conjunto de tablas en una base de datos que va a ser consumida por varias funcionalidades, elementos de seguridad, escalabilidad, rendimiento, etc. Otros tipos de historias técnicas se centran en resolver deuda técnica y en refactorizaciones, otros en historias de exploración como un análisis técnico o uno funcional que sirve para despejar incertidumbre sobre alguna historia de usuario.

Las historias técnicas se escriben directamente en texto técnico claro y preciso, sin un patrón como ocurre con las historias de usuario. También tienen criterios de aceptación asociados que se comprueban en la revisión de sprint por la audiencia técnica correspondiente.

Aunque el Propietario del Producto sea el responsable de la pila de producto y por tanto de todos sus elementos, en el caso de las historias técnicas los verdaderos "propietarios" son perfiles de carácter técnico como el equipo o un arquitecto. Estos no solo son responsables de la definición de la misma sino también de responder a dudas y preguntas y aclaraciones en la planificación y en la entrega de las historias.

Se pueden identificar diferentes tipos de historias técnicas:

• Arquitectura: construyen elementos como las API's que crean la estructura, funcionamiento e interacción entre distintas las partes del software.
  Ejemplo: "Implementar un sistema de login seguro".
• Infraestructura de producto: historias que son consumidas directamente por historias de usuario. Esto podría incluir infraestructura nueva y/o modificada, y oportunidades de refactorización originada por alguna necesidad funcional.
  Ejemplo: "Preparar los servidores de base de datos y web".
• Infraestructura del equipo: historias que respaldan al equipo en su capacidad para entregar software. Suelen ser historias para herramientas y marcos de pruebas, métricas, diseño, planificación... y también pueden implicar que el equipo "desarrolle" o "compre e instale" algo.
  Ejemplo: "Preparar un sistema de integración continua"
• Refactorización: estas son historias que representan candidatos para refactorizar, como por ejemplo lo es la deuda técnica. Pero no solo el código necesita de refactorización, también puede incluir diseños, automatización, herramientas y cualquier documentación de proceso.
  Ejemplo: "Homogeneizar el código de la función de cálculo de préstamos".
• Spikes: historias de exploración limitadas en tiempo que dan respuesta a una cuestión, o reúnen información para una toma de decisión posterior o el diseño de una solución.
  Ejemplo: "Evaluar Oracle versus SQL/Server".

¿Se estiman todos los elementos de la pila de producto en la misma unidad?

Elementos que representan la granularidad de pila de producto

Recordemos que una pila de producto debe de estar viva, ordenada por prioridad y sus elementos deben de ser negociables y por tanto tener una granularidad o nivel de detalle en relación a la posición dentro de la misma.

Tal como muestra la imagen de la izquierda, las historias de usuario encabezan la lista, y al final, donde está lo menos prioritario, están los epics y los temas.

A tratarse de elementos con granularidades diferentes, por ejemplo un tema o un epic puede resultar en 1000 veces el tamaño de la historia de usuario de referencia, nos hemos de preguntar si tiene sentido aplicar la misma unidad a elementos tan dispares.

Para las historias de usuario la técnica del planning poker basado en la serie de Fibonacci es una excelente solución. Al Propietario del Producto le permite tomar decisiones relativas a la priorización, y al ser estimaciones en formato numérico, y que por tanto se pueden sumar, permite calcular la velocidad y al equipo a hacer el corte en la pila de producto con las historias que caben en el siguiente sprint.

Cartas con la serie de Fibonacci - cortesía de Scrum Manager

Para la estimación de elementos grandes, como pueden ser los epics y los temas, la serie de Fibonacci no siempre es la más adecuada ya que sus estimaciones numéricas serian muy altas y darían una idea de precisión inexistente. La técnica de las tallas de camisa es más adecuada ya que las tallas dan una intuición más que una estimación, algo con un gran grado de incertidumbre que está de acorde a la naturaleza de los epics y temas, y a la vez es suficiente para la toma de decisiones del Propietario del Producto.

Cartas con tallas de camisa

En un marco de escalado, en el que tenemos varios equipos trabajando en un mismo producto y la pila de producto esta presente en una jerarquía de pilas con elementos de diferentes tamaños, puede ser necesario tener estimaciones en valores numéricos para poder agregar y hacer cálculos a niveles por encima del equipo. Un equipo de equipos, como son los trenes de SAFe o las tribus del modelo de Spotify, tiene una velocidad con valores altos, por tanto será necesario estimar epics y temas en números para poder decidir como distribuirlos estrategicamente a los diferentes equipos de equipos.

Elementos tan grandes no se pueden estimar directamente, hemos de utilizar la técnica de la estimación en escalado. Primero necesitamos un epic de referencia, un 144 por ejemplo, para poder estimar el resto en relativo. Para obtener la estimación del epic de referencia hay que desglosarlo en la fase de análisis del modelo de negocio en historias de usuario tentativas, estimar estas para después agregar las estimaciones individuales. Al estimar epics de esta manera lo que estamos haciendo realmente es aplicar los primeros valores de la serie de Fibonacci, ya que por ejemplo 377 es aproximadamente 3 veces 144.

Cartas de planning poker para estimar en escalado de UST Global

¿Cómo puede ser un marco operativo para utilizar Scrum en una compañía en España?

He pasado por diferentes empresas en España que han iniciado su camino en Agilidad y he observado enfoques y prácticas comunes. En este post pretendo mostrar lo que suele rodear a los equipos que trabajan en Scrum en compañías que inician su transformación ágil. Se puede considerar una primera aproximación de cómo podrían ser los inicios en el funcionamiento ágil a nivel de proyecto, cliente y proveedor.

Cualquier marco de partida ha de basarse en los 5 niveles de planificación que contempla la gestión ágil, cuyos tres niveles superiores, visión, hoja de ruta y planificación de release son parte de la fase de definición que deberá liderar el cliente. La fase de ejecución, que incluye la planificación de sprint y la diaria, se suele hacer con Scrum, y en caso de incluir un proveedor externo estará supervisada por un coordinador del cliente que hará de nexo y será responsable del seguimiento del proyecto. Por último un departamento de seguridad y calidad, generalmente una PMO (oficina de proyectos), se encargará de asegurar el cumplimiento con el nivel de calidad definido por los criterios de hecho y las políticas definidas.

Niveles de planificación y aproximaciones

La fase de contratación une definición y ejecución, y el "cómo" se resuelva es irrelevante desde el punto de vista del Agilidad. Lo que si he observado es que una vez entendida la necesidad de continuidad de los equipos, compras abre la posibilidad de contratación de un equipo por un año con posibilidad de continuidad a más años con el entendido de que TI alimente de proyectos a este equipo.

Definición

La fase de definición permitirá obtener los siguientes 5 outputs:

• Visión del producto
• Pila de producto inicial
• Planificación de la primera release
• Hoja de ruta del producto
• Valoración económica y plazo

Marco general que sintetiza como algunas compañías tradicionales inician su transformación ágil

Solicitud y justificación del producto: Todo proyecto deberá iniciarse en la generación de una visión que deberá de responder a las siguientes tres preguntas:

• Quién es el público: ¿Quién va a utilizar tu producto?
• Qué problema tiene: ¿Qué problema o necesidad latente se va a satisfacer?
• Qué solución se ofrece: ¿Cómo se va a satisfacer?

Obtenida la visión se procederá a iniciar la solicitud del mismo por las vías establecidas.

Organización del equipo de trabajo: Obtenida la aprobación del proyecto se deberá de constituir la organización del equipo que liderará el proyecto, se identificaran:

• Propietario del Producto: que liderará la macrogestión del proyecto dándole misión y propósito.
• Coordinador: que apoyará la microgestión y la maestría del equipo de desarrollo por venir y actuará de enlace con sistemas, arquitectura y calidad del cliente.
• Scrum Master: que se ocupará de la gestión del modelo operativo de Agilidad y su mejora continua así como de la gestión de las personas (formación, entrenamiento y asentamiento del modelo).
• Interesados: se identificaran todos los interesados en el proyecto, todos aquellos que pueden influenciarlo y que son usuarios del software a construir.

Plan de trabajo para definir la pila del producto inicial y su valoración: El Scrum Master se encargará de hacer todos los preparativos así como de coordinar las agendas, para que los talleres para obtener la pila inicial esté presente todo el mundo, y se puedan desarrollar de la forma más eficiente posible.

Taller funcional: En este taller se pretende obtener la parte funcional de la pila de producto inicial a través de un User Story Mapping sobre cada uno de los procesos, desde los diferentes puntos de vista de quienes interactúan con el sistema.

Asistirán a este evento, liderado por el Propietario del Producto, quienes conocen el negocio, entre ellos usuarios, así como parte o todo el equipo de desarrollo. Las actividades y conversaciones que se producirán tienen un gran beneficio porque abren canales de comunicación entre las personas de negocio y tecnología.

Todos los requisitos identificados se estimarán en valor de negocio y se trasladarán a un tablero con la hoja de ruta, priorizando las historias de usuario en función de la release de la que se pretende que formen parte. Se dará especial foco a la primera release que constituirá el Mínimo Producto Viable (MPV).

Taller técnico: consiste en la añadidura de historias técnicas por parte del equipo de sistemas y del equipo de desarrollo si este último ya estuviera constituido. Muy posiblemente la primera release requiera preparar un entorno de producción, arquitectura... historias sin las que sería imposible que funcionara el software construido. Estas historias técnicas se estimarán en esfuerzo y se refinará la priorización de la pila de producto sobre la hoja de ruta.

Valoración económica y plazo: finalmente el coordinador elaborará junto con el Propietario del Producto el contenido inicial del proyecto. En función del presupuesto disponible realizarán un corte en la pila de producto con aquello que el presupuesto permita abarcar en total de esfuerzo y plazo. Esta valoración servirá de base para el pliego y la contratación del equipo de desarrollo de proveedor.

En este modelo tiene especial importancia al sprint 0 ya que en él se establece el entorno de colaboración entre cliente y el proveedor.

• Visión del producto: coincidimos todos en ello como una de las cosas más importantes. Visión de lo que hay que hacer y además que esté compartida. Saber qué es y que no es el producto.
• Equipo: formado, motivado y con actitud proactiva.
• Intervinientes y contactos: quien tiene algo que hacer y qué.
• Fases de aceptación: proceso para conseguirlo, acuerdos de trabajo. Definición de hecho (Done).
• Expectativas de Calidad.
• Detección de dependencias.
• Restricciones o limitaciones: de seguridad, de rendimiento, de disponibilidad, …
• Pila de riesgos del proyecto: se pueden intercalar con la pila de producto, para dar respuesta temprana a cualquier riesgo.
• Métricas que se seguirán en el proyecto.
• Entorno tecnológico disponible.
• Spikes de arquitectura.

Ejecución

Cuadro sinóptico con el marco de Scrum - Cortesía de Scrum Manager

La ejecución de los proyectos se efectuará mediante el marco de Scrum definido en la guía oficial de Scrum Manager. El coordinador será el enlace e interlocutor entre el cliente y el equipo de desarrollo del proveedor.

Quiero resaltar que este post trata de una síntesis en forma de marco de lo que he observado en algunos de los clientes más tradicionales a los que he acompañado. Este "marco" no es un marco ágil ya que no está alineado con todos los valores y principios del Manifiesto Ágil.

Mis agradecimientos a Ramón y a Lorenzo que han trabajado a fondo parte de lo que expongo