• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Jerónimo Palacios Vela

5 argumentos en contra de usar Scrum

Durante los últimos meses he observado un cierto encarnizamiento en torno al debate sempiterno de las metodologías ágiles y en especial de Scrum del que he preferido mantenerme a distancia.

Este tipo de debates no es nuevo y creo que cada dos o tres años experimentan un renacimiento a causa de la decepción que muchas personas experimentan con los métodos ágiles.
​
El objetivo del presente artículo hoy es dar contexto a los argumentos en contra de Scrum, en un intento de intentar ayudar a entender qué es y qué no es.

Me he centrado en cinco: La excelencia técnica, el rol del Scrum Master, el intrusismo, la mercantilización de las certificaciones y la muerte de Scrum.

Scrum no promueve la excelencia técnica.

Muy cierto. Ningún equipo de desarrollo de Software que hiciera una basura de producto con clases de mil líneas, acomplamiento extremo, spaghetti code y cuyo concepto de test es “funciona en mi máquina”, tras aplicar Scrum, han conseguido ninguna mejora.
​
Es más, muchos de ellos, debido a la presión inherente al proceso de Scrum, han terminado haciendo cosas incluso peores, fruto de una falta absoluta de orientación a producto y una Definition of Done.
​
Porque puedes coger cualquier cosa en este mundo, y de la forma más amateur del mundo, destrozarla y decir que no promueve lo que tu quieres que promueva.
​
Y eso está bien, porque Scrum no promueve la excelencia técnica. Son las personas que hacen Scrum las que tienen que promover la excelencia técnica. En concreto el Equipo de Desarrollo (Dev Team).

No concibo trabajar en 2020 con un equipo que no entienda cómo escribir buenas Historias de Usuario ayuda a dirigir una arquitectura hexagonal u onion. Tampoco que no entendamos las bondades que aporta reducir los ciclos de feedback a través del uso de herramientas de integración y despliegue continuo como Azure. O del uso de telemetría para identificar quick wins y el impacto que el software que escribimos tiene en el valor que nuestros usuarios perciben.

Azure application insights permite integrar telemetría de la aplicación directamente en Visual Studio

Que Scrum no hable específicamente de excelencia técnica no significa que Scrum excluya la excelencia técnica.

Significa que es un framework ligero, usado en multitud de industrias y sectores en todo el mundo; como tal, es imposible describir todas las opciones que existen para mejorar la excelencia técnica sin caer en el error de intentar hacer el diccionario Larousse del Scrum: Una iniciativa noble, épica pero inútil.

​
El Scrum Master es un rol, no es una persona.

Totalmente cierto. Y todavía no he encontrado quien diga lo contrario. Sin embargo, es habitual que dada la naturaleza física del mundo, el rol del Scrum Master termine realizándolo una persona y no el espíritu santo.

Es más, debido al caos que suele generar un cambio de contexto continuo en caso de que una persona comparta varios roles, muchas de esas personas querrán dedicarle tiempo completo al rol, mientras que otras no.

El tiempo que le dediquen afectará a la efectividad del rol.
​
También afectará a la efectividad del rol la capacidad y el conocimiento que la persona o personas que ejerzan el rol tengan sobre Scrum y sus posibles consecuencias o ramificaciones.

Si su exposición a Scrum está limitada al popular episodio: “Peppa Pig y su familia desarrollan Software usando Scrum” es posible que su capacidad de entendimiento esté limitada por una falta de conocimiento sobre las consecuencias de hacer Scrum.
​
E incluso así, se puede hacer Scrum.

Igual no es un Scrum maravilloso que además cae en los problemas expuestos en el punto anterior pero la naturaleza de Scrum, que es ser libre para ser usado por quien quiera, permite usarlo.

Los Scrum Masters y Product Owners no han programado nunca. Son unos intrusos.

​
​Bingo, otra en la frente. Ahora mismo hay muchas personas ejerciendo el rol de Scrum Master, Product Owner, enseñando Scrum y certificando gente que no tienen ni idea de programar.

Es más, hay organizaciones y partes de organizaciones con cientos y miles de personas que no producen software utilizando Scrum.

E incluso hay personas que utilizan Scrum o partes de Scrum en cosas que no tienen nada que ver con la Tecnología.

