Aprenda cómo los equipos y las compañías no tecnológicas han utilizado metodologías ágiles para hacer que sus negocios sean más exitosos.
Desde 2001, cuando se formalizaron los valores y principios de Agile en el Agile Manifesto, Agile se ha convertido en el proceso estándar para el desarrollo de software. Los estudios muestran que cerca de un tercio de todos los proyectos de software utilizan alguna forma de metodología ágil.
Aunque Agile fue creado con el software en mente, los equipos no tecnológicos han comenzado a adoptar Agile. Un ejemplo notable es que NPR ha usado Agile para reducir los costos de programación hasta en un 66%. Al igual que la gente de NPR, muchos equipos no tecnológicos han descubierto que emplear una mentalidad ágil y usar prácticas ágiles puede ayudar a su equipo o negocio a hacer más cosas, hacer que sus clientes estén más contentos y hacer que sus equipos colaboren más.
VER: Kit de recursos para la gestión de proyectos de Tech Pro Research
¿Qué es Ágil?
Lo que está de moda en ConsejoTecnologico.com
Antes de describir cómo los equipos no tecnológicos han utilizado con éxito las prácticas ágiles en sus equipos y negocios, repasemos qué es exactamente Agile.
El Manifiesto Ágil surgió de un grupo de desarrolladores que querían escribir mejor software, y el movimiento Ágil ha sido generalmente tomado como un enfoque de gestión de proyectos. Scrum, Kanban y XP son los frameworks de desarrollo de software más utilizados bajo el paraguas de Agile. Y, cada uno de estos marcos se deriva de los valores del Manifiesto Ágil:
- Individuos e interacciones sobre procesos y herramientas (O: Hacer que la gente se auto-organice y hable entre sí sobre lo que está trabajando. A nadie le gusta ser micromanejado!)
- Trabajar con software sobre documentación completa (O: Hacer las cosas es mejor que hablar o escribir sobre cómo hacer las cosas. Cuando haces algo y se lo muestras a la gente, puedes ver lo que funciona y lo que no funciona.)
- Colaboración del cliente sobre la negociación del contrato (O: Manténgase en contacto con sus clientes. Dales lo que quieren y necesitan, o se te acabarán los contratos para firmar.)
- Responder al cambio en vez de seguir un plan (O: Las cosas cambian. Seamos flexibles!)
Hay muchas prácticas ágiles – todas las cuales están subordinadas al mayor esfuerzo de operar dentro de los valores ágiles. Sin embargo, algunas prácticas clave que la mayoría de los marcos de trabajo comparten incluyen:
- Creación de una lista (o atraso) de trabajo priorizado
- Escribir boletos que describan todas las unidades de trabajo necesarias para llevar a cabo las tareas atrasadas.
- Mostrar juntas públicas para que el equipo y las partes interesadas puedan hacer un seguimiento del progreso
- Planificar el trabajo a realizar en un sprint, o en un período de tiempo determinado (generalmente de 2 a 4 semanas.
- Llevar a cabo reuniones diarias de pie de 5-10 minutos donde el equipo verifica el progreso y discute los desafíos.
- Realizar reuniones retrospectivas cuando termine el sprint para discutir lo que salió bien, lo que salió mal y lo que se podría mejorar.
Muchos equipos de software siguen un marco ágil de cerca, empleando meticulosamente cada una de las prácticas ágiles, incluyendo las anteriores. Esto ayuda a estos equipos a satisfacer las necesidades de sus clientes, responder a los requisitos cambiantes y maximizar su rendimiento.
VER: Desarrollo ágil: Hoja de trucos
Historias de éxito ágiles de equipos no tecnológicos
Veamos cómo tres equipos o negocios no tecnológicos emplearon algunas de estas prácticas ágiles de manera efectiva.
Cómo la creación de una cartera priorizada ayudó a un equipo no tecnológico a crear sinergias y a comunicarse con las partes interesadas.
Marney Andes es la Directora de Aprendizaje y Desarrollo de Air Methods, una compañía de transporte aéreo de emergencia. La empresa cuenta con unos 4.500 empleados y 2.000 miembros del personal médico externo. Andes y su equipo tienen la tarea de crear o administrar la estrategia para crear capacitación y educación para la organización.
Andes dice que cuando llegó a Air Methods, las partes interesadas (e incluso su propio equipo) no tenían idea de cuánto tiempo le llevaría crear todas las capacitaciones o proyectos necesarios.
Así, Andes y su equipo comenzaron a utilizar la práctica ágil de mantener un backlog priorizado en una tabla Trello pública. La junta enumera las solicitudes de capacitación, las capacitaciones que se están construyendo en la actualidad y mucho más. Cuando las solicitudes de las partes interesadas se agregan a la junta, Andes y su equipo le dan a la solicitud un código verde o rojo; verde significa que actualmente pueden asumir el proyecto, y rojo significa que va a la reserva.
Cada mes, el grupo de interesados se reúne para priorizar el trabajo atrasado, «votando democráticamente sobre lo que es empujado a la cima».
Andes dice que usar la práctica ágil de la cartera priorizada ayuda a «comunicar las expectativas al negocio sobre por qué y cómo estamos haciendo las cosas tal como somos». También dice que esta práctica ha creado sinergia dentro del grupo. «Pueden ver lo que los otros grupos están haciendo. Tampoco están haciendo el trabajo del otro, ya que pueden ver que algo ya fue creado… reduce el desperdicio».
Cómo un editor tradicional desarrolló productos de forma iterativa con la retroalimentación de los clientes
Antes de convertirme en gerente de productos de software, trabajé en una editorial tradicional como editor de un producto curricular impreso. Nuestro equipo editorial aplicó facetas de la práctica ágil de desarrollo continuo para crear y mejorar nuestro producto antes y después del lanzamiento.
Cada semana desarrollamos una semana de clases. Una vez que tuvimos un borrador terminado, lo enviamos a un grupo de probadores alfa que usaron el producto con niños de verdad y nos dieron su opinión sobre lo que funcionaba y lo que no. Incorporamos esa retroalimentación y luego la enviamos a un grupo de probadores beta, quienes hicieron lo mismo.
Incluso en este entorno tradicional de publicación impresa, pudimos poner una versión básica del producto en manos de los usuarios lo antes posible, de modo que pudimos empezar a recopilar comentarios sobre cómo podríamos mejorarlo. Esto nos ayudó a identificar los defectos y a corregirlos antes de su publicación.
Cómo un equipo de reclutamiento utilizó una tabla Kanban para ser más eficiente
Mientras trabajaba en Return Path, proveedor de soluciones de datos por correo electrónico, William Kammersell (ex entrenador de Agile y ahora Director de Productos de CA Technologies) organizó un AgileCamp para difundir Agile a través de equipos no tecnológicos. Recordó cómo el equipo de reclutamiento utilizó prácticas ágiles para agilizar la forma en que manejaban las pantallas de los teléfonos de los candidatos.
«Un equipo de reclutamiento no puede predecir los resultados de los candidatos», dice Kammersell. «La contratación de personal puede tener un flujo de procesos bastante estándar de principio a fin. Sin embargo, hay factores en el día a día que pueden cambiar rápidamente el flujo». Debido a la naturaleza irregular de la contratación, el equipo debía ser flexible y eficiente, manteniendo al mismo tiempo la transparencia entre su equipo y las partes interesadas. Si no lo fueran, un reclutador podría quedar estancado en el flujo de trabajo, haciendo que los candidatos abandonen, que los gerentes se vuelvan impacientes, o que el costo de contratar aumente significativamente.
Por lo tanto, Kammersell trabajó con el equipo para utilizar la práctica de la tabla Kanban del framework Kanban Agile. El equipo mostró el trabajo que tenían en su plato en una pizarra física pública para que el equipo y otras partes interesadas lo vieran.
Kammersell dice que mostrar una pizarra Kanban ayudó a los miembros del equipo a entender cuando otro miembro del equipo estaba sobrecargado. «Tradicionalmente, la gente no comparte lo que está haciendo y puede que no sepa cómo puede ayudarse entre sí», dice Kammersell. «Las cosas se alargan así.»
Comience a usar prácticas ágiles con su equipo o negocio
Como dice Martin Rowe del Petroc College de Cornualles: «Incluso los trabajos mal implementados[ágiles] funcionan. Aplicar un poco de Agile puede ayudar».
Pero, antes de que los equipos den el paso de aplicar Agile, necesitan preguntarse por qué quieren usarlo. ¿Qué problemas tienen sus equipos o negocios no tecnológicos que una mentalidad y prácticas ágiles podrían ayudar a resolver?
Tal vez los miembros de su equipo tengan dificultades para duplicar los esfuerzos de los demás. Trate de mantener una postura diaria: una reunión de 5-10 minutos en la que cada uno comparte lo que ha hecho desde ayer, planea hacer hoy, y descubre que está bloqueando su progreso. Consejo: ¡que todos se pongan de pie durante la reunión para que sea breve!
Tal vez los miembros de su equipo no se sienten confiados o empoderados para hacer lo que se necesita hacer para alcanzar las metas. Trate de crear un atraso de trabajo para ser completado durante un sprint (intente 2-4 semanas), y permita que el equipo elabore el plan para llevar a cabo el trabajo.
Tal vez su negocio no pueda entender cómo darle al cliente el producto que desea. Trate de entregar lo más pequeño y valioso lo antes posible a un pequeño grupo de clientes. Obtenga retroalimentación, mejore el producto y luego repita.
¿Todavía no está seguro de por dónde empezar? Kammersell recomienda probar Agile como un experimento. Su sugerencia es probarlo durante tres sprints con retros intermedios que permitan al equipo iterar en su proceso. Si al final de tres sprints el experimento es un fracaso, el equipo o los negocios probablemente habrán encontrado al menos una parte de la mentalidad y las prácticas ágiles que los hacen un equipo más exitoso.
Use Agile para comenzar a usar Agile? ¡Esa es una forma de hacerlo!