De la idea a la ejecucion

Una amiga me decía hace poco que, en su trabajo, entre dos grupos uno haciendo Agile y otro no, trabajaban mejor los que no estaban haciendo Agile. Entiéndase por trabajaban mejor, eran más productivos y más felices. Está muy resumido, pero coincidió esta conversación con una semana en la que yo me había leído el post de Adrià Fontcuberta, Agile is Dead, que me encantó, y los dos artículos que enlazaba, y comentaba esto por Twitter:

Creo que hay un problema en no saber transmitir al "Negocio" las ventajas del Agile y demostrarlas.. mucha gente en España haciendo "Agile", no cumple ni el primero de sus principios: https://t.co/cvD5LnTa0w y así es complicado..

— Guillem Barnolas (@guillembarnolas) October 18, 2018

Recordé, de alguna forma, el post de la gente de Basecamp, Smiley, una app en 24h. Siempre he sido muy seguidor de esta gente, si no has leído Rework, estás tardando. El caso es que me hizo plantearme lo siguiente: Es verdad que Smiley, la app que comentan en el post, es razonablemente sencilla, pero cuánto tiempo pasa, de media, en la mayoría de organizaciones españolas, entre que alguien tiene una idea, piensa algo, lo comparte en un grupo, se decide hacer y se hace, está en producción, es usable por parte de usuarios externos a la organización.

Esto es aplicable a muchos campos de una empresa, no sólo al desarrollo software. Cuánto tiempo pasa, de media, desde que se inicia un proceso hasta que puede darse por terminado, ¿por cuántas fases pasa?, ¿Cuántas de esas fases le añaden valor?, ¿Cuántas son mera burocracia? He visto en multitud de ocasiones procesos que pasan por algunas fases de validación solo para que una persona se sienta útil. El décimo principio del Agile Manifesto dice: “Simplicity–the art of maximizing the amount of work not done–is essential.”

No solo esto, un problema añadido de los frenos, la burocracia, los sellados por triplicado, sobrevalidaciones, reuniones extensas en el tiempo y en la cantidad de gente presente, etc, es que la gente se aburre. Me resulta increíble la cantidad de compañeros de profesión que te confiesan que se fueron de este o aquel trabajo porque se aburrían, se a-bu-rrí-an… increíble, pero cierto… empresas con trabajo infinito y con la escasez de gente cualificada y luego la gente se aburre.

Pero, por resultar práctico y ofrecer algún tipo de herramienta. Es muy simple, no estoy inventando la rueda, pero requiere cierta capacidad de abstracción objetiva. Si eres de esas personas que tiene el es que esto siempre se ha hecho así en la punta de la lengua, tendrás que hacer un doble reseteo (Si en tu equipo hay mucha gente de ese tipo igual es algo a considerar, aunque esto para otro post). La idea es tener un cuaderno y un bolígrafo, muy 1.0 esto, cerca de la mesa, y empezar, en cada nuevo proceso en el que participemos, sea de la índole que sea, a apuntar cada acción y su momento cronológico. Esto nos dará una especie de cronograma de lo que ha ido sucediendo. Por ejemplo:

• Martes 21, 15:00. Escribo un mail a rrhh porque necesito un/a nuevo/a programador/a para el equipo.
• Jueves 23, 13:00. Me contesta rrhh que les rellene un form que hay con datos del perfil, etc.
• Viernes 24, 12:00. Ya he rellenado el form, lo mando.

Así hasta que entra la persona contratada a trabajar. Y así con todos los procesos. No es BPM esto, obviamente, ni es mandar humanos a Marte.

Luego hay que cuestionarse todos y cada uno de los apartados. ¿Es un mail lo mejor, para pedir un nuevo perfil? ¿No podríamos ahorrarnos los primeros dos puntos si relleno directamente un form que hay genérico?

La ventaja, de solo apuntarlo y de apuntar muchos, muchas de estas preguntas que no aparecen simplemente cuestionando uno a uno los puntos, aparecen al leer media docena de procesos terminados. Si siempre pido los mismos perfiles, por qué tengo que rellenar el form genérico. Si ya me ha validado la contratación de este perfil mi jefa, por qué luego IT tiene que validar la compra del equipo (portátil, etc), y muchas preguntas que surgen y que, en la mayoría de los casos, son burocracias a eliminar, exceso de validaciones, procesos heredados del pasado.

En desarrollo de SW uno puede hacer lo mismo, aunque en este caso yo incitaría a leer, imprimir, tatuarnos si hace falta, los 12 principios del Manifiesto Ágil, y hacer esto una y otra vez.. aunque bueno, probablemente si ya has hecho eso no necesitas este post.. La ventaja en el caso del SW, es que usando alguna herramienta tipo JIRA, etc, habrá muchas métricas que directamente se pueden extraer de la herramienta, pero también apuntando esto mismo pero de un ciclo de release, de una entrega concreta de un producto, una versión, sprint, lo que sea, se saca mucha información.

En resumen, hacemos Software y realizamos muchos otros procesos en cualquier empresa para mejorar algo, solucionar problemas, etc, el principal parámetro de medida debería ser conseguir hacer Software que funcione, de la mejor forma posible, en el mejor tiempo posible, y siendo felices en el proceso, y lo mismo con el resto de cosas que uno hace en la empresa. Pararse a analizar los tiempos muertos, burocracias, etc, de cualquier proceso del día a día, agiliza y da felicidad :)

Si te ha sido útil, te ha parecido una chorrada o conoces otras formas de hacer esto mismo y te apetece comentarlas, no dejes de hacerlo :)..