Este es precisamente uno de los motivos por los que Scrum es tan popular. Porque no tiene una legión de policías diciéndote lo que no puedes hacer sino que son unas reglas de juego que puedes utilizar para múltiples cosas.
​
Y no sólo hay personas haciendo Scrum en equipos de tecnología que no saben programar. Hay CTOs, CIOs, Development Managers, Arquitectos de Software e incluso programadores que no tienen ni idea de programar.
​
Por un lado, yo nunca contrataría a un Scrum Master para trabajar con un equipo de tecnología que no tiene un conocimiento mínimo de Software. Y si ese es el caso, le invitaría a hacer al menos dos o tres cursos de los miles gratuitos que hay en línea para que aprendiera qué es programar, para qué sirve el control de versiones o por qué una arquitectura monolítica puede superar en beneficios a una de microservicios en equipos pequeños y cross-funcionales.
​
Por otro, los técnicos tendemos a pensar que el valor de nuestro Software reside en el código. Y el ciclo de vida del Software es mucho más que eso. Podemos hacer un código maravilloso y ofrecer cero valor a nadie. En la mayoría de los casos hacen falta personas de producto, de proceso, de operaciones, de administración de sistemas, de marketing, de ventas y de administración para ofrecerle valor a alguien.
​
Los programadores hemos de dejar de estar enamorados del código que escribimos y empezar a enamorarnos del valor que el código que escribimos crea.

​
El mercado de Scrum y las metodologías ágiles se ha mercantilizado. Las certificaciones no valen nada.

Absolutamente cierto. En la fiebre del oro del lejano Oeste quienes tenían ganancia asegurada no eran los buscadores de oro, sino los vendedores de palas.
​
Lo cual no quiere decir que no hubiera buscadores de oro que no se hicieran tremendamente ricos.
​
Hoy en día hay compañías completamente alejadas de estos debates que están usando Scrum para ser tremendamente ágiles: competitivos, adaptativos e innovadores.
​
​Durante una reunión en 2015 a la que asistí en Boston, cuna de Scrum, descubrí que existe un acuerdo total entre las compañías certificadoras para identificar a individuos influenciables y a través de campañas dirigidas de Facebook Ads, anuncios en conferencias ágiles y una campaña orquestada por redes sociales, fabricantes de post-its, rotuladores y el lobby de las jirafas, para certificarlos a todos. Todo se hizo con conocimiento del club Bilderberg y la aprobación del Conde Drácula y Don Pimpón.

A pesar de que alguien haya leído el párrafo anterior y le haya dado un vuelco al corazón – ¡Lo sabía! – es ironía. Lo cual no cambia el hecho de que Scrum se haya mercantilizado.
​
No hay más que crear una sensación de demanda para dirigir un comportamiento.

No es nuevo.

En 1775 se hizo en Francia para fomentar el consumo de la patata, que se veía como un alimento para el ganado.
​
Las compañías, sobre todo en el último lustro, han demandado más profesionales con conocimientos de Agile. Y Agile se ha asociado tradicionalmente a Scrum. Es por ello que han surgido cientos o miles de compañías dedicadas a la fabricación en masa de certificaciones ágiles cuyo marketing es cuestionable o puede llevar a engaño.
​
Y hoy en día, tenemos un maravilloso y variado mercado de limones.

No es algo exclusivo de Agile, es algo inherente a cualquier sector emergente en cualquier industria en cualquier país.

Desde las mascarillas para el COVID a los másteres que no son másteres.
​
Un momento. ¿No soy yo, Jerónimo Palacios, parte de esa mercantilización? Por supuesto que sí, en la medida en que todo el que tiene que ver con las certificaciones cae dentro del mismo saco.

Sin embargo, creo que dado el posicionamiento que hemos tenido, intentando mantener la calidad -y por ende el precio- por encima de la media, centrándonos en hacer de la formación -y no de la certificación- una palanca de transformación en las organizaciones con las que he trabajado y aportando experiencia haciéndolo.
​
Como ser humano es imposible no caer en contradicciones. Estoy seguro de que he formado personas que utilizan Scrum como un báculo con el que golpear a otros. Personas que han terminado formando parte de equipos de Software como Scrum Masters sin saber de tecnología.

Siempre he creído que lo importante de mi trabajo es explicar las cosas, la importancia que tiene la tecnología y las personas en torno al valor que creamos, pero siempre lo he hecho desde la perspectiva de Scrum.
​
Además, no es ningún secreto que puedes ir a Scrum.org y pasar la certificación PSM sin necesidad de asistir a nuestra clase ni a la de ningún Professional Scrum Trainer. Es más, con un poco de google fu puedes buscar archivos con cientos de preguntas por la red que te ayudarán a pasar la certificación sin saber siquiera cuantas preguntas está obligado a responder el Team todos los días al Scrum Manager.
​
Y eso hace que la certificación no valga nada. Porque la certificación certifica -¡Sorpresa!- que en un momento dado has pasado un examen de conocimiento básico sobre Scrum. Lo que vale es el conocimiento, ideas, habilidades y capacidades de la persona que ostenta esa certificación de ejercer ese rol en una organización.


