Agile Project Management

Si llevas unos años trabajando en equipos de desarrollo software seguro que has vistos problemas como estos en algunos de los sitios en los que hayas estado. Y no solo uno, sino más de uno al mismo tiempo.

Aquí tienes algunos de los problemas más habituales con los que me he encontrado yo:

1. Se llevan mal entre equipo y negocio. Tienen prioridades distintas, visiones diferentes que hace cada uno tire hacia su lado tratando de llevar el ascua a su sardina.
2. Por el producto no mira nadie. Solo se mira el número de features que se sacan o el número de puntos y user stories hechas ¿pero se está aportando valor? A alguien le está ayudando lo que se ha entregado en la última versión.
3. El equipo da el mantenimiento a un software legacy gigantesco o a 10 pequeños productos a la vez. Cuando no está caído uno, está caído el otro. No hay tiempo sino para parches.
4. El producto es el ojito derecho de la empresa y la gerencia ha puesto en él todo su empeño. Sin embargo, no se ha calculado su potencial en ventas, o lleva ya tiempo a la venta, pero después de invertir años y años en él no consigue despegar. Todo se apuesta a que quizás con la próxima feature, puede que si le añadimos esto o lo otro. El potencial cliente te alienta diciendote que si tuviera esto te lo compraría, pero no se hace más que correr detrás de una meta que se aleja.
5. El producto no se saca nunca al mercado. Parálisis por análisis. Primero para elegir el framework, luego esta arquitectura, luego la otra y la otra, después la interfaz gráfica no es suficientemente buena, pero tampoco las features. Solo podemos ponerlo en marcha cuando esté perfecto (nunca lo está).
6. El roadmap por decibelios. El mánager que más alto habla es el que decide todas las features. Su departamento o proyecto es el más importante por lo que debe trabajarse en ello por el bien de los objetivos de la empresa.
7. El equipo que solo acepta peticiones aprobadas por dirección, economía, ventas y gerencia. Es necesario un formulario complejo para cada solicitud, una documentación que nadie quiere rellenar o que te obliga a hacer un copy-paste que es rechazado constantemente. Toda nueva petición se responde con: «¿Para qué lo necesitas? Eso lo puedes hacer con un Excel».
8. El legacy en eterna sustitución. Se está desarrollando el nuevo producto que lo sustituya, pero no paran de llegar peticiones de mejora del antiguo. Todas son urgentes, no pueden esperar al nuevo producto. Como el equipo está trabajando en esas mejoras, no puede avanzar en el nuevo proyecto que siempre se ve retrasado.

Lo curioso es que ninguno de estos problemas aparece de golpe, y normalmente no se sufre uno solo. No se pueden evitar por completo. Son consecuencia de la lógica y de los intereses de cada uno. Lo que debemos hacer es intentar que se conviertan en nuestra forma habitual de trabajar.

En las próximas semanas iré desarrollando cada uno de ellos.

En algunas empresas de consumo te hacen rellenar un formulario antes de aceptarte una devolución. Tienes que explicarles qué falla, por qué los quieres cambiar, dar detalles del problema.

En algunas ocasiones no hay nadie leyendo lo que escribiste y poniendo un sello de solicitud aprobada o denegada. Todas son aprobadas. El coste de leerlas, estudiarlas y aprobarlas o atender las reclamaciones cuando lo niegas tiene un coste mayor que simplemente cambiarte el producto por otro igual.

Hay empresas que sí revisan esos formularios, pero en otras solo están para tratar de introducir fricción para reducir el numero de solicitudes. El simple hecho de obligarte a explicar el motivo hace que muchas personas piensen dos veces si realmente merece la pena.

Ese mismo principio aparece continuamente en el desarrollo de productos software y no software.

Cuando como Product Manager te llega una petición «urgente» y todo el mundo quiere que empieces con ella hoy mismo (present bias), pero dos semanas después aparece otra prioridad descubres que muchas urgencias tienen fecha de caducidad.

Dejar pasar algo de tiempo y tratar de averiguar primero qué coste o qué beneficios tiene para la empresa o el producto esa nueva solicitud de desarrollo o cambio te va a ayudar a dar reposo y estabilidad al flujo de trabajo.

