Una de las historias de éxito más impactantes de la industria de la tecnología no se encuentra en un producto o una aplicación que ahorra tiempo. Tampoco se trata de cuánto control tiene el iPhone sobre nuestras vidas. En cambio, una de las mayores revoluciones detrás de escena en la tecnología es cómo se realiza nuestro trabajo diario. Es ágil.

Debido a que los tecnólogos tienen la propensión a empantanarse con el pensamiento excesivo mientras intentan resolver acertijos interminables y luchar contra obstáculos, los desarrolladores descubrieron una manera de luchar contra procesos engorrosos y simplificar todo.

La metodología ágil surgió de su frustración y cambió el juego. Lo mejor de “volverse ágil” es que, si bien puede parecer que adoptar sus principios puede ser difícil, no lo es en absoluto. Es bastante sencillo.

Trabajar con agilidad no requiere un título avanzado o una pila de libros para comprender. Si la gerencia y el equipo se comprometen a optimizar sus procesos y cambiar la cultura de cómo trabaja tu equipo, se trata de establecer buenos hábitos.

Si estás en un equipo no técnico, pero buscas mejorar la forma en que tu equipo logra sus objetivos, este artículo te ayudará. Te mostraré cómo los cambios en el proceso, la comunicación y la visibilidad cambiarán lo que estás haciendo, pero también harán que las cosas funcionen mejor.

Ser ágil ayudará a tu equipo a:

Identificar los malos hábitos laborales
Resolver cuellos de botella
Mejorar la colaboración en equipo
Crea una cultura de transparencia

Del desarrollo obstruccionista a la comunicación constante

En el pasado, los desarrolladores confiaban en un marco para sus actualizaciones en un “modelo en cascada” que enfatizaba una serie de pasos a lo largo del ciclo de desarrollo de software. La idea del homónimo de la metodología era que era como pasos en cascada hacia abajo en una “cascada” incremental de progreso.

Confiar en este proceso ayudó a los equipos de software a producir nuevas versiones de productos anualmente, no a través de lanzamientos continuos como es el estándar actual.

En los días antes de que todos estuvieran conectados a Wi-Fi, las empresas de software podían tomarse su tiempo y lanzar el software como un evento. ¿Recuerdas cuando cayó Windows XP? Eso fue un gran problema y una campaña de marketing aún mayor. Solo busca algunos de los videos en YouTube, son tan dignos de vergüenza, pero asombrosos.

Hoy, tenemos un ícono en la parte superior derecha de nuestra pantalla que dice que necesitamos descargar una nueva actualización y que no podemos usar nuestros dispositivos durante los próximos diez minutos. No hay fanfarria, no hay eventos de alfombra roja. Es una actualización, una de las muchas lanzadas a lo largo del año. Este ejemplo es la diferencia aparente entre las metodologías ágil y en cascada.

Mientras estaba de moda, el proceso de cascada fue bastante básico: todo siguió un patrón lógico y nunca se desvió del camino. La versión de Cliff Notes del desarrollo de la cascada funciona de la siguiente manera:

Requisitos: Todo está escrito, obsesionado, considerado y define qué aplicación se está construyendo, pero no el “cómo”. Una especie de fase de “arrojemos esta gran idea a la pared”.
Análisis: se analiza todo el asunto y algunas personas locas e inteligentes generan modelos, luego se elabora un caso de negocio para que el jefe deje que el trabajo suceda.
Diseño: Se sientan las bases de la obra. Se establece la jerga de la programación, se establecen los trabajos y se pone en marcha el plan. Este paso crea los huesos del proyecto.
Codificación: Se escribe código fuente real, el proyecto comienza a tomar forma.
Pruebas: esta fase está dedicada a ver si el proyecto tiene piernas.

¿Puede funcionar, incluso en sus etapas iniciales? ¿Qué se puede romper? Este es probablemente el aspecto esencial del desarrollo de una cascada.

Operaciones: las pruebas han terminado. El proyecto está listo para un entorno vivo. El sitio o la aplicación o lo que sea que esté listo para funcionar, o al menos lo suficientemente listo.

