Agente SCRUM, con licencia para matar

4

Si hay algo más peligroso que un loco de los procedimientos, es un loco de los procedimientos disfrazado de agilista. Ya os lo comenté cuando os dije que ser ágil es más un estado que un método. Pero en este mundillo hay mucho listillo que se cree que leyendo dos libros ya puede considerarse experto. Se aprende cuatro reglas y se cree rápidamente superior (ya os dije en otro articulo que tendemos a creer que sabemos más que nadie). Este comportamiento es típico de los JASP, los jóvenes, aunque sobradamente preparados. Gente sin criterio que lee lo que dicen las eminencias y lo aplica sin entender realmente el trasfondo (como lo dice el manifiesto, lo aplico sin criterio).

Resumiendo, tenemos por ahí gente que no entiende lo que es realmente importante en toda esta historia de intentar ser ágiles, se aprenden cuatro normas y las aplican como si fuese una religión (mucho cuidado con los fanáticos). Y un grupo importante son los agentes SCRUM sin criterio. Gente que se ha aprendido las cuatro normas de SCRUM, las aplica y dicen que ya son “Agile”.

El problema es que le cuentan el cuento a los equipos, y lo que transmiten son puramente procedimientos. No el trasfondo o el por qué. Puede que se aprendan el mantra de “maximizar el valor entregado”, pero ¿realmente lo entienden?. No, ya os digo yo que no lo entienden. Y como no lo entienden, no lo transmiten a los equipos.

Los “pobres” equipos, que les han taladrado hasta la saciedad que SCRUM es el elixir que lo cura todo, acogen las normas. Además son unas normas que les molan muchísimo porque les permite dejar de hacer todo lo que les joroba. Ya nunca más documentar requisitos. Sólo se habla. Cuando eso no es así. A veces, por mucho que nos jorobe, toca escribir algo. Aunque sea poco. Pero eso de no documento nada de nada, porque lo dice el manifiesto, es un error. Hace poco os comenté que el manifiesto dice priorizar unos valores, no descartar completamente los otros. Resumiendo, tenemos unos equipos que se olvidan de la base y el por qué queremos ser ágiles, y en cambio sólo ven normas y procedimientos.

Cuando esto pasa, varios comportamientos super nocivos aparencen en el camino. Y son simplemente el resultado de aplicar a ciegas los procedimientos SCRUM sin entender por qué son así. Veamos unos pocos.

Yo desarrollo, no doy soporte

Caso típico es el del equipo que planea un sprint en el que todo es nueva funcionalidad, y más adelante llegan incidencias. Bueno, incidencias, consultas, peticiones de servicio o peticiones de ayuda para investigar problemas. El soporte no mola. Mola mucho más ponerse los cascos a escuchar música (que bueno es escuchar música programando) y tirar código como el que vomita en el teclado. Que guay es eso de entrar en flujo mientras se programa. Además hay una norma en SCRUM que es cumplir el objetivo del Sprint.

Soporte no mola + Procedimiento que nos pide cumplir el objetivo = Equipo que evita el soporte a toda costa.

Por supuesto hay incidencias que no se pueden evitar, que hay que arreglar sí o sí, y esas las tienen que hacer. Pero hay muchas otras que es importante atender, pero como no tienen una alta prioridad, pues es más fácil arrinconarlas en un cajón. De repente alguien necesita ayuda, y “eso no está en el Sprint”.

En ocasiones he visto como esta situación se eleva a un enfrentamiento. Enfrentamiento con negocio, que ve que no se le resuelven los problemas. Enfrentamiento con operaciones, que ve que no le hacen ni caso.

Este equipo se ha olvidado que su objetivo es entregar valor, no entregar código. Entregar código es una forma de entregar valor. Pero resolver una incidencia puede ser algo que entregue mucho más valor. Perdemos la cultura de servicio hacia el negocio. Esa tiene que ser nuestra máxima prioridad. Si negocio está cabreado, algo hacemos mal.

Hay casos en los que se llega a un acuerdo en el que se dicen cosas como “el 20% del Sprint lo dedicaremos a soporte”. Y luego de repente tenemos tres incidencias graves y la reacción del equipo es que te dedica el 20%, que es lo que ha pactado. Que no puede dedicarte más porque incumpliría lo comprometido en el Sprint.

¿Comprometido? ¿No nos damos cuenta de que hemos pasado de intentar se ágiles y dar lo mejor de nosotros a firmar contratos (aunque sea cada 2 semanas)?

Resumiendo, mucho procedimiento y poca agilidad.

Eso no está en el Sprint, hay que esperar al siguiente

Os pongo un ejemplo práctico vivido en propia carne (aunque con algún matiz menor para evitar aludidos): Una empresa vende su producto como herramienta de contabilidad. Están a punto de firmar un nuevo contrato con un cliente y éste les dice que para empezar necesita que la aplicación muestre su logo.  Estamos en la última semana de Julio. El equipo de desarrollo está en medio de un Sprint y hacer el cambio y liberar una versión con logo configurable les cuesta unas horas. Pero responden que no, que eso para el Sprint siguiente. Así, el desarrollo se hace en la segunda semana de Agosto, y el cliente, como no cambia a mitad de mes, comienza a trabajar en Septiembre. La empresa perdió un mes (una importante suma de dinero) de contrato, además de dar imagen de “poco interés” y poner en riesgo la venta.

Esto pasa continuamente en muchos sitios. Negocio que necesita pequeñas cosas, o que le cambia el entorno en cuestión de un día. Y desarrollo que, escudado en el “procedimiento” SCRUM le manda a paseo y que se espere.