El tiempo filtra las falsas urgencias. Es, a veces, la mejor herramienta para priorizar tu producto. Incluso mejor que Jira.

No se trata de dejar todo para mañana. Se trata mejor de no dejarse llevar por los impulsos o por esa sensación de «tengo que hacer algo, lo que sea» (action bias) para mostrar una diligencia que en realidad solo nos está atropellando nuestro proceso de decisión.

Cuando uno está diseñando una arquitectura software hay una parte siempre difícil: la de la toma de decisiones, el valorar los trade-offs y decidir qué dejas a un lado y por qué apuestas. Todos sabemos que por buena que sea la idea siempre tendrá algún aspecto negativo a considerar: quizás un mayor coste, una mayor complejidad de implementación, o un riesgo alto al apostar por una tecnología no tan probada.

Problemas siempre habrá y alguien se encargará de recordártelos cuando empiecen a dejarse notar. Todos se acordarán de ti cuando se le empiecen a ver las orejas al lobo.

Pero el problema de verdad no está en los diagramas, en los planos y diseños, está justo después de eso. Cuando hay que llevarlo a la práctica, cuando alguien tiene que abrir el Visual Studio y convertir en líneas de código contantes y sonantes eso que para ti eran solo un par de flechitas en un Powerpoint. Ahí hay un verdadero riesgo de fracasar: nadie mantiene las decisiones arquitectónicas, nadie tiene en la cabeza todo el diagrama, y los apaños, o el «yo pensé que podíamos resolverlo de esta otra forma», van tomando cuerpo y reemplazando tu bonito blueprint.

Vas a tener que registrar las decisiones más importantes en los ADR, y revisarlos con frecuencia. Adaptarlos para lograr que sobrevivan al contraste con la realidad, y vigilar el coste de cambiar de rumbo. Ten siempre presente qué decisiones son reversibles y cuáles no.

Pero ante todo, comunica siempre los pros y los contras. Necesitarás que se suban a tu barco, y entiendan por qué se tomaron esas decisiones, para que no empiecen a remolonear cuando la mar pinte fea.

El psicólo David Premack propuso en 11965 que iniciaras las tareas del día o de tu proyecto con las actividades menos preferidas o las que menos te motivan. Ya se sabe por esta frase atribuida a Mark Twain: «Si tu trabajo es comerte un sapo, que sea lo primero que hagas en la mañana. Si tienes que comerte dos sapos, empieza por el más grande».

Lo que dice la teoría es que inicias el ciclo (la mañana, la tarde, la semana) con las tareas más pesadas o desagradables, y para el final de la jornada te «premias» con las que te resulten más interesantes o ligeras.

Te aseguras así de que lo importante, lo difícil, lo que todos dejamos siempre para después está ya hecho. El resto será ya cuesta abajo. Incluso te permite comprobar que, si la tarea era más difícil de lo esperado, tienes todavía margen para reaccionar.

Todos sabemos que no es lo mismo acabar un viernes por la tarde cumpliendo a toda prisa eso que tan poco nos gusta hacer, que terminar con las tareas sencillas y que nos dan un respiro para poder empezar el fin de semana con algo más de resuello. Ea, valor y a por el sapo.

Entre los años 22 y 25 corrieron olas de despidos en muchas empresas. Hasta entonces había dinero barato, las compañías disponían de financiación casi ilimitada y cuando eso se acabó se dieron cuenta de que estaban sobredimensionadas, de que de esa manera nunca iban a tener beneficios.

Es cuando empezaron los recortes, primero por necesidad, pero en algún caso también por moda. El último grito en gestión era Lean Reduction, Lean Staffing. Quitamos un miembro del equipo y al poco todos se adaptan, se reparten el trabajo entre el resto, siguen trabajando y las incidencias se resuelven igual, los desarrollos continúan. Nada parece cambiar así que quitamos a otro miembro de cada equipo. Aparentemente todos los indicadores siguen en verde, los proyectos siguen entregándose.

Musk parecía ser el ejemplo máximo de esto. Cuando compró Twitter, que llevaba años en pérdidas, redujo la plantilla a la mitad. Donde antes había diez personas, solo quedaron cinco o menos. Y nada parece haberse roto en la empresa del pajarito.