Scrum ha muerto.

Toda la razón. Llevo viendo morir a Scrum y Agile desde que empecé a aplicar técnicas de desarrollo ágil y XP en 2007, cuando me subí al carro de Ruby on Rails. Hay pocas cosas tan viejas en el desarrollo de Software moderno como Scrum, que ya tiene 25 años.
​
Dentro de unos años Scrum no existirá. Y con ello habrá desaparecido la mercantilización, la falta de excelencia técnica y el rol del Scrum Master.

Ojalá el motivo de la desaparición de Scrum tiene como motivo que las organizaciones que desarrollan productos complejos han entendido que todas las cosas que promueve Scrum, incluyendo la agilidad de negocio, forman parte de su ADN, y por tanto no tienen que recurrir a ningún framework, método, certificación o bala de plata para mantenerse competitivas.

Compromiso y Scrum, una guía para tomar decisiones

En ocasiones, entender el funcionamiento de los compromisos en Scrum es difícil dada la diferencia de comprensión sobre qué es un compromiso y los conceptos de simetría y asimetría en el mismo. Veámoslo con una pequeña historia.

María quiere casarse con su pareja. Llevan siete años juntas, pero han tenido algunas dificultades.

A pesar de estar dentro de una relación, María se siente tentada a abrirse a otras personas y a otras experiencias.

Esto no quiere decir que no la quiera, todo lo contrario.

María entiende las relaciones como algo abierto, mientras que su pareja lo entiende como algo cerrado.

Este es un caso clásico de simetría y asimetría del compromiso.

Mientras que la pareja de María entiende que cuando se está en una relación de pareja el compromiso de fidelidad es mutuo (simétrico, igual para los dos actores), María entiende que no tiene por qué serlo (asimétrico, distinto para los dos actores).

En ocasiones tampoco existe transparencia acerca del compromiso, así que cada uno de los actores asume que su manera de entender el compromiso es la bueno. Es la vara de medir que utilizará para atizar al otro.

Esto dará lugar a problemas en la relación de María y su pareja en el futuro.

Compromiso en El Mundo Real™

¿Y en las organizaciones? Ocurre igual.

Mientras que algunos jefes les piden a sus subalternos cosas en las que ellos no creen, los subalternos piensan que en la misma posición ellos lo harían de forma diferente.

Error.

El problema de nuevo es la simetría del compromiso.

Cuando el departamento de gestión de calidad encarga un nuevo proyecto y pide un alcance, tiempo y coste cerrado, el departamento de Software entiende que las estimaciones y compromisos estarán atados a que no haya cambios.

Sin embargo no es así.

Tanto por un lado como por el otro es imposible tener un compromiso simétrico.

Calidad querrá que Software se atenga a su compromiso mientras ellos no respetan el su parte del trato y Software luchará para que haya simetría de nuevo, indicando que es imposible mantener el compromiso inicial cuando se han cambiado las reglas del juego a medio camino.

Y al igual que en la relación de María, esto genera problemas continuos en las organizaciones con las que trabajamos.

¿Y cual es la solución? No se trata de establecer procesos pesados que definan el compromiso para siempre, se trata de asegurarse de que cuando las reglas cambian, todos los implicados están de acuerdo con los cambios y aceptan que los compromisos iniciales quedan invalidados de acuerdo a la nueva situación. Esto es la capacidad de adaptarse a nuevas situaciones.

La principal ventaja de la agilidad.

Para poder mejorar la simetría, lo primero es establecer un “punto de compromiso”, dentro del marco en el que trabajamos, que obviamente es uno en el que se acepta que los cambios pueden surgir. En este punto de compromiso, se realinean expectativas y se hace transparente hasta donde se está dispuesto a llegar.

Compromiso en Scrum

En Scrum, esto ocurre durante el Sprint Planning. Los Sprints en Scrum permiten dar flexibilidad al cliente y constancia al equipo. De esta manera, se fija un Sprint Goal (simétrico, no cambia para el Development Team y para el Product Owner) y un Forecast o previsión (asimétrico, puede cambiar en función de las necesidades que surjan).

Este proceso se hace transparente a través del Sprint Backlog, que junto el Sprint Goal y el Forecast o previsión para el Sprint, nos ayudan a definir una guía sobre la que trabajar durante el próximo mes -o menos-.

En el método Kanban ocurre de forma similar. Mientras que los tickets se encuentran a la izquierda del punto de commitment (normalmente una columna llamada Next, que se elige durante el Replenishment), son solamente opciones. Los peticionarios pueden pedir pero hasta que los tickets no entran dentro del sistema. No se establece la relación de simetría o asimetría.