El peor caso lo he visto en una situación en la que hacían sprints cada dos semanas y cada 4 sprints una sesión de priorización. Sólo entraba nuevo desarrollo cada dos meses. ¿Estamos locos? Negocio tenía que esperarse dos meses para que desarrollo hiciese nada.

Resumiendo, mucho procedimiento y poca agilidad.

¿Cuando estará? Ni idea

Otro de los temas recurrentes es que el equipo se compromete con un objetivo para el Sprint. Pero negocio está esperando épicas (proyectos en argot de negocio) y necesita saber cuando estarán. Las empresas no van como pollo sin cabeza tomando decisiones cada día. Las empresas diseñan su estrategia. Y nosotros deberíamos alinearnos con nuestra estrategia (puedes leer mi opinión sobre la estrategia y el desarrollo ágil).

Pero estimar cosas más allá de las dos semanas es algo que los desarrolladores no quieren y no saben hacer por norma (puedes leer el artículo sobre la miopía en la estimación de los programadores). Lo ven como un compromiso difícil de cumplir (y ya he comentado varias veces que una cosa es estimar y otra es comprometerse). Así que SCRUM les viene de maravilla para esto. “Ya no estimamos nada, sólo te decimos lo que estará en dos semanas”.

Responder esto es realmente no entender para nada lo que necesita negocio. Negocio quiere saber cuando podrá poner a la venta el nuevo producto, porque semanas antes ya estará preparando el material comercial y probablemente vendiendo la piel del oso en ferias. Negocio no necesita que le digas que el 3 de Abril lo tendrá (eso sólo te lo acierta Amazon). Pero sí que necesita que le digas que lo tendrá por Abril o Mayo, siempre que no se le vaya la pinza haciendo gold platting.

Pero claro, los agentes SCRUM con sus procedimientos pueden con todo y en nombre de la agilidad puede pasar de lo que realmente necesita negocio y aplicar sus procedimientos.

Resumiendo, mucho procedimiento y poca agilidad.

La culpa es del Product Owner

Y la última que os comento (y me quedo con ganas de más): Echar la culpa al Product Owner de lo que se hace o se deja de hacer. Es la reactividad máxima sólo comparable a cuando los programadores hacían lo que les daban en los cuadernos de carga. El Product Owner dice: “Qué se haga la luz” y el equipo la hace. Pero al equipo le da igual si el cliente necesita luz o necesita aire.

Ser ágil e intentar aportar lo máximo a negocio significa comprometerse y alinearse con negocio. Significa entender lo que le pica para rascarle. El equipo debe implicarse, comentar y colaborar en las tareas. El Product Owner tiene la responsabilidad (Accountability) de definir qué va delante o detrás. Pero eso no implica que el equipo tenga que pasar de todo. Es como en la matriz RACI (una lección básica de RACI por si te pilla despistado el término) que hay los roles de Responsible y Accountable. El PO es el Accountable. Pero el equipo tiene que formar parte del Responsible y colaborar. Tiene que implicarse.

No es raro encontrarse con un equipo que cuando acudes pidiendo que se haga tal o cual cosa sólo te responde “habla con el PO, nosotros hacemos lo que nos dicen”. Se llega a casos absurdos en los que un equipo, y esto lo he visto, está haciendo un desarrollo para un cliente, que sabe que acaba de romper el contrato (por lo que sea) y ellos siguen haciendo el desarrollo. Sabiendo al 100% que eso no se va a usar. Pero “nadie les ha dicho que paren, así que no paran”.

Claro para ellos es muy cómodo. Es quitarse esa responsabilidad de participar de la toma de decisiones. Es “ficho, hago mi trabajo y me piro”. Implicación cero.

Estoy de acuerdo que las decisiones las tiene que tomar el PO. Pero, espero un poquito de sangre en las venas de los desarrolladores y que sean capaces de hablar con el PO de tú a tú (y no de subordinado a jefe) y explicarle por qué creen que se equivoca. O por qué ese desarrollo, tal y como se plantea, es un riesgo muy elevado.

El extremo es cuando el PO está de vacaciones y el equipo se comporta como lemmings que van al precipicio sin cabeza. “Yo hago lo que me dicen”. El procedimiento dice que la priorización la hace el PO y punto en boca.

Resumiendo, mucho procedimiento y poca agilidad.

Últimas palabras

Quiero dejar clara una cosa: No estoy diciendo que SCRUM sea malo. Me parece una de las mejoras cosas que nos ha pasado en nuestro sector. Lo malo son los “Formadores en Agile” y la gente que se cree que esto va de metodología ágil y procedimientos y no acaba de entender realmente lo que se quiere.

AgileSCRUM

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

4 comments

  1. Albert 31 julio, 2018 at 17:12 Responder

    Muy buen artículo de nuevo. Esa “aplicación de la norma” lo he visto en directo. Y te has dejado el capítulo de “la calidad va en otro sprint. Fase 2”..

    Un placer leerte y aprender

  2. Alex Ballarin 2 agosto, 2018 at 11:31 Responder

    Hola José María,

    una buena colección de antipatrones en Scrum. La diferencia entre “un formador agile” (entre comillas) y alguien que tiene experiencia real desarrollando con Scrum, y ayudando a otros a hacerlo, es radical. Que los formadores malos no empañen la profesión.

    Más que JASP diría JASP&SER (Sin Experiencia Real). 🙂

Post a new comment