En realidad el coste existe. Menos innovación, menos documentación, menos tiempo para pensar. Si dejas de hacer mantenimiento preventivo a tus máquinas, a tus camiones o s tus activos software, durante un tiempo nada pasará, nada se rompe de golpe, pero la deuda se acumula. Podrás pagarla cuando tenga un tamaño que la haga insostenible?

Ya sabemos que el trabajo se expande hasta ocupar el mayor tiempo posible, sin límite alguno. La capacidad humana también puede asumir más trabajo del que parecía posible, pero en algún momento la organización empieza pagar esos intereses y a consumir su propio futuro.

El libro Management 3.0 indica que los sistemas de información, los portales o aplicaciones que tratamos de crear, no son desarrollados como en la industria de la construcción: con unos grandes planos, mucho diseño, y un montón de camiones llegando después a la obra para dejar los materiales. En IT somos más como jardineros podando, regando y retocando aquí y allá.

Se trata más bien de plantar un semilla o un pequeño mato y dejarlo crecer, dejar que vaya tomando forma y orientarlo hacia lo que queremos tener, en lugar de tratar de tener un arbol ya crecido con las dimensiones y forma que queremos. Si le falta la rama de Contabilidad, la diseñamos e injertamos a la fuerza donde queremos. Me temo que así no va a funcionar.

Esto que cuenta el libro me recuerda a la ley de Gall, que dice que todo sistema que funcione proviene, sí o sí, de un sistema más pequeño que ya lo hacía y evolucionó hacia el sistema actual (que es lo mismo que decir que no hay sistema grande que funcione que no provenga de un sistema semilla original que ya haya probado su viabilidad).

Si tienes un nuevo proyecto entre manos, asegúrate de construir primero un germen inicial que tenga éxito comercial y funcional. Luego, vete haciéndolo crecer poco a poco, añadiendo todo eso que le falte (o que no le sobre).

Todos sabemos que muchos contratistas son impredecibles: no empiezan el trabajo el día indicado, tampoco esa semana ni ese mes, trabajan de forma chapucera o tienen malas formas cuando se les menciona que algo no se hizo de forma correcta.

El Libro MBA Personal menciona el ejemplo de una pequeña empresa de reformas de Aaron y Pat en la que su secreto está en la «capacidad de predecir». Todos los trabajos que hacen son de alta calidad, respetan las fechas y son agradables en el trato.

Ni que decir tiene que, como consecuencia, les llueven los pedidos y los clientes hacen cola por sus servicios, lo que es un logro bastante grande en un sector en el que hay mucho intrusismo. Conseguir eso donde abundan los profesionales que se ofertan a un precio muy bajo, si lo comparamos con los de las empresas que tratan de dar calidad, es una señal fuerte de haber hecho las cosas bien.

Lo que funciona en el mercado «blando» de la construcción también es válido para casi cualquier otro sector: trabaja, trabaja bien, cumple con lo que se te ha pedido sin regatear en el tiempo dedicado o los materiales, y con un poco de suerte el boca a boca hará el resto. Solo tienes que ser constante y dejar que el tiempo te caiga encima, poco a poco, y sin desesperar (aunque podemos intuir lo difícil que es esto).

Si tienes que preparar un documento muy extenso con todos los requisitos del proyecto para que te lo firmen, puedes estar dando un paso equivocado.

Puede que lo quieras para defenderte si hubo un malentendido y poder decir, «lo siento, esto es lo que se firmó», pero con eso solo ganarás una batalla, el cliente no podrá reclamar nada pero no estará contento. Simplemente, no va a estar contento contigo y no va a llamarte para el próximo proyectos. Esperaba algo distinto. Lo necesitaba para trabajar, y que haya cometido el error de firmarlo no lo va hacer más contento a la hora de pagar.

No hay nada de malo en recoger lo hablado en un documento, pero ten en cuenta que no lo van a revisar. Seguramente ni a firmar. Nadie quiere ser responsable de que en la página 68, tercer párrafo tenga por error: «el informe no será personalizable», cuando en realidad debe decir que sí deber ser personalizable. Si ha habido un malentendido el malestar seguirá igual.

Si realmente quieres solucionar el problema, enseña tu trabajo cada poco en una demo, envíales un vídeo del comportamiento de la aplicación, un informe de estado de lo que estás haciendo esa semana, pero sobre todo, pónselo en producción al poco tiempo de comenzar.

