Tengo un gran amigo, que trabaja para una empresa que este año, tuvo como meta usar Scrum en la empresa para agilizar sus procesos, mi amigo trabaja en un área de servicio, la situación interesante es que incluyeron a la gente de productos y negocio al proceso, y los pasos que tomaron fueron más o menos los siguientes:

Capacitaron de manera formal a TODA la empresa, fueron a cursos de certificación y tienen poster pegados con frases de estas ágiles como:

“Ágil significa reemplazar la predictibilidad falsa por le EFICIENCIA”

“Seguimos el manifiesto ágil”

Y otras tantas, unas en inglés sujetas en su pizarrón de corcho, todo muy startup e interesante la decoración.

Y ciertamente lograron que la organización independientemente del área o puesto, empiece a hablar de reuniones ágiles, de sprint review y de Backlogs, y existen Scrum Owner y Scrum Master y todo lo que conlleva este tipo de procesos, la verdad es que ha sido un esfuerzo interesante, pero todo en la vida tiene un pero, máxime cuando es un cambio de paradigma, no es un afán de criticar sino de ofrecer una alternativa más funcional, veamos que pasó en la línea de tiempo:

Les tomo unos meses estar fuera de la oficina tomando cursos, para todas las áreas, y finalmente cuando llegó el día, hasta un nombre importante le pusieron a todo este proceso, olvidaron la corbata y el saco (para estar ah doc) y se volvieron startup su ambiente en una empresa muy grande (y es un banco).

Como lo he observado sucede en dos partes esta transformación de paradigma:

Paso 1: Capacitan a todo el personal posible para el nuevo paradigma

Paso 2: Deben aplicarlo y se vuelcan las dudas y … lamentablemente las interpretaciones de cómo debe ser aplicado

Y tuve la suerte de ser invitado a algunas de estas reuniones de inicio de procesos, adelanto a la conversación que este problema lo tuvimos nosotros hace tiempo, de ahí que sepamos en carne propia para donde van los problemas y encontramos algunas alternativas de como mitigarlos, dicho lo anterior, seguimos con el caso de mi amigo.

Y en mi calidad de observador, diré que me costó mucho trabajo no hablar, en verdad mucho trabajo, pero bueno, toca quedarse como mero observador de la reunión, y empezó de esta manera:

Mostraron una herramienta Kanban, asegurando que era hacer Scrum, ya que dentro de esta pared Kanban colocaron los Sprint, los backlogs y los responsables de cada actividad

Mostraron unos blueprints para seguir algunos procesos de usuario, y revisamos unas cuantas paredes kanban (cerca de 6), evidentemente estaban todos los interesados reunidos, y definitivo el negocio era el único amo y dios de el backlog, el resto si era para los mortales, y era genial como se movían los postits en el Kanban para cambiarse de estatus cada tarea.

Si se nota al final del párrafo mi ironía, es que no lo pude evitar, en ese momento no sentía nada, solo asombro ante tal escenario, pero termino mejor ya que el final de la reunión fue algo que desató este artículo para mostrar mi punto de vista y lo que nos funciona, esperanzado que le ayude a alguien y a mi amigo, sobre todo.

Para cerrar la reunión, empezaron a preguntar que estaba terminado y que se PODÍA hacer para moverlo de estatus a “haciendo” en la pared Kanban, y lamentablemente se movieron muchos elementos, por cierto, cada sprint era un detalle de tareas no una historia de usuario, y detallada mucho más de lo que me gustaría … la reunión duró cerca de 4 horas.

Y ahí me quede impresionado, con un problema real, todas las tareas estaban ordenadas, teníamos pendientes en el backlog, el negocio estaba perfectamente de acuerdo, operaciones sabía que pendientes se revisaron, desarrollo estaba enterado de la pila de cosas que tenía que hacer y se documento fechas y comentarios en la pared kanban, como lo manda Scrum, y al final todos felices porque por fin, estamos avanzado haciendo Scrum en la empresa, ahora sí vamos a caminar perfectamente y de manera ágil.

Ciertamente es más fácil criticar cuando no eres parte del problema, pero siempre he dicho que cualquier pe…rsona puede criticar, pero para estar un poco por encima, debes proponer la alternativa de mejora.