Durante un tiempo, este fue el estándar de oro. Hoy, no tanto. Waterfall se anticipó a sí misma porque no pudo evolucionar. Claro, algunos equipos todavía usan el método, pero es probable que sean negligentes al decir que no están haciendo el trabajo. Con tantos equipos de arranque, era necesario desarrollar procesos de racionalización.

¿Qué es exactamente la metodología ágil?

En su forma más pura, ser ágil significa agilizar todo. Cada proceso, cada comunicación, elimina la grasa de los huesos en aras de la adaptabilidad y el avance de los proyectos, incluso contra viento y marea.

En lugar de depender de prácticas cansadas e inflexibles, la agilidad se apoya en la comunicación y la transparencia como sus inquilinos más importantes. La idea es mantener informados sobre el progreso a los desarrolladores y “la empresa”, el marketing, las partes interesadas, etc.

La base del modelo se describe en el documento original, The Agile Manifesto, que debe su ADN a la entrega temprana, la planificación adaptativa y la mejora continua. Si tu equipo está constantemente enfrentando cuellos de botella con sus objetivos, ágil probablemente pueda ayudar a aliviar ese estrés debido a cómo el flujo de trabajo se mueve a través de los canales de comunicación diarios y semanales.

La transparencia es el camino

Probablemente, la piedra angular más importante de la agilidad es la transparencia. Todos los miembros del equipo deben ser abiertos y honestos acerca de su trabajo, lo que están haciendo, trabajar para lograr qué objetivo y cuáles son los próximos pasos. Eso es todo. Todo lo demás es secundario.

La adaptabilidad es lo esencial cuando se trabaja con un proceso ágil. La cascada permanece estática en la forma en que se ejecuta, mientras que la agilidad sigue la corriente. (Juego de palabras intencionado). Mantenerse en contacto constante con el equipo durante todo el ciclo de vida del proyecto ayuda a permanecer en la misma página. El espíritu de comunicación y colaboración, algunos puntos deben ser sostenidos como el evangelio según El Manifiesto Ágil:

1. Individuos e interacciones sobre procesos y herramientas
2. Resultados tangibles sobre el papeleo de las montañas
3. Responder al cambio en lugar de seguir un plan
4. Colaborar con los clientes, tomar en serio sus comentarios

Entonces, ¿cómo fomenta una cultura de transparencia e inclusión? Empiece con un stand-up diario.

Ponte de pie, no te sientes

El stand-up diario es una práctica recomendada fundamental y es muy beneficiosa para la vida y el éxito de sus proyectos. El ADN esencial del stand-up es la claridad y la comunicación, y es muy fácil de hacer.

Todas las mañanas, o al menos una vez a la semana, después de que todos hayan tomado su café, el equipo se reúne en el mismo lugar, a la misma hora. No sentarse. Situación real. Estar de pie, no sentarse recuerda a las personas que deben mantener una breve actualización. Todos se reúnen en círculo cerca de sus escritorios, en el centro de la sala, cerca de los bocadillos, lo que sea que funcione para el equipo.

El equipo girará en el sentido de las agujas del reloj e informará a todos sobre en qué están trabajando, qué han planeado para el resto del día y si hay obstáculos. No es necesario profundizar, manten las actualizaciones de los aspectos más destacados, o tu 20%, solo.

Si necesitas más tiempo para explicarle algo a un compañero de equipo, hazle saber que necesitas una sesión y sigue adelante. No obstruyes el stand-up con un desglose prolongado. Guárdalo para una reunión uno a uno. Una vez que la persona ha dado su actualización, es hora de la siguiente en la fila.

Si un miembro del equipo es remoto, hay muchas herramientas como Google o Zoom para usar, que ofrecen video directamente en el software. (Para el equipo de Michele Di Sei, usamos Zoom).

El punto principal del stand-up es que el equipo sepa cuál es su posición en un proyecto y, al mismo tiempo, mantiene la transparencia sobre su progreso. Es práctico, fácil y gratuito. Y lo más importante, mantiene a todo el equipo en sintonía sobre las cosas que están haciendo para impulsar tu negocio.

La agilidad se adapta a tu equipo

