Muchos de nosotros cuando hemos hablado con una compañera o compañero nos ha narrado cómo hacen Scrum en su empresa: “tenemos una Daily donde el Scrum Master nos dice las tareas y cada uno explica lo que está haciendo”. Estos ejemplos son los llamados “Agile Smells”, aquellos que, de lejos, sospechas que solo usan de Agile lo que les interesa. El problema de estos Agile Smells es que generan en la industria muchas dudas acerca de las bondades de trabajar con el mindset Agile. Precisamente, Agile trata de enfocar los problemas con una estrategia adaptativa sobre la predictiva clásica. ¡Analizamos los principales Agile Smells!
Fecha y Alcance Cerrados
En el mundo existen fechas y no podemos ignorarlas. Scrum por ejemplo propone usar esas fechas para maximizar valor. Ahora bien, en el momento en el que el Alcance y la Fecha se cierran, acabamos poniendo toda nuestra energía en cumplir con el plan mágico que definimos cuando apenas teníamos experiencia resolviendo el problema
La Fecha o el Alcance (o ambos) deben ser abiertos para que podamos maximizar valor. Si tenemos una fecha final trataremos de aprovechar al máximo el tiempo disponible. Si, por contra, tenemos un determinado producto que desarrollar (como una vacuna) entonces estará cuando lo finalicemos, la fecha deja de ser relevante.
Cuidado, que no haya fecha y alcance cerrado no significa que ignoremos el coste incurrido y que podamos abandonar un determinado producto si no está otorgando resultados esperados.
Falta de Test Automáticos
Cuando aplicamos Agile en el mundo del desarrollo software (de dónde surgió) debemos tener en cuenta que la calidad es un punto muy relevante. Los Test Automáticos son básicos para garantizar que nuestro producto funciona cómo esperamos y para adelantarnos a errores. Los productos con ausencia de test pueden funcionar pero suelen generar muchas incidencias que después hay que solucionar y que, mientras existan, transmiten un pésimo servicio al usuario final.
¡Cuidado! si fuéramos más allá, realizaríamos un Desarrollo Manejado por Test (Test Driven Development) pero tampoco podemos obligar a un equipo Agile a que lo haga.
Waterfall en Sprints
Cómo ampliación del primer punto. Muchas empresas trabajan con un Waterfall más o menos explícito. Después, tratan de introducir Agile para que su Waterfall funcione. Trabajar durante meses en Sprints buscando alcanzar una determinada fecha y alcance no es parte del mindset que propone Agile.
Recordemos que el objetivo de Agile no es hacer eficiente tu empresa, sino que debes cambiar tu empresa para que sea eficiente. ¡Es un cambio de paradigma!
SAFe
Debo admitir que incluir a SAFe como un Agile de Mier** puede generar cierta polémica. SAFe es un marco de escalado que ha sido vilipendiado por casi todos los firmantes del manifiesto Agile. Muchos argumentan que es excesivamente complejo, otros que sigue proponiendo una cierta jerarquización de las organización en vez de buscar la adaptación contínua.
Desde mi perspectiva, SAFe está incluyendo todas las palabras de moda que existen actualmente. Por ejemplo, ahora ha incorporado Inteligencia Artificial u OKR. Después, te propone que “cojas lo que necesites”. Para mí, una propuesta Agile tiene que ser aterrizada, debe mojarse, y debe demostrarte que tu capacidad de adaptación mejora.
Equipo de QA
Cómo decíamos, la Calidad es clave en la Agilidad para ser más rápido adaptándose. Un equipo de calidad no es malo pero separamos en un silo la calidad. La calidad es parte de las tareas de un producto y las personas que sepan hacerlo deben pertenecer al equipo. Por eso, tener equipos de especialistas dificulta nuestra agilidad.
Esto de equipos de QA se puede extender a más disciplinas: equipos de UX, equipos de Analistas, Equipos de Soporte… ¡Tenemos que ser un único equipo con capacidad de entregar valor!
Ausencia de Métricas de Negocio
Un equipo debe ser capaz de adaptarse para generar valor de negocio. Los equipos que solo miran a una fecha y un alcance y no al resultado real que su trabajo provoca siguen siendo equipos tradicionales. Parte del cambio de mindset consiste en orientar los equipos a resultados.
Muchos equipos deberían tener consciencia de los resultados económicos que su trabajo provoca. Sin una visión de negocio muchas veces tomamos decisiones sin tener en cuenta el impacto real de las mismas.
Hablar poco con el usuario final
Para poder adaptarnos debemos ser capaces de resolver problemas por los que los clientes paguen. Un cliente es algo más que una empresa que nos contrata, son los usuarios cuyo producto estamos desarrollando los que deben intervenir en su producto. Un equipo Agile trata de hablar con sus usuarios de muchas maneras. Tener al usuario presente es clave para adaptarnos y generar el máximo valor posible.
En productos con usuarios masivos buscaremos la manera de obtener feedback. Pueden ser métricas de uso del producto, encuestas de feedback o foros de propuestas. Hay muchas maneras de entender a tu usuario y hacerlo partícipe si realmente tienes esa intención.
Micromanagement
Una de las características clave que propone Agile son los equipos autoorganizados. Cuando nos enfrentamos a problemas complejos la solución se encuentra en la inteligencia colectiva de un equipo. Si una organización apuesta por Agile debe confiar en sus equipos y dejarles organizarse. En el momento en el que implantamos métricas o sistemas que “persiguen” contínuamente a los empleados para garantizar que trabajan acabamos invirtiendo más tiempo en controlar que en generar valor.
Agile, y en concreto Scrum, proponen dejar a los equipos sin esa supervisión pero con una revisión periódica de resultados en la que los equipos demuestren su capacidad de generar valor. Es decir, no te controlo el día a día pero me siento contigo a estudiar los resultados de tu trabajo.
Agile Project Manager
La figura del Project Manager (Jefe de Proyectos) ha sido un pilar fundamental de muchas empresas. Eran las personas responsables de un determinado Proyecto, la pieza clave para avanzar trabajo en las organizaciones. Sin embargo, los proyectos siempre han dado problemas: plazos que no se cumplin, sobrecostes, personas que rotan mucho, horas extras… ¡Necesitamos un cambio!
Es ahí cuando queremos incorporar Agile como disciplina pero sin cambiar nada. Por tanto, etiquetamos al Project Manager con la palabra Agile para que parezca que somos ágiles. La realidad es que Agile propone ser adaptativo y el Project Management busca cumplir con un plan que definimos antes de empezar.
Unir ambos mundos se antoja difícil más allá de algunas prácticas. El problema radica en la naturaleza intrínseca de ambas disciplinas.
Factorías Software
Una de las prácticas más extendidas en las empresas consiste en externalizar su desarollo software para abaratar costes. Empresas cuyo core de negocio no es el software, siempre han visto la informática como un gasto que había que reducir y dejar fuera. Esta idea ha cambiado con el tiempo, gracias a la Transformación Digital y la importancia de Internet en nuestras vidas.
Sin embargo, muchas empresas siguen usando las Factorias Software como mecanismos para resolver sus problemas digitales. Estas factorías generan dependencias que dificultan o imposibilitan la adaptación por toda la burocracía y problemas comunicativos que generan.
Recordemos que, cuando en Agile se habla de comunicación cara-a-cara, no es una crítica al teletrabajo sino a este tipo de empresas alejadas de nuestra realidad.
Estimar
Debo de admitir que este concepto no tiene porqué ser un Agile de Mier** pero en la mayoría de los casos lo acaba siendo. Hace pocas semanas hablamos en el blog de que Agile no consiste en estimar mejor. La estimación es una actividad que el ser humano hace contínuamente. Por tanto, tampoco podemos calificarlo de algo malo.
El problema radica en la idea de querer estimarlo todo antes de arrancar un determinado trabajo. Esa estimación, además, conlleva que se acaben tomando decisiones importantes en base a unos datos que nos hemos inventado.
Estimar se basa en predecir el futuro y Agile funciona a base de adaptarte con tu realidad no de estimar cómo será.
Delivery Tras muchos Meses
La entrega es una de las claves de Agile. Cuando entregamos, aprendemos, obtenemos feedback, mejoramos la relación con nuestros clientes y avanzamos. La entrega es la esencia de Agile y, sobre todo, de Scrum. No todos los contextos permiten una entrega continua por tanto, puede haber equipos ágiles sin ello.
Ahora bien, un equipo que realiza entregas tras varios meses acabará por perder gran parte de los beneficios de la agilidad. Un equipo Agile sin entrega es un equipo ciego que no sabe si está en el camino correcto para entregar valor.
Cambios Gratis
Uno de los motivos principales por los que muchos clientes demandan Agile es por los “cambios gratis”. Ahora pueden exigir un determinado proyecto con fecha y alcance y, gracias a que somos “ágiles”, solicitar cambios continuamente.
Cuidado, cambiar es positivo siempre que busquemos con ello una oportunidad para entregar más valor. Solo tiene sentido si con ellos conseguimos mejorar. Ahora bien, cuando convertimos el “cambio gratis porque somos ágile” es una excusa para convertir nuestro equipo en un caos constante, se acabó la agilidad.
Retrospectivas sin acciones de mejora
Las retrospectivas son uno de los elementos favoritos por las personas que conocen Agile. Es un espacio de reflexión donde trabajamos cómo hacemos las cosas para encontrar puntos de mejora. El problema con la retrospectiva es que se convierten en pozos de desesperación y sufrimiento donde acudimos a quejarnos.
Una buena Retrospectiva puede tener una zona de escucha y queja pero, siempre, debe acabar con un plan de acción para que esos impedimentos se puedan superar o acomodar y salgamos adelante. Un equipo que no acciona cambios nunca mejora y, por tanto, es poco adaptativo o Agile.
Autogestión con un jefe/a
Por último, uno de los favoritos y que más “gracia” me hacen. Está muy de moda el concepto de autogestión y de las organizaciones Teal. Sin embargo, te encuentras equipos teóricamente capaces de tomar decisiones pero que cuentan con algún tipo de Jefe/a. A veces es la figura de Product Owner, otras veces el Scrum Master y otras un Technical Lead.
Sea como fuere, si una persona tiene que gestionar al equipo, entonces no son un equipo autogestionado. Sin autogestión, es muy difícil que un equipo encuentre el pulso que necesita para entregar valor.
Y tú, ¿Cuáles de estos Agile de Mier** has visto?
Buenísimo!!!!