Una vez que pasan este punto de no retorno, se convierte en simétrico: ahora hay un acuerdo explícito y transparente. Hay que evitar abortar a toda costa cosas que ya están dentro de nuestro sistema, porque tenemos un compromiso de entrega.

¿Qué ocurre cuando el equipo no es capaz de responder a toda la demanda?

Entonces lo protegemos y ordenamos la demanda por prioridad, dejando que sea el equipo el que haga tantas cosas como puede hacer. De esa manera maximizamos la eficacia de ese equipo.

Si además limitamos la cantidad de trabajo en curso, usando límites WIP, conseguiremos que el flujo de entrega sea más estable y de esa manera, responder adecuadamente a un compromiso simétrico.

Tampoco es decir a todo que sí

Es evidente que decir a todo que sí, o su variante “No puedo decir que no” es una receta desastrosa para mantener una simetría del compromiso. Si decimos a todo que sí, o no podemos negarnos a nada, nuestra capacidad de mantener un compromiso estable de entrega de valor es completamente asimétrico.

Nuestro compromiso no vale nada.

No tenemos control sobre lo que podemos comprometer. Evidentemente eso afecta a la capacidad de adaptarse a nuevas situaciones en nuestra equipo u organización.

Precisamente saber cual es la capacidad real de compromiso y esforzarse por fomentar una simetría a través de la autonomía en la toma de decisiones es clave para conseguir que Agile nos permita acelerar y mejorar los resultados de nuestro negocio.

Hacer lo contrario, es decir, meter todo lo que se puede a ver si sale algo. Además poner un carril de urgentes -normalmente llamado Scrumban– es una receta para el desastre. El que más comprometido está es el más débil de la relación.

Volviendo al ejemplo de María, sería como si esta hablara a su pareja de las bondades de la fidelidad mientras disfruta de tres amantes distintos. No sería lo mejor para nadie, ¿No?

La increíble teoría de la latencia de las decisiones

Ahora que la parte dura de la pandemia del COVID-19 ha pasado y se han producido desconfinamientos, es probable que en algún momento desees volver a cenar a un restaurante con tu pareja, tu familia o un amigo.

Durante este tiempo en casa has tenido la oportunidad de revisar los mejores restaurantes de la ciudad y has hecho una lista ordenada por puntuación, reseñas y tipo de comida.

En el centro de la ciudad, Ángela está disponiendo todo para poder recibir a nuevos comensales cumpliendo con todas las medidas de seguridad.

Su equipo está muy contento de volver al trabajo y han preparado todo para hacer que todo esté perfecto.

Están muy emocionados. Las neveras están llenas. Todo está listo.

El día señalado nos dirigimos al restaurante. Tomamos asiento y revisamos la carta, que es un poco reducida. Elegimos nuestro plato y pedimos una botella de vino mientras esperamos.

En cocina, el equipo es uno de los mejores de la ciudad. Son capaces de preparar los 14 platos de la carta en tiempo record y han practicado durante la última semana para asegurar que todo está perfecto.

Sin embargo, para asegurar que el servicio cumple con todos los requerimientos sanitarios, cada comanda debe de ir primero a la mesa de Ángela, que se encarga de revisar las peticiones de los clientes una a una y decidir que platos se prepararan y quien se encargará de hacerlos.

Durante la primera hora las cosas funcionan. Un poco lentas, pero funcionan.

Sin embargo, cuando los clientes ya completan un tercio del aforo del local, las notas empiezan a acumularse en la mesa de Ángela mientras ésta tiene que acudir a cocina constantemente a revisar quien está disponible y cual es el siguiente plato que puede entrar en función de los requerimientos que hay que cumplir.

La primera noche es un desastre.

La segunda también.

Durante la tercera el equipo consigue mantener el servicio a duras penas. Los clientes dejan malas reseñas en Internet y empieza a correrse la voz.

Ángela toma una decisión.

A partir de la seiguiente semana contrata un equipos de compliance que se encargará de proporcionar capacidad a la toma de decisiones. Sin embargo, el resultado es incluso peor.

El nuevo equipo de compliance decide que el problema es la necesidad de tiempo para la toma de decisiones.

Así que a partir de ahora los clientes tendrán que avisar con al menos 24 horas de antelación de lo que desean comer para que el equipo tenga la oportunidad de organizar la comida.

Problema resuelto.

¿Problema resuelto?

Este problema es un problema clásico donde la toma de decisiones afecta a la agilidad de negocio, a pesar de tener una capacidad tecnológica y un equipo altamente preparado.