Hay algunas ideologías ágiles y tipos de formas de hacer el trabajo. Cualquiera que sea la combinación adecuada para ti, a menudo será el resultado de ajustes y pruebas. Los dos métodos más dominantes porque los equipos no técnicos se vuelvan ágiles son Scrum y Kanban.

¿Qué es Scrum?

Scrum adopta un enfoque iterativo, centrándose en definir objetivos antes de cada sprint. Cuando confías en Scrum, todo gira en torno al sprint.

Un sprint es un ciclo de tiempo destinado al trabajo de la semana, pero está diseñado para proporcionar valor. Todos los días, alguien del equipo da cuenta de su tiempo.

Si hay 8 horas en una jornada laboral, se contabiliza todo. Descansos, salir temprano, investigar, aprender, escribir correos electrónicos, lo que sea que alguien necesite lograr esa semana, todo se desglosa y se discute en la reunión semanal del equipo.

La idea del sprint es ser capaz de gestionar los obstáculos en función de la capacidad de cambiar de rumbo. Al comienzo de la semana, el equipo se reúne y discute en qué están trabajando a través de un 4-1-1. El equipo está de acuerdo en que estos pequeños proyectos orientados a tareas son significativos y luego comienzan el sprint de la semana.

El “Scrum Master” realiza un seguimiento de cómo el equipo hace las cosas y el ciclo se repite. Ya sea una vez a la semana o una vez al mes, el equipo se reunirá para una “retrospectiva” y discutirá lo que fue bueno, malo o feo del sprint. Hablarán sobre los desafíos que enfrentaron o si algo podría haber funcionado mejor.

Scrum se puede adoptar para equipos no técnicos, pero según la naturaleza de la bestia, las cosas pueden arruinarse rápidamente si un enfoque cronometrado no es factible. Si tu equipo no es bueno con las minucias de un proyecto, Scrum puede ser un poco demasiado geek.

PERO, no se pierde toda esperanza. Ni siquiera un poco. Lo más probable es que la respuesta a las oraciones de tu equipo sea utilizar un tablero Kanban. Kanban es fácil de usar y obtiene recompensas de inmediato.

Así es como se descompone Kanban

Kanban ha existido por un tiempo. Fue creado por Toyota en su día para aumentar la productividad en las fábricas. Funciona excepcionalmente bien cuando se combina con un stand-up diario.

Piensa en Kanban como una gran lista de tareas pendientes.

Mientras que Scrum está preocupado por las cantidades incrementales de tiempo que se dedican semanalmente, Kanban se dedica a la cantidad de trabajo que declara para sí mismo al comienzo de la semana. Kanban no se basa en el tiempo. Se basa en la prioridad.

Una vez a la semana, el equipo se reúne para planificar el trabajo de la próxima semana. Las tareas son manejables, no logros monumentales que requieren muchas horas. La idea es mostrar las pequeñas cosas que se incluyen en los grandes proyectos y, si es necesario cambiar el rumbo, ajustarlo a voluntad.

Una vez que el equipo está de acuerdo con el trabajo, pasa al tablero. Un tablero puede ser un tablero literal en la pared con notas Post-It o software como Trello. Cualquiera que sea tu método, hay tres columnas:

• Hacer
• En curso
• Hecho

Al principio, todo se cuelga en “Hacer” y pasa a “En curso” a medida que trabaja en su proyecto. A medida que se completan las cosas, pasa a la etapa “Hecho”. Si estás utilizando Trello, es fácil realizar un seguimiento de los análisis del equipo y cuánto trabajo se realiza semanalmente.

El modelo Stand-up + Kanban se puede aplicar a casi cualquier lugar de trabajo.

Otros principios ágiles podrían funcionar, pero estos parecen ser los más naturales y beneficiosos para un equipo no técnico. Existen libros sobre la metodología ágil, por lo que es fácil caer tratando de encontrar nuevas formas de hacer que tu equipo trabaje más rápido que nunca.

¿Qué tipo de modelos utilizas en tu equipo?

Y te invito a RESERVA UNA CITA HOY  de 30 minutos gratis conmigo y te enseño como el coaching puede beneficiar tu negocio.