Partiendo de cuatro aseveraciones, que se clarifican con doce principios, la industria del desarrollo de software lleva casi dos décadas en medio de una revolución de los procesos productivos, a la búsqueda de implantar las filosofías y metodologías Agiles.
Algo que, como bien conoce todo aquel que tenga experiencias personales de este tipo, es especialmente difícil conseguir que funcione correctamente. Incluso si nos decantamos por un framework tan abierto y generalista/ambiguo como pude ser SCRUM.
Además, hay que abarcar una complejidad creciente en la aplicación de este manifiesto, al desarrollarse a su alrededor una miríada de procesos, buenas prácticas y metodologías que se muestran como un impedimento de primer orden para llegar a buen puerto con la adopción Agile.
Fundamentos
Cuatro simples frases que comprenden un universo de sentido común y experiencia aplicado a la construcción de software. Cuatro profundas declaraciones que recuerdan, de forma constante, donde está el valor.
Cuatro declaraciones sencillas, y desde las cuales se ha creado un gigantesco mapa de principios, valoraciones, interpretaciones, prácticas, mejoras, evoluciones y puntualizaciones.
Cuatro comparaciones de valor, que debieran ser la medida sobre las que debiéramos dilucidar las dudas que surjan sobre la adopción de Agile en nuestros procesos de construcción.
A partir de estos fundamentos, el manifiesto Agile describe 12 principios que son normas de aplicación de los procesos agiles en nuestros equipos de desarrollo. Incluyendo en ellos, toda la experiencia atesorada por profesionales y metodologías ya reconocidos en el momento de la redacción del propio documento.
Y ya está, cuatro fundamentos junto con doce principios y una metodología – más bien framework – como Scrum, y es todo lo que necesitamos para adoptar el Agilísimo en nuestro equipo.
Pero no es así…
PBI, o el principio del infierno
Olvidémonos del principal problema que nos encontramos cuando queremos aplicar una metodología Agile como Scrum, que no es otro que la práctica inexistencia del Product Owner o Dueño del Producto. Por lo cual el fundamento de “Colaboración (cercana) con el cliente” se queda en agua de borrajas en demasiados casos, emergiendo figuras parcialmente supletorias como los proxy.
Y ahora centrémonos más en técnicas específicas como son los PBI (Product Backlog Items), artefactos que vamos a utilizar para construir nuestra Pila de Producto en donde se segmentará el valor que espera el cliente, de forma priorizada.
La aproximación es relativamente sencilla: vamos a construirlo por medio de Historias de Usuario. Pequeñas cartulinas o post-tip, en donde utilizaremos la fórmula de las 3 C’s: Card, Conversation y Confirmation
Es decir, la primera C la cubro en el formato clásico de: Cómo tal, Quiero hacer…, Porqué/Para que me aporte este valor... La segunda ce sería el cuerpo de la documentación en donde almacenaría todos los recordatorios de la conversación en cualquier formato que me sea útil. Y la tercera significa que debo dejar claros los criterios de aceptación que van a permitir dar por válida la realización de la Historia de Usuario.
También debo de estar seguro que mis Historias de Usuario cumplen con el acrónimo de INVEST: Independiente, Negociable, Valiosa, Estimable, Pequeña (Small) y Testeable; para asegurarme que son correctas y útiles en su función de describir cada requisito.
Y, además, debo de poder priorizarla por el valor que aporta (Product Owner) y por estimación (Develop Team) para poder comprometer un número dado de PBI’s en cada sprint.
Esto significa que el equipo de Scrum debe de conocer técnicas de estimación Agiles, como puede ser Wall, Triangulación o similares, que permiten hacer estimaciones iniciales de un gran número de PBI.
Aplicando a su vez, técnicas de estimación específicas para el sprint planning, como es el Planning Poker. Que son mucho más lentas, a cambio de obtener estimaciones bastante más afinadas, siguiendo lo esperado en un gráfico de cono de incertidumbre.
Pero volvamos con nuestras Historias de Usuario y veremos cómo las podemos mejorar. Aplicando técnicas de Desing Thinking lograremos una construcción más completa de nuestros PBI, incluyendo prácticas como los storyboards, story telling, mapas de empatía, pitch elevator y una miríada más.
¿Y si la historia de usuario es muy grande? ¡No hay problema! Utilizaremos agrupaciones por medio de Historias de Usuario Épicas o también Features. Que, ojo, a su vez tiene su técnica para ser subdivididas de forma eficaz. Eso sí, apliquemos el concepto Lean de evitar el Waste y solo poner foco en lo que aporte Valor, y breguemos con tareas no funcionales o con bugs que deben de aparecer en algún lado, pero no en el Product Backlog… ¿o sí?
Como es inevitable, en este punto nacen diferentes escuelas para abordar este tipo de disyuntivas de procesos que, en realidad, al cliente se la traen al pairo. Pero son críticas para el equipo de desarrollo.
Así vemos que algo tan simple como una lista ordenada de tareas, en la realidad se ha convertido en un artefacto complicado de construir y mantener de forma eficiente en los proyectos Agiles; tanto por el trabajo a tiempo completo que requiere durante todo el proyecto, como por el abanico de conocimientos que parece de obligado estudio.
Y sin tener en cuenta todas la técnicas psicológicas, sociológicas y tecnológicas que existen para el proceso de captura y diseño del producto. Entre las que nos encontramos con el reconocido brainstorming, el foco en la pregunta, los 5 Porqué, las 5 E’s, Descubrimiento por Hipótesis, MVP, y un largo etc.
De la mejora continua al coaching
Vamos un paso más allá, y hemos arrancado nuestro Scrum. Tenemos un Product Backlog y un Product Owner, listos para empezar a trabajar, y arrancamos nuestro sprint con todas las liturgias asociadas a framework.
Pero uno de los objetivos clave de Agile es establecer un marco de mejora continua en donde, al final de cada iteración, el equipo sea capaz de detenerse, reflexionar, sacar conclusiones y comprometerse a realizar acciones. Es decir, la retrospectiva.
Pues bien, hay suficientes técnicas de esta liturgia, que podríamos escribir existen multiples libros dedicados totalmente a cómo aplicar de forma eficiente esta reunión en el transcurso del proyecto. Así te encuentras con técnicas como la de “Estrella de Mar”, “Barco de Vela”, “6x3x5”, “Mad, Sad, Glad”, “Positivo, Negativo, Delta, Flor”, “Esqueleto de Pescado”, Timeline”, etc.
Incluso podemos ir varios pasos más allá, muy “Lean”, en donde entramos en medidores de la felicidad del equipo, del departamento o de la empresa. Con propuestas tan sencillas como puede ser un calendario Niko-Niko y sus caritas emocionales.
Y con la filosofía y el psicoanálisis hemos topado. De forma gradual pero consistente se ha implantado el uso de conceptos filosóficos y de mejora continua proveniente de procesos industriales y empresariales para aplicarlos en ámbitos mucho más allá de la mera construcción del software, origen de todo este tinglado, abarcando la cultura de la empresa en su globalidad y la vida diaria en lo más personal e íntimo.
Hemos visto surgir profesionales en técnicas de coaching (el entrenador, en roman palantino), llenándonos la cabeza y los sentimientos de buenos propósitos y deseos de mejora.
Verdaderos guías que nos acompañan en el camino para llegar a un éxito inaplazable, y que han convertido conceptos de crecimiento como “Kaizen” o metodologías cual “Lean”, en el centro neurálgico imprescindible de alcanzar, para poder aplicar de forma correcta y emergente los principios Agiles.
Por supuesto, los libros y conocimientos necesarios se van acumulando, los cursos se suman los unos a los otros, y las certificaciones cierran el circulo al validar el conocimiento y experiencias adquiridas.
Del tablero al universo “Kanban”
Una de las herramientas más conocidas del mundo Agile es el tablero Kanban, en su vertiente Scrum. Una forma visual de describir el flujo de trabajo, el estado de las tareas, de los bloqueos que existan o puedan existir, y de los puntos de mejora en el ciclo.
En definitiva una forma muy eficaz de auto organización y colectivización de la información.
Debería ser suficiente con un tablero físico, dibujar cuatro columnas, subdividir y priorizar las tarjetas con la descripción simple del trabajo a realizar para cada PBI comprometido durante la iteración actual, un visión u objetivo del sprint, y tener muy claro el concepto de Done que permite asegurar el finalizado un trabajo.
Pero ya que estamos, podemos añadir las capacidades push & pull del movimiento de las tarjetas, la subdivisión, el WIP o la división horizontal, para obtener un tablero “Kanban” más rico y con más capacidad de mostrar el flujo.
Y aún más, aplicar las técnicas “Just In Time” que desarrolló Toyota hace décadas (primera descriptora de la metodología Kanban), en nuestro proceso de desarrollo; y terminar siguiendo los siete principios de la versión occidental llamada “Lean”:
- Eliminar los desperdicios
- Ampliar el aprendizaje
- Decidir lo más tarde posible
- Reaccionar tan rápido como sea posible
- Potenciar el equipo
- Crear la integridad
- Véase todo el conjunto
Los cuales -a su vez- se complementan con múltiples prácticas, que también han ido evolucionando en el tiempo de la misma forma que ha ganado complejidad en su entendimiento, aplicación y uso.
Escalando Scrum y usando otras metodologías
Es cierto que Agile, y en especial Scrum, están orientado a equipos pequeños de alto rendimiento, experiencia y calidad técnica. Pero desde hace años se está aplicando a proyectos grandes, en donde decenas de personas deben participar en los trabajos.
Así surgen metodologías que han evolucionado el framework para que pueda funcionar, más o menos deformado, en estas circunstancias.
Scrum of Scrum, Scaled Agile Framework (SAFe), Large Enterprisse Scaled Scrum (LeSS) o Disciplined Agile Delivery (DAD), abordan las complejidades inherentes de escalar procesos que fueron diseñados, inicialmente, para equipos y proyectos perqueños.
Además, debemos de tener en cuenta que también existen metodologías Agiles más allá de Scrum, que son más concretas y que plasman los principios Agiles de una forma mucho más detalla.
Tenemos Extreme Programming (XP) pone mucho el foco en el desarrollo y en los desarrolladores. Haciendo natural utilizar técnicas como la programación en parejas o el desarrollo guiado por pruebas (TDD) para que emerja la arquitectura de manera orgánica y se limite la complejidad.
También tenemos DSDM, que es una metodología “pesada” Agile. Es decir, describe todos y cada uno de los procesos que se han de implantar, de forma detallada y con el objetivo de conseguir una empresa Agile.
Nacida en los años 90 por un consorcio de actores en el desarrollo de Sistemas de Información, añade conceptos orientados a la gestión del riesgo, la estimación y la presencia de la parte de negocio empresarial, para complementar y enriquecer una construcción Agile de proyectos.
O Crystal Clear, conjunto de metodológico que va cambiando de color según el tamaño del equipo, y de color según la criticidad de los errores. En ella se pone al equipo humano como centro de todo y se va incrementando la complejidad en los procesos según va creciendo el volumen de personas participantes.
Sin olvidar FDD (Featuren-Drive Development), también pensada y diseñada para equipos grandes o sin madurez suficiente de auto organización, en donde se describen cinco procesos que (hay que reconocerlo) son de lo más realista y pragmático de entre las metodologías Agiles.
Es cierto que para los que estamos acostumbrados a Scrum o “Scrum But” nos rechina una figura similar a un “Jefe de Proyecto” o a un Arquitecto, pero es otra aproximación salvaguardando los fundamentos y principios de Agile.
Propuestas de solución:
A todo este conocimiento, que debiera tener aprendido e interiorizado los equipos de trabajo, debemos añadirle la complejidad creciente del desarrollo de software.
Una carrera en donde continuadamente el profesional debe encontrar -casi a ciegas- cuál es el punto justo de equilibrio entre lo conocido y lo novedoso. Qué ventajas ofrecen los nuevos framework que aún está de moda, en comparación con el código aburrido, consistente y confiable con el que podemos abordar nuestras construcciones.
Y que, a su vez, implica que debiéramos estar permanentemente reciclándonos y aprendiendo en un torbellino constante que deja tiempo para muy poquitas cosas, cuidadosamente priorizadas.
Lo cual todo, junto con lo mucho que se ha quedado fuera del artículo, está significando que el grado de implantación positiva de Agile en las empresas esté siendo inferior a las previsiones que se tenían hace unos pocos años.
Arrancar con muchos bríos, pero con una enorme cantidad de normas, preceptos, filosofías, técnicas, prácticas y actividades, es un buen camino hacia el desastre o – aún peor – la inutilidad.
Tal vez, una buena propuesta sea aplicar a rajatabla el viejo concepto de los años 60: KISS (Keep It Simple Stupid).
Aplicando las liturgias de Scrum en su forma más básica y de forma iterativa de acuerdo a la madurez del equipo; revisando sobre los cuatro fundamentos del manifiesto, si realmente es necesario ganar un gramo de complejidad en pos de una mejora; y, en caso de nuevas adopciones en los procesos, estar plenamente justificadas y comprendidos los porqué.
Buscando un Coach, empecemos por acostumbrar al equipo a trabajar con un tablero físico Scrum (tareas y sprint), luego introduciremos las retrospectivas para que emerja la mejora continua; la Pila de Producto será imprescindible rápidamente para que el equipo pueda iniciarse en la auto organización; y todo ello debiera desembocar en las liturgias del Sprint Review y el Sprint Planning.
Si no ves claro algo o es dificultoso, como puede ser estimar por puntos, empieza por horas ideales (que es imperfecto y produce disfunciones); recuerda que lo importante no es la técnica, si no entender por qué estimar, cuando (si es necesario) y de qué manera.
No entres en otros conceptos hasta que tengas pleno dominio de los fundamentos y principios Agiles. Ya habrá tiempo para mejorar, y las retrospectivas te van a ir llevando a ello.
Reflexiona sobre que lo que menos valor aporta son los procesos y herramientas; que ser un especialista en Thinking Design es una gran ventaja en un nivel de madurez y adopción Agile medio, pero que lo verdaderamente importante es describir el trabajo con el detalle mínimo suficiente como para que el equipo de desarrollo se pueda auto organizar.
Funciona, a pocos, pero funciona
La pregunta que me hacen muchas veces es: ¿Pero es posible? ¿Funciona? Y la respuesta es un rotundo “depende”.
Si aplicas una metodología muy experimentada y madura como Scrum, tienes más posibilidades ciertas de conseguirlo. Lo difícil es continuar poniéndolo en práctica una vez que el coach o el tutor se haya alejado del proyecto. Demasiadas veces nos devora el día a día, los plazos y los costes, perdiendo el foco en lo importante que es seguir aplicando los fundamentos Agile al desarrollo de software.
Pero sí que hay empresas, muy pocas en comparación con la generalidad, que aplican metodologías Agiles y les funciona; construyendo equipos altamente motivados, y por ende productivos.
La pena es que aún hay más que, o no quieren salirse de sus procesos (o no-procesos), o las que lo intentaron, pero las dificultades en su implantación y continuidad de uso, las llevaron a fracasar y a no querer volver a “meterse en jaleos”.
Sin duda la complejidad de un crecimiento expansivo de los conocimientos necesarios para aplicar “bien” Agile, se ha convertido en el mayor hándicap para su implantación. Por ello tal vez el camino sea el abordarlo desde la simplicidad y la reflexión continua sobre los cuatro fundamentos.
Ir poco a poco.
En GenbetaDev | Retos de la agilidad en empresas grandes, Modelos de aprendizaje para el programador ágil ¿Cómo ser efectivo en nuestro aprendizaje constante?, DevOps. ¿Moda, mito o evolución?
Imagen de portada | Deloitte
Ver todos los comentarios en https://www.genbeta.com
VER 0 Comentario