En el informe CHAOS de 2018, un referente en la estadística de gestión de proyectos, Standish Group introdujo la teoría de latencia de las decisiones para explicar por qué aparentemente organizaciones preparadas para enfrentar problemas de negocio de forma ágil tenían altos niveles de fracaso y de rotación de personal.

La latencia de las decisiones es un factor decisivo para valorar la agilidad de una organización”

La teoría propone que esos niveles de fracaso están más relacionados con la latencia -espera- que se produce entre las decisiones que con la capacidad de la organización de hacer frente a los problemas.

En una simulación avanzada, Patrick Steyart, creador de Okaloa FlowLab, explica como lidiar con este tipo de latencias usando Upstream Kanban y también en el libro Essential Upstream Kanban (Descarga gratuita tras introducir datos).

En 2017 también publiqué un artículo sobre el uso de Upstream Kanban para tratar este problema.

La latencia de las decisiones -también ironizada como parálisis por análisis- es un factor decisivo para valorar la agilidad de una organización.

En el caso de Scrum, se resuelve teniendo vectores de responsabilidad única, tales como el Product Owner para las decisiones de negocio, que sólamente por existir pueden agilizar un dominio de negocio o un producto, produciendo un retorno de inversión mucho mayor que su coste.

También el tener un equipo de desarollo que pueda tener una cierta independencia en la toma de decisiones técnicas o una librería de diseño para la creación de la experiencia de usuario son inversiones fundamentales para permitir que se pueda crear valor hacia el cliente.

Es precisamente cuando se trata de tomar acciones que cambian la latencia de las decisiones cuando las organizaciones presentan más resistencia a estos cambios. En general, reducir el número de decisiones puede llevar a que determinados roles y funciones queden totalmente obsoletos.

Por ejemplo, abordar decisiones en entornos de complejidad usando Cynefin puede destripar de autoridad a un manager cuya función es precisamente el controlar las decisiones que se toman.

Cuando un Scrum Master es empoderado para acceder a la organización y provocar cambios que afectan -y por tanto suboptimizan- al resto de la organización, pueden ser vistos como una amenaza. Sin embargo, reducir o incluso eliminar totalmente determinados estratos de decisión ayuda a reducir costes y mejorar la entrega.

Y esto no sólamente aplica a la creación y gestión de productos. Una organización que permite a sus empleados comprar cosas necesarias para su trabajo de un coste no superior a 150€ puede reducir eliminar la mayor parte de los sistemas de control y aprobación de gasto. Esto es lo que en Lean se conoce como waste.

Los estados por los que debe pasar una decisión pueden visualizarse y gestionarse utilizando Kanban.

Aquellos que somos fans de chefs Alberto Chicote o Gordon Ramsey podemos visualizar el impacto sistémico que tiene en un restaurante que el propietario decida meterse hasta la cocina a tomar decisiones que no le corresponden.

Esta analogía sería válida para comparar al equipo de compliance de Ángela con los gerentes intermedios de cualquier organización.

¿Significa eso que las personas deben operar con absoluta libertad y desprecio hacia las normas de la organización en un entorno de anarquía?
​
En absoluto.
​
Precisamente es en estos entornos donde tener una serie de reglas en torno a metas concretas de negocio las que nos permiten alcanzar nuevas cotas de competitividad y agilidad.
​
*Standish group ha creado un Free Membership donde se puede tener acceso gratuito a los reportes hasta 2015, aquí el link.

Cursos que te pueden interesar…

Professional Scrum Product Owner Advanced

Professional Agile Leadership

El estado de Agile en 2020

Hace más de 10 años estuve trabajando en un proyecto financiado con fondos europeos llamado Tratamiento 2.0. El objetivo era definir un marco para la obtención de información para la toma de decisiones médicas y la verificación automatizada de estas decisiones.

Me llevó unas cinco semanas definir ese marco teórico utilizando una metodología desarrollada por la Universidad de Amsterdam y hacerla cumplir con lo que se buscaba, que era una especie de UML para las decisiones médicas.

Ese proyecto se enmarcaba dentro de lo que posteriormente sería Horizonte 2020, un programa de la Unión Europea para el desarrollo de actividades de investigación científico-técnicas. Lamentablemente, mi trabajo nunca llegó a usarse.

Por aquel entonces 2020 era una quimera. Un puerto gris. Algo que quedaba lejano en el tiempo. Y sin embargo, hemos llegado.

La transformación del sector

Durante estos últimos años, el sector de la tecnología en España ha cambiado radicalmente.

