Tips for remote meetings

Since I joined Jungheinrich Digital Solutions here in Madrid, I’ve been part of a distributed agile team for a while. I will try to group all the learnings I get being a remote team player:

• Make a sound test at the start for everybody.
• If possible use: a digital kanban board and a Bluetooth mic.
• Don’t limit your self to the board and sounds. For example: use a board (or a wiki page) for the parking slot. If you are the remote attendants you can always use a sheet of paper in front of your camera to mark the main points you are talking about.
• Use visual markers to help people understand what you are talking about (maybe just point to the US/Task, open the ISSUE in JIRA, select the subject, etc.).

Systematic approach on facilitating large agile programs

I would like to start this post with the first step to create a roadmap to help the adoption of Agile at a program level.

By no means this is a finished proposal, please feel free to contribute whatever you need think it is useful. If needed, I will create an entire site to help to develop this adoption framework.

I’ve tried to make this framework as escalation model neutral as possible. It should help any model, if it has a release timebox and sprints.

High level activities

Kickoff

StartPlan

Prepare Launch

Launch

Support during execution

End & Replicate

Manteniendo la calidad bajo el paradigma agile – Regresión funcional continua

Vale, la frase de “Las historias de usuario, una vez completadas, ya se pueden descartar” nunca me convenció. Tenía claro que estaba incompleta, o daba por supuesto alguna otra práctica que haría posible este escenario.

Cosas de la vida, he tenido la oportunidad de colaborar el último año en una gran implantación ágil y contribuir con mi granito de arena a mantener la calidad en un evolutivo de varios millones de líneas de código y más de 100 desarrolladores trabajando bajo el paradigma ágil.

Este va a ser el primero de un conjunto de posts que van a ir en la línea de compartir lo que he aprendido y aquí y allá, y ponerlo todo junto dando una visión real de cómo se está ya resolviendo esto. Intentaré dar una visión extremo a extremo de todo el ciclo de vida.

La primera cosa a tener en cuenta es: “Cuando una historia de usuario termina, nace un test automático en la regresión global”. Este principio, es la base de la práctica que permite descartar historias de usuario, sin que sea a la ligera.

Podría llegar a ser cuestionable el hecho de que “si he roto una historia de usuario anterior, será porque el cliente me lo ha pedido. ¿Para qué quiero este overhead adicional?”. Bueno, la clave está en el pensar en que no está mal romper una historia de usuario adrede, pero existen 2 otros escenarios:

• No ha sido adrede y esto va a generar un problema a otro actor (véase por ejemplo un interfaz con otro sistema).
• No tenía ni idea, fue hace tanto tiempo que ya ni me acuerdo.

En ambos, que en el fondo pueden ser la primera, es importante saber que algo hemos roto y determinar si debe:

• Cambiar la prueba: ya no es válida la historia de usuario y hay que actualizar el caso de prueba para que refleje la realidad.
• Vale, me confundí y mi implementación, aunque cumple con lo que nos han pedido, hay algo que hay que hablar con el cliente.

Lo segundo es también muy importante: “Todos los equipos, todos los días en la daily, revisan la regresión y se auto-organizan teniendo en cuenta este input”. Es curioso, esto tiene mucho que ver con el concepto de “Local continuos integration” que en su momento mi compañero Juan Alonso definió cuando trabajábamos para un gran banco español.

Obviamente no puedo integrar si mi regresión funcional está rota

Esta estrategia no rompe el flujo, y garantiza que fluyan las conversaciones en relación a potenciales defectos cuanto antes mejor.

Empowering the team

Es la típica frase que se lee en toda la literatura sobre agilidad. Pero cómo definirlo. Es algo así como la confianza, y la autoridad derivadas de la naturaleza de las decisiones que el equipo puede tomar por sí mismo. Y el proceso de delegar en los equipos aquellas decisiones que, por su naturaleza, sean más eficientes tomarlas en el seno del propio equipo.

Está claro que no se puede delegar en cada equipo individual todas las decisiones de un proyecto o una compañía.

Sobre las decisiones de compañía hay mucho escrito (planificación estratégica, lean startup, segmentación, etc.).