Mi impacto real, es la manera en que combinan muchas empresas como donde trabaja mi amigo, los modelos y corrientes que existen, todas interesantes sin duda, pero cada cual tiene su tiempo y su momento por ello están, por ejemplo:

Kanban: la idea central es visualizar el trabajo que se hace, no documentarlo, pero la máxima contribución de este sistema es algo muy importante, el WIP (Trabajo en progreso) esto quiere decir, que dentro de la columna de “haciendo”, solo debe tener tantas actividades como el equipo sea capaz de cumplir, cualquier cosa por abajo o por arriba de ese número es mentirse vilmente, ejemplo: si mi equipo es capaz de hacer 3 actividades por el número de miembros o de horas, solo podemos hacer de 1–3 actividades si hacemos o “ponemos” más, quiere decir que se harán a prisa o comprometemos calidad o sobre trabajaremos o algo malo pasará, en lo personal me parece que este indicador es la cosa más importante que kanban ha hecho, pero que se confunde con Scrum que es otra cosa, de hecho existe ScrumBan para ser más claro, imagina que cara puse cuando veía muchas actividades en “haciendo” sin que nadie dijera nada

Blueprints: Es tomado de Service Design, que es una cosa maravillosa y apenas estoy entendiendo como aplicarlo, los blueprints vienen de ingeniería y son diseños para entender como funcionan los procesos, o eso entiendo apenas, estoy sobre este tema porque me parece que es muy importante

Scrum: No solo es hacer reuniones de pie y preguntar las 3 cosas, tener o querer un equipo auto organizado y evitar documentar, es de ayuda sin duda alguna, pero no puede solo y es mi punto a reconocer y comentar con mi amigo

Al final de la reunión, me volví a mi amigo y le pregunté: — ¿cuáles son los objetivos de negocio que persigue este sprint?

-Y me miró con cara de: ¿estás menso o qué? Si estuviste dormido en la reunión ni lo notamos, porque se trataron todos, ¿no lo ves?

– Le dije: No, me refiero a si está claro para todos que la base de ágil es ENTREGABLES CORTOS que se puedan probar, algo como un MVP para el mercado

Luego, le comenté si ya tenían el publico con quién validar el producto, si habían investigado la viabilidad de la iniciativa de innovación que tenían delante, y que pruebas previas habían hecho, para acto seguido, documentar las acciones y gestionarlas con alguna metodología ágil (hay más que Scrum, por cierto) y revisar la visibilidad de avance con Kanban, y mi amigo se quedó callado.

Y le comenté como hacemos nosotros, después de varios experimentos, ahora estamos con:

Negocio — Estrategia — Seguimiento — Control — Regresar

“Nos enfocamos en procesos no a las herramientas”

Negocio: Si no mides la cantidad de dinero que gastas vs la que recibes, y que siempre sea mayor a cero y positivo, no tiene caso que sigas invirtiendo en ese proyecto (eso es un modelo startup o un caso de negocio), así que primero lean startup para ayudarnos a definir la estrategia y no perder de vista que se trata de ingresar más o gastar menos

Estrategia: Para lograr el objetivo de negocio, siempre se requiere un mapa o guía para lograrlo, para saber que paso sigue y no estar definiendo sobre la marcha, de modo general no particular, para eso usamos Service Design y los Blueprints

Seguimiento: Ahora sí, volteamos a Scrum para definir de acuerdo con el mapa, que entregables cortos deben hacerse, me encanta la reunión diaria, por qué como dicen los que saben:

“Un proyecto se atrasa día a día”

PmBok

Control: Para el control, y revisar que se trabaje sobre cierto ritmo, y no tener huecos de actividades, usamos kanban (trello no es kanban per se, es una herramienta online pero existen otras) y una pared llena de papelitos de colores es suficiente y funciona mejor

Regresar: debemos volver cada cierto tiempo, para probar los entregables con el mercado y validar la idea (lean) y caso contrario pivotar

Presentó mi experiencia tal como es, en mi nano empresa, es valiosa porque podemos hacer ajustes al proceso tan rápido como se requiera, y por que ese valor de laboratorio ahora es valioso para las grandes empresas y este conocimiento y experiencia es más barato de hacer con nosotros

Los pequeños ahora somos valiosos, experimentamos antes y contribuimos con costos menores