Aunque quizás parezca lejano, hasta bien entrado el 2016 seguía existiendo un techo de cristal para las carreras técnicas (Programadores, Arquitectos de Software) que requería pasar a un puesto de gestión para poder ver incrementado tu salario.

En 2013 me mudé a Londres y apliqué a 20 ofertas para desarrollador un Lunes por la noche. Al día siguiente tenía 15 llamadas perdidas y mensajes en el buzón de voz. Contrastaba con la sequía de interés por parte de las empresas en España. En las consultoras andaluzas, el sueldo era de 850€ netos.

Fue una de las primeras cosas que me sorprendió cuando me fui de España en los peores años de la crisis.

Por otro lado, encontrar compañeros de 50 años que arrastraban una carrera técnica sin intención de cambiar, porque sus expectativas estaban más que satisfechas. 

Al principio se me hizo extraño. Nunca había trabajado en equipos técnicos con gente que estaba más cerca de la jubilación que del comienzo de su carrera profesional. Fue interesante descubrir como la madurez personal puede aportar mucho más que los conocimientos técnicos a los proyectos de Software.

Durante ese tiempo tuve la oportunidad de conocer en profundidad proyectos como el del Government Digital Services del gobierno británico, en el que introdujimos principios DevOps para garantizar la calidad de la arquitectura, la testeabilidad y reducir los ciclos de vida del desarrollo y la producción. Hablé de ello en la Conferencia Agile Spain de 2014.

El concepto de transformación digital también llegó tarde a España. Trabajando en la transformación digital de CapOne UK en 2014, vine unos días a España y descubrí a través de una búsqueda rápida en Google que nadie hablaba del tema. Fue BBVA en 2015 la que se embarcó en un proyecto de transformación que todavía dura.

En 2017, los recruiters invadieron el mercado después de haber pasado por Centroeuropa. Se destapó el pastel. A pesar del esfuerzo de muchas empresas para mantener unos salarios contenidos, se hizo patente que no había tanto talento técnico como demanda.

Durante esta década han surgido multitud de pequeñas compañías que se han especializado en el apoyo a determinados aspecto del proceso de transformación. También las grandes se han lanzado con los dos pies a intentar llevarse un trozo del pastel.

Los casos de éxito y de fracaso

Hay pocos casos de éxito a gran escala pero multitud de ellos a pequeña escala. De hecho, hay muchas startups y pequeñas compañías que no existirían de no llevar la Agilidad de Negocio en su ADN.

El motivo para que las grandes todavía no puedan presumir de casos de éxito rotundo es sencillo. La cultura de una compañía de décadas y decenas de miles de empleados no se puede cambiar en uno, dos o cinco años. Probablemente requiere jubilar a una generación de personas para dejar paso a las nuevas ideas.

Muchas personas siguen viendo Agile como algo perteneciente a tecnología. Y a tecnología como algo separado del negocio. Incluso peor: Abrazan Agile como un fin en si mismo cuando en realidad es un medio para conseguir un fin. Organizaciones más competitivas, innovadoras y aptas para sobrevivir.

Por supuesto, el crecimiento de la demanda de Scrum Masters, Product Owners y Agile Coaches no ha hecho sino atraer personas externas al sector que han buscado la mejor manera de incorporarse a puestos bien pagados en compañías que se preocupan de sus empleados. Tardará un tiempo y llevará una criba, pero muchos de ellos han llegado para quedarse.

Tal y como dice un buen amigo y conocida figura del desarrollo de Software: “¿Y cual es el problema? Yo empecé a hacer Software en el 2000 tras pasar un curso de tres semanas en una desaparecida consultora después de suspender las oposiciones a profesor de filosofía”

Conforme arrancamos 2020, Agile no es una palabra desconocida para la mayoría de las organizaciones. Quizás no todos entienden de la misma manera lo que es, pero ya no es desconocido.

Agile no es un puerto gris. Es un puerto que hace tiempo superamos.

Ahora el trabajo es más difícil, ya que supone ir alineando, descubriendo y acompañando organizaciones en descubrir como usar esa amalgama de cosas inconexas para obtener un resultado tangible en su cuenta de resultados.

Hace cuatro años publiqué un artículo en LinkedIn que tuvo cierto éxito: 9 Easy Mistakes to Avoid during your Agile Journey. Uno de los puntos a evitar era “No despedir gente“, en el que hacía una clasificación rápida del tipo de reacciones que la gente tiene ante estos procesos de cambio: Aceptarlas, Irse o lucharlas desde una falsa aparicencia de aceptación.

El problema son los terceros. Tienen una evidente falta de Skin in the game, cuidan mucho su exposición pública, no ponen su nombre junto a lo que dicen y utilizan a otros para sus fines publicitarios.