Haz que lo use, no esperes 6 meses o un año a que el cliente lo vea y se dé cuenta de que eso en los que has estado trabajando durante un montón de tiempo no le sirve para nada.

Se suele decir que lo que hace falta para que un proyecto sea exitoso es:

1. Que se haga en el tiempo estimado.
2. Que se haga dentro del presupuesto calculado.

Pero, aunque normalmente no se hable de él, hay un tercer requisito para poder declarar un proyecto como exitoso:

1. Existe una relación cordial y colaborativa entre el director o directora de proyecto y el proveedor.

Si el director de proyecto, el que acepta tus entregables, no te puede ni ver después de acabado el proyecto, no existe posibilidad de que te contrate de nuevo para los siguientes trabajos.

Si has quemado al proveedor, si le has sacado hasta la última peseta, tendrás unas mejores cifras, pero no cuentes con ellos para el próximo proyecto. Perderás un colaborador para el futuro. No hay más juego que dar, no cuentes con sus expertos. Tendrás que recurrir a ese otro proveedor, el que nadie quiere, el que resulta muy barato en el precio/hora, pero que a la larga sale mucho más caro en incumpliminetos, retrasos y fallos.

El trabajo, como casi todo, se basa en relaciones a largo plazo. De nada te vale ganarle una batalla o una discusión al cliente si se termina estropeando la relación. No te va a llamar para el próximo proyecto. No te va a aceptar la próxima propuesta por buena que sea, por poco que cobres.

Es a la larga cuando se gana. Los primeros proyectos, esos donde estás aprendiendo, donde vas mejorando poco a poco, en esos lo pasarás mal. Cuando lleves 10 o 20 proyectos, clientes, proveedores y colaboradores es cuando vas a poder respirar algo mejor.

En una gran cantidad de proyectos, aparece un fenómeno curioso: cuanto más gente hay implicada en un asunto, más difuso es saber quién está haciendo qué y si realmente hay alguien atacándolo.

Se organizan reuniones, se envían emails a decenas de personas y equipos, se escalan los mensajes, pero nadie se siente aludido. Todos parecen pensar «esto no me afecta», «esto lo tiene que mirar mi jefe», «si yo tuviese que hacer algo ya me lo habrían dicho».

Es el conocido efecto espectador: cuando todos son responsables, nadie lo es.

Sucede lo mismo con la asignación de tareas en un equipo, hasta que la tarea no tiene un nombre y apellidos, ningún miembro del equipo la coge para empezar a trabajar en ella.

Lo mejor es:

• Asignar cada acción a una persona concreta.
• Definir un resultado claro.
• Establecer una fecha exacta.
• Comunicarlo directa y claramente a la persona requerida.

No se trata de decir en alto «esto hay que hacerlo», sino «tú tienes este punto pendiente». Ahí es cuando empiezan a desbloquearse las cosas.

Referencias:

• https://es.wikipedia.org/wiki/Efecto_espectador

La semana pasada escribía Simón Muñoz esta entrada en su blog: https://www.estrategiadeproducto.com/p/el-manager-entrenador-jugador

Esto que describe ahí terminará llegando a España y el resto del mundo. Son corrientes que comienzan normalmente en USA y se van propagando con más o menos acierto país a país, empresa a empresa, tan pronto como algún libro sobre gestión moderna llega a manos de algún gerente.

Este efecto lleva viéndose décadas. Una nueva moda empieza, grita, asusta, se copia, se emula sin entender bien cómo debía funcionar y unos años después la moda se renueva. En ese momento lo cool será decir que aquello era un desastre y la causa de todo mal que aconteció después.

Ahora es el mánager entrenador-jugador, hasta hace poco era Lean Staffing o Slack Reduction. Nuevas ideas vendrán y otras se marchitarán (o quién se acuerda ya de Dare to Lead y las organizaciones Teal?).

Ninguna de estas ideas era totalmente cierta ni el santo grial. Tampoco son totalmente descartables ni ridículas. Solo fueron nuestro último salto de fe, algo que nos abrió un poco la mente hacia otras formas de pensar. Una cosa más a la que estar atento.

Suele existir la cultura o filosofía en muchas empresas por la que se debe mantener al trabajador siempre ocupado, siempre con una carga alta para que aproveche cada minuto de su tiempo y sacar así el máximo provecho de cada euro que se le paga por su sueldo.

Pero para poder lidiar con los problemas inesperados, con las incidencias que nos asaltan sin que estén programadas o con los asuntos que nos pueden hacer perder un cliente de por vida, se debe disponer de algún tiempo libre para reaccionar.

Solo tenemos un determinado número de horas al día, y si vamos con la lengua fuera y la agenda a tope, no vamos a poner dedicar el tiempo que merece una situación de alerta o la estrategia que nos deje ver el cuello de botella. No contamos con ese tiempo ni energía.

Hace algo más de una década, en el periodo en el cerraba mis asuntos en una compañía para empezar en otra unas semanas más tarde, pude resolver algunos de los problemas que más tiempo llevaban atascados. No fue magia. Simplemente, durante ese tiempo dejaron de llegar tareas nuevas, y puede centrarme en entender qué estaba pasando realmente y tomar las acciones que terminaron de darle la puntilla a lo que bloqueaba estos asuntos.

Desbloquéate una tarde, las dos últimas horas del viernes. Cancela las reuniones. Échate para atrás en tu silla sin hacer nada de lo agendado y cruza las manos detrás de la cabeza. En 20 minutos cogerás rápidamente el boligrafo para anotar todo lo que ahora te viene a la cabeza y que te va a ayudar el resto de la semana (o el mes/año).

«Calidad, calidad y calidad: nunca se aparte de ella, ni siquiera cuando no sepa cómo podrá mantenerla. Si transige en cuanto a la calidad, se convierte en una mercancía y acabará hundiéndose». -Gary Hirshberg.

Aunque resulte increíble, la mayor parte de los productos de chocolate que encontramos en la sección de dulces de los supermercados ya no son de chocolate con leche sino dulces aromatizados con chocolate. ¿Y eso por qué?

Los fabricantes en lugar de comprar granos de cacao de buena calidad, compran granos que no fueran tan caros a productores de cacao de calidad mediocre. ¿Quién se iba a dar cuenta?

Ahorrar dinero no sirve de nada si se degrada la calidad de su oferta. En su momento estas medidas para ahorrar costes no parecían influir demasiado en la calidad del chocolate. Con el paso del tiempo, sin embargo, los efectos acumulados minaron el sabor y la calidad del producto.

Si su objetivo es aumentar las ganancias recortando costes, no llegará muy lejos. Crear y entregar un producto de valor siempre costará cierta suma de dinero, por eso el recorte de costes tiene un límite si no quiere que afecte a la calidad del productos que ofrece.

Fuente: libro MBA Personal de Josh Kaufman.

La competencia de Apple parece enganchada en una lucha inacabable por darle alcance. Después de que Apple lanzara el iPhone, Blackberry quiso competir creando el Storm, que tenía la mayoría de sus características. El problema es que antes del lanzamiento del Storm, el iPhone ya había mejorado varias veces esas características en diversas versiones.

Por cada valor que añadas a tu producto, a la competencia le será más difícil igualar la oferta. No te centres en competir, compararte o igualar, céntrate en aportar más y mejor con cada nueva entrega. Tus competidores tendrán que hacer lo mismo.

Fuente: libro MBA Personal de Josh Kaufman.

Pensamos que el hito 1 del proyecto estará en dos meses, pero decimos tres. Añadimos un «colchón» para no equivocarnos y no fallar al cliente, que hará planes en base a nuestros cálculos.

Como resultado de esto, le añadimos una gran cantidad de tiempo a cada etapa del proyecto.

Según el libro MBA Personal, igualmente entregaremos tarde porque nos veremos afectados por tres mecanismos que se comerán esos márgenes:

1. Síndrome del estudiante: solo apretaremos fuerte la noche antes del examen/entrega.
2. La multitarea nos hará que tengamos todo abierto, todo empezado, nada acabado.
3. Los retrasos en cada una de las fases se irán acumulando, comiéndose su «colchón» y el de las siguientes. En cambio, los avances no se acumulan.

Tendremos más margen y una «falsa» seguridad en nuestras entregas.

Evítalo mediante:

1. La limitación del trabajo en curso (WIP).
2. Entregas frecuentes del trabajo.
3. Levanta rápido la mano con los bloqueos y decidete a atacarlos.

Seguro que te has visto en más de una ocasión en la que tienes que tomar una opción u otra y tu debate interno te reconcome. Debo elegir A o B, negro o blanco. Normalmente cuadriculamos las opciones e intentamos decidir cuál de las dos es la mejor.

En muchos de esos casos, ninguna de las dos opciones es perfecta, pero desde luego no lo es quedarte solo con una. Siempre que puedas, decide entre una Y otra. No entre una U otra.

Por ejemplo, en decisiones como estas:

1. Ahorrar para el futuro o gastarlo todo ahora. No tienes que ahorrar hasta el último céntimo. No tienes que comprar las botas de marca «gato» para ahorrarte 2.50 euros. Tampoco tienes que gastar todo lo que ganas como si te quemara en las manos. Haz ambas cosas: ahorra una parte de tu sueldo, cada mes, aunque sea pequeña. Y date un viaje a Fuerteventura cuando tengas un colchón. No he estado en Bali, pero dudo mucho que le saque gran ventaja a esta isla canaria (y seguramente te costará mucho menos que venir por aquí).
2. Me mudo a Madrid/Londres o me quedo en mi tierra. Tampoco tienes que morirte de viejo solo o sola allí. Vete unos años, vive la experiencia, llena una maleta más grande y luego vuelve a tu lugar de nacimiento (o a otro sitio) cuando el cuerpo te lo pida. Las experiencias que vas a vivir en 3 o 4 años en Berlín no las vas a poder acumular en más de 10 haciendo lo mismo de siempre junto a los tuyos.
3. Desarrollo solo nuevas features en la aplicación o me dedico solo a resolver la deuda técnica acumulada. Tendrás que seguir desarrollando nuevas funcionalidades, pero valora al mismo tiempo dónde están las incidencias más graves, las partes poco claras de tu código, sopesa cuanto cuestan y decide atacar una de las más fáciles por mes. Cuando te des cuenta, habrás ganado mucho en estabilidad sin perder los ingresos.

Seguro que hay muchas otras opciones en la que lo óptimo no es binario. Seguro que todo debe apostarse a blanco o al negro?

Hace algún tiempo me guardé este post de Simón Muñóz en mis notas, y creo que no puede hacer otra cosa que recomendarlo. Quizás porque me veo reflejado en estas líneas:

«Y como te encanta, lo haces. Te despiertas por la mañana pensando en lo que puedes crear, no en cómo puedes vender. Abres Visual Studio antes de consultar tu lista de tareas pendientes porque hay algo que necesitas ajustar. Inicias xterm antes que tu CRM (si es que tienes uno, que es que no) porque el servidor funcionaba un poco más lento de lo que esperabas y quieres revisar los logs«.

Aquí la entrada de Simón con su post la original de Jason Cohen: https://www.estrategiadeproducto.com/p/el-codigo-es-tu-enemigo

Sí, me temo que he perdido demasiado el tiempo a lo largo de mi vida. Empiezo a tener la sospecha, probablemente muy fundada, de que he perdido excesivo tiempo en lo que luego resultaron ser de poca utilidad (o simplemente y llanamente tonterías) para el entorno profesional. Al menos en su versión extendida 😀

Primero me pasó con los patrones de diseño. Leía todo sobre ellos. Cuando descubrí en la Universidad el libro de The Gang of Four sobre patrones a usar en la programación, quería usarlos todos, demostrar que los conocía, que todo el mundo viera lo brillantemente diseñada que estaban mis aplicaciones.

Los usaba fueran útiles o no, fueran necesarios o no, y lo que es peor, tanto si los entendía como si no. Se trataba de incluir el máximo número posible para demostrar solvencia y criterio.

Afortunadamente, esto se me pasó con el tiempo, y entendí muy bien lo que había pasado cuando años después leí sobre los millones de dólares empleados por las empresas en refactorizar su base código para eliminar diseños confusos e innecesariamente complejos que solo hacían más difícil que la gente supiera qué diablos prentendía hacer aquello.