En esferas más cercanas al desarrollo de software, existen límites más bien naturales que requieren acuerdos entre equipos (por ejemplo talleres Lean VSM para modificar procesos en un value stream, o talleres de Inspect & Adapt en el marco de un programa SAFe). Estos procesos no dejan de ser ejemplos de empowerment pero a una escala superior (equipos operativos en Lean, o programas formados por equipos ágiles en SAFe).

Scrum, entendido desde la óptica de la Scrum Guide, está lleno de aspectos que en sí mismos dan poder al equipo (mi traducción de Empower the team).

1. Equipo auto-organizado y auto-gestionado.
2. Estimaciones realizadas por el propio equipo.
3. Liderazgo servil.
4. La propia dinámica de Retrospectiva.
5. La dinámica del Refinamiento del backlog.

En general, en vez de tomar la decisión en nombre del propio equipo y comunicarla, presenta el problema y da pie a que el equipo decida qué hacer (por ejemplo a la hora de resolver un defecto que el usuario acaba de reportar en pleno sprint).

Si te examinas de la certificación de Profesional Scrum Master de Scrum.org, en general la imposición de decisiones, salvo la cancelación del Sprint por parte del Product Owner, suelen ser una pista de que la respuesta no es correcta.

El líder técnico

El desarrollo de software en el sector financiero no se parece al desarrollo de software que se realiza, por ejemplo, en una startup. Existe una arquitectura corporativa que hay que respetar y ciertos procesos internos que garantizan la correcta convivencia entre sistemas.

En esta ocasión vamos a hablar del rol del líder técnico, en general la persona garante de que se cumplan las directrices técnicas vigentes en el banco durante los procesos de desarrollo, evolutivo, correctivo y perceptivo.

El líder técnico tiene la última autoridad en relación al cómo se hace. Ante conflicto es en última instancia la persona encargada de decir cómo se debe resolver una funcionalidad para que cumpla con la arquitectura y estándares establecidos.

Es un excelente conocedor de la arquitectura actual de los aplicativos y de la arquitectura objetivo a corto, medio y largo plazo.
Es copropietario del backlog junto con el Product Owner o responsable funcional, de tal manera que negocia con este último que porcentaje del backlog debe estar disponible para labores técnicas orientadas a la construcción del Architectural Runaway (piezas de arquitectura que soportarán el negocio futuro).

En el caso de funcionalidades complejas, se encargará de diseñar la interacción de las partes y comunicar adecuadamente dicho diseño.
Por último es la persona de referencia y punto de contacto en todo lo relativo a cuestiones técnicas con otros aplicativos y sistemas.

Agile en el RUN

Facilitar Agile en grupos de correctivo o de evolutivo rápido previo a la puesta en producción no es para nada una labor sencilla.
Dada la especial naturaleza de estos grupos, donde la demanda es imprevisible, resulta extremadamente complejo y contraproducente intentar que se comprometan a completar partes del backlog en el timebox de un Sprint. Por mucho que lo intenten, los fuegos propios del correctivo cambian su disponibilidad continuamente.

Mi experiencia personal en este tema es que resulta mucho más natural utilizar un enfoque Kanban puro. Así estos equipos contarán con su propio sistema Kanban que utilizará 3 líneas de prioridad:

• Urgente: una tarjeta puesta en esta línea de prioridad provocará inicialmente que los miembros del equipo interrumpan su trabajo actual y colaboren en resolverla inmediatamente. Esto no significa necesariamente que todos los miembros del equipo terminen resolviéndolo, si no que potencialmente podrán colaborar puntualmente en la resolución aunque el trabajo final se realice mayoritariamente por un subconjunto de los mismos.
• Importante: un miembro del equipo, una vez termine un ítem de trabajo, si existen tarjetas en esta línea, deberá coger una de ellas.
• Business as usual: las tarjetas de esta línea se completarán en el caso de que no existan tarjetas en las líneas de urgente o importante.

¿Quién programa las tarjetas en las distintas líneas de prioridad? En general el responsable del equipo. Es decir, aquella persona que conoce las prioridades del negocio y está en contacto con él. Normalmente esta persona recibirá las incidencias directamente del grupo de soporte nivel 3, filtrando aquellas que realmente no sean incidencias (pueden ser consultas o problemas de documentación) y colaborando en completar la información antes de que llegue al equipo.

Sigue existiendo la necesidad de contar con un facilitador o coach del equipo. El equipo necesitará ayuda para pasar por las 4 fases y convertirse en un equipo de alto rendimiento, y ese será pues el rol del facilitador.

En cuanto a la documentación a entregar, mi recomendación es que previo al lanzamiento del equipo se realicen talleres Lean de mapeo del flujo de valor (Value Stream Mapping) para aligerar la documentación a entregar a lo que realmente sea necesario.

Comparando SAFe(r) y LESS(r)

Scaled Agile Framework (SAFe ®)	Large Scale Scrum (LeSS®)
Modelo centrado en torno a la ejecución del programa, la alineación común y la calidad.. Representa un mecanismo de entrega y un proceso de fácil comprensión y adopción para organizaciones tradicionales acostumbradas a trabajar en cascada. Facilita las primeras fases de la adopción de la agilidad en las grandes organizaciones. Es un buen modelo para comenzar y luego adaptarse con experiencia.	Basado en un conjunto de principios, modelos, normas, directrices y 600 experimentos que ayudan al cambio de organización. Es similar a tener startups internas, y requiere el contacto directo con el cliente y el negocio. Simplifica las estructuras y permite una mayor orientación del mercado. Es un lugar para buscar respuestas en el viaje hacia la agilidad en grandes organizaciones.

Algunos mitos de Agile

“Agilidad es solo una cuestión del equipo de desarrollo.”

Sin el feedback e implicación del cliente al menos en la priorización y en el feedback tras la demo, nunca se obtendrá los beneficios derivados de agile. Ser agile requiere un cambio cultural.

“En agile no hay gestión del cambio.”

En un proyecto ágil, como en todo proyecto, es necesario justificar los cambios y la inversión, pero la clave está en tener una implementación muy ligera de dicho proceso de gestión del cambio (¿Un acta después de la demo?).

“Los equipos ágiles no entregan documentación.”

Los equipos ágiles consensuan con sus clientes internos la documentación que da valor y la mantienen actualizada en cada Sprint (normalmente se gestiona como cualquier otro activo, creando las correspondientes tareas durante el Sprint Planning).

“El principal objetivo de agile es la reducción de costes.”

El principal objetivo de agile es reducir el time to market de la entrega de valor, a través de un producto completamente adaptando, aprovechando reduciendo así los costes de retraso. Pueden pueden producirse también eficiencias de costes dado que los equipos de alto rendimiento son más eficientes que la suma de sus partes.

 

Continuos deployment, o como no quedarse atascado en Ops

La relación entre Agile, los marcos de escalado y DevOps es una duda recurrente en los primeros pasos de los procesos de transformación.

Scaled Agile Framework (SAFe) (r)  prescribe la entrega de código potencialmente implantable cada dos semanas, sincronizando así a todos los equipos en un programa. Además, también obliga a realizar una demo integrada  al final del sprint. El comité de Release Management analiza si el incremento de funcionalidad es suficientemente valioso para el negocio y si los tiempos son los adecuados. En caso afirmativo pide a DevOps que se inicie el proceso de implantación de la versión entregada. Este segundo proceso, no está sincronizado con la entrega de versión desde desarrollo, y se realiza en función de las necesidades del negocio. Pero ¿cómo opera DevOps?

Esta parte, en la versión 3.0 de SAFe, no está totalmente especificada, pero utilizamos la forma de actuar del equipo de ingeniería de Rally como base para plantear una alternativa base para nuestros clientes.

Es un proceso a medio plazo y requiere un nivel de madurez elevado. Inicialmente no todo el mundo está preparado para que el proceso de puesta en producción este gobernado por la automatización, verificado por pruebas automatizadas y frameworks de monitorización de servidores de producción.  Normalmente, estas fases del proceso de transformación se realizan al final del propio proceso.

Se trata de pasar del concepto de integración continua al deployment continuo. Aquí inicialmente es necesario distinguir código y servicios de infraestructura de servicios de presentación. Obviamente la automatización de los servicios de presentación requiere la intervención de gente de usabilidad, y por lo tanto es normalmente mucho más complicado automatizar dichas pruebas. De intentarse esto, es recomendable hacerlo al final y definir procesos de inspección humana antes del lanzamiento del pipeline de deployment.

Atacar la automatización del pipeline de deployment para servicios de infraestructura es sustancialmente más sencillo, y permite obtener experiencia y lecciones aprendidas más fácilmente. No todos los procesos de deployment son iguales y es necesario comenzar con algo manejable para entender y optimizar el proceso.

Se trata de identificar un equipo que normalmente entregue código de infraestructura (inicialmente suele ser el equipo de sistema) y comenzar a analizar todo el pipeline que tiene desde que la tarea es terminada en el IDE del desarrollador hasta que llega a estar disponible para el usuario final.

Identificaremos  trabajo sin valor para proponer su eliminación, y trabajo automatizable para proceder progresivamente a su automatización. Al menos deben estar automatizadas las pruebas unitarias y las de integración, junto con las de regresión. Esto asume que el equipo usa TDD y entrega con el código pruebas funcionales suficientes para verificar la funcionalidad (como se hace el SAFe). Es altamente recomendable que se audite la cobertura de dichos sets de pruebas, y se establezcan límites razonables de cobertura comprobados previamente antes de la puesta en producción.

Además, se añade un paso adicional de pruebas que tiene más que ver con verificar el compliancy de los propios servidores de producción (puertos abiertos, configuraciones, etc…). Esto también se automatiza en el pipeline de deployment.

A partir de ahí, una vez que el comité de Release Management dé su aprobación, podemos llegar a poner en producción varias versiones al día como hace Rally.

DevOps es la manera de acortar los ciclos de feedback para entregar valor antes y reducir el coste del error. Sin esto, ¡el valor que generan los equipos ágiles puede estar atascado en Ops!

Modificaciones contractuales para facilitar la aplicación de SAFe(r)

Actualmente en España los grandes proyectos se estructuran entorno a las relaciones contractuales que la empresa cliente tiene con sus proveedores de confianza. A la hora de implantar metodologías como SAFe es necesario cambiar el marco de las relaciones contractuales de dichas empresas para permitir la flexibilidad necesaria para trabajar en un programa ágil.

El problema a resolver es cómo regular contractualmente unas responsabilidades dinámicas que se determinan cada 6 meses en el Release planning.

El planteamiento de esas relaciones contractuales ha de ser multi-nivel. Mi planteamiento es que el resultado del propio Release planning sea convertido en un contrato que se acepte por parte de ambas partes de manera ágil y automáticamete. No queremos burocratizar la relación, pero ambas partes deben regularse contractualmente.

Así deberá existir:

A) Un contrato marco que regule la relación general entre la empresa proveedora y el cliente. En este contrato marco deberán regularse los factores tales como formas de pago, garantías, y demás factores que regulan la relación administrativa y comercial entre ambas empresas.

B) Existirá un anexo a nivel de programa (uno específico por programa donde el proveedor va a trabajar), donde ambas partes añadirán las clausulas necesarias para la correcta colaboración dentro del programa en concreto. En este caso, para aplicar SAFe, será necesario que se garantice la presencia del proveedor en el reléase planning, la obligatoriedad de la cadencia de desarrollo, las políticas de Green build que rigen el programa y el uso de las herramientas y estándares que son propios del programa. Este contrato podrá conllevar la tarificación por perfil de los recursos que el programa requiera.

C) Cada release planning generará un anexo del contrato directamente a partir de la matriz de equipos sprints de la versión. Es decir, tras el proceso de planificación conjunta añadiremos una fase administrativa que convertirá en contractual los compromisos que el equipo del proveedor ha adquirido con el cliente y con el resto de los equipos. Mi recomendación es permitir la facturación por hitos, donde el hito es la demo integrada y la aceptación del PM del trabajo realizado contra las especificaciones iniciales.

Esto no excluye una gestión de cambios orientado a la compensación de cambios y ampliación de los mismos. Factores como la garantía deberán regularse adicionalmente, sobre todo en el momento en el que el proveedor deje de trabajar en un programa.

Aunque una organización por componentes no es la idónea, en este caso facilitaría este tipo de aspectos.