En el libro Skin in the Game, Nassim Nicholas Taleb explora las asimetrías cotidianas en las que no nos fijamos en lo que la gente dice, sino en como se están arriesgando para defender desde El Mundo Real™ esas ideas.

Los falsos ídolos

No quiero terminar de escribir este artículo sin hablar de las certificaciones: los falsos ídolos.

Al parecer, existe una creencia generalizada en el mercado Agile que las certificaciones son una especie de sistema mágico que te habilita para hacer cualquier tipo de transformación mágicamente.

No lo son.

Las validaciones profesionales existen desde hace muchos siglos como complemento a una experiencia profesional que es insustituible. Habitualmente son una manera de establecer un reto claro en el objetivo es mejorar el conocimiento para luego llevarlo a una realidad. Proporcionan una base que permite comparar, aprender y descartar en función de una variable más. No la única.

Aquí hay dos falacias a explorar.

La primera es que hay grandes profesionales que no ostentan ninguna certificación. Sin embargo, no ostentarla no te hace por defecto un gran profesional.

La segunda es que sirven como muñeco de paja para golpear con el argumento de que sólo sirven para obtener un título y que la formación en torno a ellas es solamente una preparación -un peaje- para ganar más, aunque no tengas ni idea.

Es un problema de calidad de la fruta que compramos.

Hace un tiempo escribí sobre la teoría del mercado de los limones, una metáfora para ilustrar el problema que supone poner a competir un producto de buena calidad con uno de mala calidad. La solución en este entorno es disminuir la asimetría de la información -que el consumidor esté mejor informado- para hacer evidente la diferencia de calidad de los productos existentes en el mercado.

Estas falacias son fácilmente rebatibles.

Agile como moda

Para aquellos que piensen que esto es una moda, les recomiendo que hagan una comparativa de búsqueda entre Agile y Televisión 3D, para descubrir qué es una moda y qué es un movimiento que poco a poco está transformando el mundo.

Agile en 2020 está más vivo que nunca.

Hay muchos retos por delante: Profesionalizar cada vez más el sector, conseguir que los programadores dejen de estar enamorados de su código y empiecen a enamorarse del valor que su código crea y convencer a muchos responsables de toma de decisiones que las bolas mágicas están pasadas de moda.

Por supuesto hay quien seguirá vendiendo Scrum o Kanban como la solución mágica a los problemas de las organizaciones, pero no lo son. Aportan la estructura necesaria para poder afrontar esos problemas, pero no los resuelven.

Esto significa contar con gente técnicamente preparada y darles el espacio que necesitan para poder empezar a aportar, eliminando capas de gestión que están ahí para dar una falsa apariencia de control sobre el Caos.

Cómo formar equipos ágiles trabajando con Scrum

Conformar equipos ágiles cuando estamos trabajando con Scrum es un reto. ¿Cómo decidimos quien debe ir en cada equipo? ¿De que manera podemos extender Scrum a la organización y mantener la agilidad?

Hace unas semanas durante una charla para OnTech Innovation una de las asistentes me lanzaba esta pregunta en Twitter.

Jeronimo, por favor me indicas si existen técnicas de división de equipos, cuando ya se trabaja Scrum y Kanban? Escuchamos sobre la técnica (split and seed – split and grow) pero no encontramos casi información del tema. Gracias

— Monica Martinez H (@monicaromartine) September 26, 2019

Equipos auto-organizados. No equipos donde todo el mundo haga de todo.

Cuando usamos Scrum para lidiar con problemas complejos, podemos caer en dos tentaciones diametralmente opuestas: Distribuir el trabajo en trozos de acuerdo a los equipos que tenemos actualmente (Fron-end, Back-End, Data, etc…) e ir haciendo Sprints en el que el trabajo de unos recae en otros.

Otra opción es tener equipos donde todo el mundo haga de todo. En realidad, en Scrum no es ni lo primero, ni lo segundo, ni nada en medio de los dos.

Cuando Scrum fue descrito por primera vez en el New New Product Development Game, los investigadores Takeuchi, Nonaka y Ken-Ichi Mai observaron que los equipos de alto rendimiento que estudiaban tenían precisamente todos los perfiles que necesitaban para entregar algo terminado, funcionando y que el cliente valorara en un periodo muy corto de tiempo.

¿Como podemos conseguir identificar cuales son las skills necesarias para entregar un incremento de valor, terminado, en 30 días o menos? Es más fácil de lo que creemos. Sólo hay que preguntarle al equipo que trabaja en ese producto.

A pesar de que pueda parecer sorprendente, las personas que desarrollan un producto son las que más saben cómo organizarse para sacarlo adelante.