Me ha pasado también con otras cosas, la reflexión en el código o los algorimos de ordenación, pero fue lo mismo con Agile y con Scrum.

Agile ha sido una gran ayuda profesional. No creo que nada me haya ayudado tanto en mis proyectos como la agilidad, pero me temo que me habría bastado con saber 4 o 5 principios y valores básico y luego tratar de ponerlo en práctica. Eso habría sido suficiente.

Sin embargo, el resto, todo lo que rodeó a eso, las ceremonias, las preguntas en las dailies, las discusiones si mencionabas la palabra «proyecto», si eras Agile de pura cepa y 5 jotas o no porque habías escrito la tarea a realizar en castellano simple y llano y no habías escrito una historia de usuario con el formato Connextra (Como usuario x, quiero la app hay y, de forma que obtenga z).

Más me habría valido aplicar el principio de Pareto, dedicar un tiempo a aprender las bases de la nueva moda del momento, y luego aprovechar el resto del tiempo a cosas más importantes.

Quién no se ha visto alguna vez tratando de sustituir un sistema viejo? Una forma de trabajar que ya no aguanta cambios, al que ya no le valen un simple trabajo de pintura para seguir adelante.

He estado leyendo últimamente sobre un patrón para afrontar estos cambios: el Strangler Fig pattern (el patrón de la higuera estranguladora) del que habla Martin Fowler en https://lnkd.in/ezBrWa6h

Este tipo de planta pone una semilla en la copa de otros árboles, comienza echando raíces hasta el suelo de forma que, con el tiempo y poco a poco, termina sustituyendo al árbol original que queda hueco en el interior de este tipo de Ficus.

En IT este patrón trata de hacer lo mismo, poner un proxy al frente de la vieja aplicación que derive, rama a rama, endpoint a enpoint, las llamadas originales hacia el nuevo servicio, construido con nuevas tecnologías y en la nube, dejando a la vieja aplicación hueca y sin uso.

Con cada funcionalidad que sustituyas aprendes, revisas y mejoras. Por otro lado, tampoco causas un gran cataclismo en la empresa al hacer un cambio drástico, de golpe, hacia un nuevo sistema que quizás no está lo suficientemente maduro como para soportar todo el peso de una compañía.

Cuando se trabaja en equipo notas bastante pronto qué compañeros son los que resuelven de forma más eficiente, los que te sacan de apuros ante cualquier asunto, los que tienen Acabativa como los llama Yoriento. No son los más inteligentes, ni los más experimentados ni los que tienen un título universitario de renombre. Son los más decididos, los que se deciden a empezar a cortar y tomar resoluciones. Los que se ponen el cuchillo en la boca y empiezan a avanzar, encuentren lo que encuentren.

En una gran número de ocasiones no queremos empezar a atacar un problema hasta no tener todos los datos, hasta no saber seguro qué hacer. El problema es que nunca podrás estar seguro. Solo estás buscando excusas en tu mente para empezar a trabajar fuerte en ello (mañana, cuando esté el tech lead será mejor día, seguro), para no decidirte por una de las opciones, y por tanto no correr el riesgo de equivocarte.

Mucho me temo que te vas a equivocar, tanto si lo pospones a mañana, a principios de mes, o al Q1, como si retrasarlo tu fuese a garantizar una ejecución perfecta. Pero no, casi nunca sabrás de antemano cuál es la mejor opción. Escoge la opción más «económica», la de menor coste o haz una prueba piloto/PoC, y mira los resultados. Seguro que aprenderás mucho más de ello que buscando excusas mentales para justificar por qué justo hoy no es buen día para empezar a teclear/diseñar/probar/construir.

Tampoco lo conviertas en un Spike eterno. Estos spikes o pruebas/investigación sobre un asunto han sido uno de los grandes males de Agile y los equipos de desarrollo. Suelen ser la excusa perfecta para darte tranquilidad mental y pensar que lo estás mirando, que estás en ello pero que todavía necesitas comprobar esto o aquello. Estas tareas de investigación deberían estar prohibidas si no entregan al finalizar un trabajo tangible, unas líneas de código o unos diagramas. Lo que sea que quiera que hagas, pero asegúrate de que te ayudan a atajar el problema, o incluso mejor, a descartar opciones.