Para aquellos que temen que los techies se centren sólo en su área, esa es precisamente una de las problemáticas que resuelve Scrum.

Scrum proporciona los límites, la transparencia y la capacidad de inspección y adaptación para asegurar que la auto-organización funciona. Cuando un equipo de desarrollo tiene que entregar un incremento terminado en 30 días o menos, pone el foco en qué necesita para que eso ocurra.

Hace un año y medio, escribí un artículo sobre las diferencias entre distintos tipos de diseño de equipos.

En realidad nada ha cambiado mucho desde entonces, más allá de que sigue siendo difícil entender que para cambiar nuestra forma de entregar valor a los clientes, tenemos que cambiar la forma en que organizamos el trabajo.

Split and Seed y Seed and Grow.

Cuando nos planteamos escalar Scrum a distintos equipos de nuestra organización, se suele acudir a los métodos por los que Mónica pregunta en su Tweet: Split and Seed y Seed and Grow.

Seed and grow model in Scrum

Con este método, se toma un equipo pequeño que establece un núcleo o un core y se divide.

En el primer caso (Split and Seed), una vez que el equipo está establecido, se divide en dos equipos que se utilizan como base para hacer crecer otros equipos, a modo de mitosis de equipo.

En el segundo caso (Seed and Grow), se toman algunas personas de un equipo que ya está funcionando y se utilizan como semilla para hacer crecer otro equipo, a modo de esqueje.

Este método plantea dos problemas: ¿Quien decide como se mueven los miembros de un equipo a otro? ¿El Agile Coach, el Scrum Master, el Propio Equipo?.

El segundo problema es que podemos partir de un equipo de alto rendimiento para terminar con dos equipos mediocres o que no funcionen en absoluto.

El método del becario

Una alternativa, que Jeff Sutherland llama “El modelo del amigo del equipo”, es introducir a un nuevo miembro del equipo de desarrollo, que se encarga de empaparse de la cultura, forma de trabajo y experiencia del mismo con el objetivo de graduarse y formar su propio equipo más adelante.

Internship grow model in Scrum

Un equipo de desarrollo identifica uno o varios compañeros, que trabajaran con ellos durante un periodo de 4 a 6 sprints.

Su papel durante este tiempo será aprender y participar en las actividades del equipo sabiendo que su permanencia tiene una fecha de caducidad en el tiempo. Cuando pase ese tiempo, serán los encargados de ser el pilar fundador de un nuevo equipo.

En ocasiones a estos equipos que admiten nuevos miembros se les llama “Equipos de bienvenida” o “Training Teams” y tienen una alta cultura de colaboración que puede ser expandida a nuevos miembros.

La decisión del número de Sprints que permanecen en el equipo es una decisión personal. Cuando están listos, pueden migrar al nuevo equipo.

La ventaja de este método es que asegura que no se rompe un equipo de alto rendimiento ya existente, tiene un impacto menor en el delivery actual y permite un crecimiento de acuerdo a las capacidades de contratación de la organización. Sin embargo, es un método extremadamente lento para aquellas organizaciones que quieren escalar Scrum rápidamente.

El observador

Otra opción, basada en el modelo anterior, es incorporar nuevos miembros como observadores. La principal diferencia es que mientras en el método del becario participan activamente de las labores, entrega y eventos del equipo, en este modelo sólamente actúan como observadores.

Observer Model

La principal ventaja de esta última opción es que la incorporación de un observador es mínimamente disruptiva.

Pueden continuar con se trabajo como hasta ahora sin tener que centrarse en enseñar a un nuevo miembro del equipo.

A pesar de todo, el efecto del observador puede ser disruptivo para equipos existentes. A nadie le gusta sentirse observado.

Puede tener consecuencias inesperadas cuando los nuevos miembros crean sus equipos e implementan lo que creen que han observado.

Lo más importante: Medir Siempre

Durante todo el proceso de escalado a equipos con Scrum, es importante medir el estado y la salud del equipo. El health check de Henrik Knieberg en Spotify puede ser un buen comienzo. La importancia de medir el estado de los equipos radica en que una manzana podrida en una cesta de fruta acabará rápidamente con todos los esfuerzos por mantenerla en buen estado.

Lamentablemente el crecimiento rápido en pocas ocasiones tiene buenos resultados. Si además se están adoptando prácticas que requieren de un alto grado de auto-organización, como Scrum, es necesario dejar que los equipos y la organización maduren a su propia velocidad.

  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página 4
  • Ir a la página 5
  • Páginas intermedias omitidas …
  • Ir a la página 26
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad