Una breve introducción a Agile, parte 1

El término Agile es cada vez más común en una gran cantidad de escenarios y contextos distintos a los del mundo de desarrollo de software donde tuvo su origen, incluido el de Experiencia de Usuario.

Contrario a lo que comúnmente se interpreta de primera instancia, Agile no se trata simplemente de cómo desarrollar productos de forma rápida. Agile busca, en esencia, transformar paradigmas y organizaciones para propiciar entornos de trabajo con personas felices, motivadas y comprometidas, logrando en consecuencia, productos exitosos y clientes satisfechos.

Contexto histórico sobre Agile

Actualmente, Scrum, Kanban y eXtreme Programming (XP) son los enfoques o frameworks más representativos de Agile; sin embargo, otros métodos relativamente emergentes que incorporan en su definición parte de los conceptos clave del Agilismo han ganado una creciente popularidad, sobre todo en el ecosistema del emprendimiento, como Lean Startup, Lean UX o Design Sprint.

Más allá de los frameworks, la verdadera naturaleza de Agile radica en la profunda transformación de la manera en la que pensamos y nos comportamos. Es decir, el Agilismo no sólo consiste en la adopción de procesos y herramientas, sino en un cambio de cultura, verdadero, profundo y significativo.

Para comprender los motivos por los cuales Agile hace un llamado al cambio de paradigmas, es necesario hacer un recuento de su origen y evolución porque, como decimos en UX, el contexto lo es todo.

El Modelo en Cascada y los antecedentes de Agile

Explicar qué es Agile implica ineludiblemente hablar primero de su némesis: el Modelo en Cascada. De la misma forma en que no es posible explicar La Fuerza sin el Lado Oscuro, para entender el surgimiento de Agile, es importante comprender las razones de su origen, aquello a lo que trataba de oponerse.

El Modelo Secuencial de Procesos o Modelo en Cascada (Waterfall Model) es un modelo metodológico de la industria de desarrollo de software que surgió en la década de los 70. Sin entrar demasiado en detalle (porque para eso está Wikipedia) el Modelo en Cascada propone una serie de pasos, rigurosamente en secuencia, para el desarrollo de software:

  • Especificación de requerimientos
  • Diseño
  • Implementación
  • Verificación
  • Mantenimiento
Modelo en Cascada
Modelo en Cascada

 

Lo que vale la pena destacar del Modelo en Cascada es que, de alguna u otra forma, surgió como una herencia del pensamiento Taylorista, que tuvo su máximo esplendor durante la Revolución Industrial, y que definía a los procesos como una división de tareas bajo un ambiente rígido. En el Taylorismo, las personas no tenían participación ni control en los procesos, “todo lo que queremos de ellos (los obreros) es que obedezcan las órdenes que les damos, que hagan lo que les decimos y que lo hagan rápido“, decía Frederick Taylor en 1906.

Recreen en su mente la mítica escena de Charles Chaplin en Tiempos Modernos. Eso es el Taylorismo. Reemplacen la cadena de montaje por líneas de código. Eso es el Modelo en Cascada.

Escena del largometraje Tiempos Modernos (1936).
Escena del largometraje Tiempos Modernos (1936).

La razón por la que la naciente industria del software de la década de 1970 consideró que era buena idea adoptar un modelo secuencial, rígido y que restringía tanto la libertad y creatividad de las personas sigue siendo un misterio y quizá el mundo nunca lo sabrá.

Es tan controversial el tema sobre cómo fue posible que el Modelo en Cascada se haya convertido en un estándar de la industria del software, que existen varios mitos alrededor, uno de ellas señala que desde su origen, el modelo fue malinterpretado y que su autor, Winston Royce, en realidad quiso decir que el modelo era una mala idea y que no era recomendable implementarlo pues “invitaba al fracaso”. No es broma. Incluso el Departamento de Defensa de los Estados Unidos, en 1985,  tuvo esa “interpretación” incorrecta y estandarizó su propio proceso para el desarrollo de software basado en el modelo de Royce y como suele ocurrir con casi todo, el resto del mundo siguió el mismo estándar.

Las circunstancias del contexto también pudieron influir notablemente en la estandarización del Modelo de Cascada, piensen en la alocada década de los 70: la tecnología era accesible sólo para unos pocos privilegiados; apenas eran los albores de Internet; Steve Jobs y Bill Gates eran un par de jóvenes que iniciaban la construcción de los imperios de Apple y Microsoft, respectivamente. Si lo vemos en perspectiva, el Modelo en Cascada se convirtió en el modelo más utilizado simplemente porque en ese momento se concebía al software como algo tan complicado, grande y robusto que sólo era posible producirlo bajo un proceso riguroso y detallado.

Uso de la tecnología a principios de la década de los 70.
Uso de la tecnología a principios de la década de los 70.

Al paso de los años, el mundo empezó a cambiar drásticamente gracias a una vertiginosa revolución de las Tecnologías de la Información. La tecnología llegó a la vida cotidiana y el cliente empezó a convertirse paulatinamente en el centro del universo en el desarrollo de productos y servicios.

Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.
Publicidad del lanzamiento de Apple II (1977). La tecnología llega a los hogares.

La industria del software tuvo que empezar a adaptarse al nuevo escenario y los problemas del Modelo en Cascada comenzaron a emerger:

  • Poco o nulo involucramiento del cliente a lo largo del proceso.
  • Limitación de la participación activa de las personas responsables del desarrollo.
  • Incapacidad de responder satisfactoriamente ante cambios de negocio.
  • Documentación excesiva del proceso.
  • Tiempos demasiado largos de producción.
  • Recuperación tardía y costosa ante errores.

La caja de Pandora fue abierta.

Los orígenes de Agile

El Movimiento Agile surgió como una reacción de hartazgo a todo lo que significaba el Modelo en Cascada.

Para muchos expertos, el año 1994 representa el punto de quiebre en la historia del Agilismo, cuando todos los problemas que el Modelo en Cascada venía arrastrando por más de dos décadas quedan exhibidos en CHAOS Report, un estudio que reveló una cifra contundente e irrefutable:

más del 80% de los proyectos de software se entregaban con sobrecostos, en forma tardía, sin cumplir las expectativas de los clientes o incluso eran cancelados antes de concluirse.

La industria del software estaba en crisis, empezaron a surgir o a cobrar notoriedad métodos alternativos al Modelo en Cascada como Scrum, eXtreme Programming (XP) y Lean Software Development, por citar algunos. La nueva “sombrilla” de métodos empezaron a ser identificados con el nombre de Metodologías Livianas (Lightweight Methodologies). Comenzaba así la versión en el mundo del software de Civil War, o eras #teamwaterfall o eras #teamagile.

Hay que abrir un breve paréntesis en esta línea del tiempo. Aunque muchos métodos relacionados con Agile empezaron a ser cada vez más populares a partir de la década de los 90, no significa que hayan sido creados simultáneamente, algunos conceptos clave surgieron desde mucho tiempo atrás:

El siguiente hito en la historia del Agilismo llegó en el 2001 cuando un grupo de profesionales y entusiastas de los métodos livianos se reunieron “en lo alto de una montaña” (como suele contar Mike Beedle) para discutir cómo la industria del desarrollo de software debería hacer frente al nuevo contexto, cómo responder de mejor forma a los cambios que surgían por intereses de negocio y cómo consolidar una alternativa los procesos tradicionales de desarrollo de software caracterizados por la rigidez de su proceso. El Manifiesto Ágil vió la luz.

El Manifiesto Ágil

Estamos descubriendo mejores formas de desarrollar software…

Así inicia el Manifiesto Ágil, el documento que representa la declaratoria de principios de todo lo que significa el Agilismo.

Cuatro valores y doce principios. Es todo. Por más de 15 años, cada línea escrita en el Manifiesto Ágil ha permanecido intacta. Señal de su vigencia y pertinencia.

Valores:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Principios:

  1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
  2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
  3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
  4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
  5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
  6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
  7. El software funcionando es la medida principal de progreso.
  8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
  9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
  10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
  12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Waterfall vs. Agile

Lo que siguió después de la aparición del Manifiesto Ágil fue una disputa cada vez más frontal por la supremacía en la industria de desarrollo de software entre Waterfall y Agile; de manera simultánea, el mundo seguía cambiando, llegó el mundo de los dispositivos móviles, de las apps y startups.

En la versión 2012 del CHAOS Report (ahora llamado CHAOS Manifesto) se publicó una conclusión simbólica sobre la batalla entre Waterfall y Agile:

El proceso ágil es el remedio universal para el fracaso en los proyectos de desarrollo de software. Las aplicaciones de software desarrolladas a través del proceso ágil tienen tres veces la tasa de éxito del método en cascada tradicional y un porcentaje mucho menor de demoras y sobrecostos. El software debería ser construido en pequeños pasos iterativos, con equipos pequeños y enfocados”.

Parecía que la batalla tenía un ganador.

Ser Agile vs Hacer Agile

Ante el éxito de los métodos ágiles en la industria del software, su popularidad y adopción traspasaron fronteras. El ecosistema de emprendimiento y otras industrias distintas a las del desarrollo de software empezaron también a abrazar las prácticas ágiles. Hacían lo correcto, aunque por las razones incorrectas.

La promesa de ser el “remedio para el fracasso en los proyectos” comenzó a ser una carga muy pesada para el Agilismo y para lo que, insisto, realmente significa.

En 2015, otra vez el CHAOS Manifesto dió a conocer una cifra reveladora:

61% de los proyectos ágiles, son ágiles solamente en el nombre.

El Agilismo verdadero es orgánico, emerge, fluye; simplemente ocurre o perece en el intento. Es independiente de cualquier práctica dogmática, por encima incluso, de un “dogma ágil”, por contradictorio que esto parezca. Individuos e interacciones sobre procesos y herramientas. El origen de todos los males de la práctica incorrecta del Agilismo radica en la inadecuada comprensión del Manifiesto Ágil y todo lo que conlleva.

Agile no es una metodología. No es una colección de procesos y herramientas. Agile es un mindset, una forma de pensar y actuar distinta para encontrar mejores formas de hacer las cosas a través del empirismo y el aprendizaje.

La verdadera promesa de Agile

Quiero concluir con una cita del libro Por un Scrum Popular: Notas para una Revolución Agile, de Tobias Mayer y traducido al español por Alan Cyment:

“Pinten en el aire una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente donde se fomenta la escucha activa, la comunicación abierta y la colaboración a mansalva.

Estoy convencido de que se puede convertir esta imagen en realidad usando un mecanismo simple y conocido, que les permitirá llegar desde su crudo presente hasta ese sitio donde les gustaría estar. Y no, ese mecanismo no se llama Scrum.

No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión. Hay una sola persona que puede hacer realidad esta visión. Ese alguien eres tú”.

Espero que este llamado, los haga pensar en abrazar el Agilismo por las razones correctas.

Diseñador de Experiencia de Usuario. Scrum Master Certified. Fotógrafo. Ha participado en proyectos vinculados a HCI, usabilidad y UX en el ámbito académico, empresarial y gobierno desde 2007. Es parte del equipo de UX Nights.

Licenciados en Experiencia de Usuario

He encontrado recientemente en foros y plataformas de discusión para profesionales de UX con estudiantes universitarios preguntando por las habilidades que se requieren para aplicar a un puesto trabajo de “diseñador de experiencia de usuario”.

Por lo general el perfil de estos jóvenes es de diseñadores gráficos y la mayoría de las respuestas involucran con familiarizarse con técnicas de investigación y mejores prácticas. La pregunta aquí es: ¿es eso lo único que se necesita para portar el título de Diseñador de Experiencia de Usuario en nuestras tarjetas de presentación? ¿Cómo puede existir un perfil de Diseñador de Experiencia de Usuario si nadie entiende bien qué hacemos?

La respuesta a estas preguntas es una que ya hemos abordado numerosas veces en UX Nights: el problema de la enorme variedad de especialidades involucradas en el área de Diseño de Experiencia de Usuario. La contraparte de este problema son los requisitos que las empresas colocan en sus vacantes, cuando anuncian que necesitan un “Diseñador de Experiencia de Usuario” que en la mayoría de los casos se traduce como la de un Diseñador Gráfico que sepa programar porque tener a una persona que haga dos tareas es más barato.

Este dilema se centra en que no hay un plan de carrera que tenga el título “Diseñador de Experiencia de Usuario” y que unifique el currículum de los profesionales. Decir: “soy Diseñador De Experiencia de Usuario” es como decir “Soy Coordinador“.

Ok, pero ¿en realidad a qué te dedicas?

Disciplinas de UX

“User Experience Designer” no es un título que alguien se pueda auto-asignar en base a sus estudios. Hay Diseñadores de Experiencia de Usuario que son psicólogos, diseñadores, programadores, expertos en HCI, etc. He tenido oportunidad de conocer comunicólogos y hasta licenciados en Historia Del Arte que se dedican a algún aspecto de UX.

la etiqueta de “Diseñador de Experiencia de Usuario” no es un título que ofrece alguna institución de estudios superiores, porque es como si alguien pudiera estudiar para ser “Gerente” o “Coordinador Regional”. El título de Diseñador de Experiencia de Usuario hace referencia al área profesional -que lo que haces, lo haces orientado al Usuario- pero por si mismo no significa nada.

El Rol de un Diseñador de Experiencia de Usuario es el de resolver problemas. Para los fanáticos del cine como yo, la referencia obvia es Mr. Wolf, de Pulp Fiction. Un Diseñador de Experiencia de Usuario es un Mr. Wolf para las empresas o las organizaciones. Nos llaman, nos cuentan el problema y dependen de nosotros para encontrar la mejor solución.

Mr. Wolf podría haber estudiado Diseño Gráfico, Ingeniería en Sistemas o cualquier otra cosa, pero su valor radica en el conocimiento que brinda la experiencia, no sus conocimientos teóricos. Mr. Wolf lo ha visto todo, conoce todas las herramientas, tiene todos los contactos y es su trabajo y su responsabilidad atar los cabos para resolver el problema de su cliente.

Salir de la Universidad y aplicar a un rol de Diseño de Experiencia de Usuario es igual a la diferencia entre tener el conocimiento teórico sobre cómo iniciar un negocio y echarlo a andar en la realidad. Cuando un cliente está buscando un Diseñador de Experiencia de Usuario (uno de verdad, no un Desarrollador front-end) está buscando resolver o mejorar un problema con su producto o servicio y para eso se requiere más que conocimiento teórico, incluso más que referencias y estudios.

La única manera de implementar Diseño de Experiencia de Usuario es  haciéndolo: realizando estudios, entrevistas, análisis, pruebas de diseño, layouts, estructuras, calls-to-action, sumar stakeholders, convencer clientes, adquirir presupuestos, lidiar con fechas de lanzamiento, tiempos de desarrollo, frameworks, metodologías y la interminable variedad de perfiles profesionales a con las que un Diseñador de Experiencia de Usuario debe colaborar en el desarrollo de su trabajo.

Si la única manera de “graduarse” como Diseñador de Experiencia de Usuario es la experiencia, ¿cómo alguien puede obtener esa experiencia laboral? En muchas industrias, la única manera de ascender a puestos gerenciales o de dirección es pasando por todas las áreas que componen la empresa, porque ¿cómo puedes resolver problemas de los empleados si no conoces sus procesos? Sucede exactamente igual con el Diseño de Experiencia de Usuario: la única manera de dominar todas las herramientas que existen es practicando con ellas.

¿Estudiaste Diseño Gráfico? ¡Bien! Ya vas de gane. Ahora métete a aprender de programación para que sepas cómo y qué se puede implementar de las UI que ya sabes diseñar. Métete a aprender de investigación de usuarios para que aprendas a obtener insights que te ayuden a diseñar mejores interfaces; practica cómo vender tus proyectos a los clientes, usando el valor que tienen tus mejoras o soluciones para su negocio.

¿Estudiaste programación? Bueno, ahora empápate de patrones de diseño, de buenas prácticas, de heurística. Lean mucho: UX es parte de todo lo que haces y todo lo que eres. Además, un Diseñador rara vez hace todo por sí mismo: es necesario saber trabajar en equipo, entender las prioridades de los investigadores, diseñadores, desarrolladores, project managers, clientes, jefes y otros personajes involucrados en los proyectos.

Créanme: el mundo necesita más Diseñadores de Experiencia de Usuario que sepan lo que hacen. Aún quedan muchas cosas para mejorar, siempre habrá bancos, aerolíneas, tiendas en línea y marcas que no tienen la menor idea de lo que están haciendo y necesitan de un UX que los guíe para mejorar y para eso necesitamos gente de UX con mucha experiencia, profesionales y con ganas de hacer bien las cosas.

Trabaja como Planner en SCLBITS. Es curador de UX Mexico y parte del equipo de UX Nights.

El Dueño de la Experiencia de Usuario

Crear productos con buena experiencia de usuario requiere de un equipo con personas que tienen enfoques y habilidades muy diferentes. ¿Quién de ellos es el dueño de la UX?

El trabajo de desarrollo de tecnología dejó de ser desde hace mucho la tarea de una sola persona; los días del “webmaster” o del “hacker solitario” quedaron atrás como anécdotas de los tiempos en que la responsabilidad de programar, diseñar, crear contenido, asegurar la infraestructura, llevar a producción y dar a conocer un producto de tecnología era trabajo de una persona.

Los productos que sobresalen en el mercado casi siempre son creados por equipos de profesionales con habilidades y conocimientos diferentes, como en “The Avengers“, diría Adrián Solca:

El objetivo de tener un equipo es que el talento total compense las deficiencias individuales.

Un equipo multidisciplinario debe superar primero el impulso de sus miembros de trabajar únicamente orientados por requerimientos u objetivos personales. El primer reto es aceptar de que cada persona en el equipo, al tener diferente formación, tiene también formas diferentes de pensar, de comunicarse y de resolver problemas; usa herramientas diferentes que los demás y tiene objetivos personales diferentes también.

Trabajar enfocado en el beneficio del usuario sirve para centrar la atención de todos en el mismo tema y para unificar las visiones y objetivos de trabajo. Si el éxito del equipo depende del éxito del usuario final, entonces todos tiene un gran incentivo para crear la mejor experiencia de usuario posible.

La pregunta que surge en este punto es: ¿quién en el equipo es el responsable de la implementación correcta de UX?

La respuesta común es “todos son responsables“, pero esta respuesta tiene una trampa: cuando la responsabilidad es todos, en realidad nadie es 100% responsable. Los miembros de equipos con poca integración se pasan la responsabilidad entre ellos tratando de evitarla, lo que diluye el compromiso hacia el usuario y afecta el diseño final de la experiencia.

Es importante señalar en este punto que tampoco se trata de generar una “área de UX” que se responsabilice de la implementación de las buenas practicas del diseño centrado en el usuario. Una área que sólo tenga esa tarea como objetivo y trabaje de manera aislada de los equipos de producción solo volverá el proceso lento y burocrático, alienando a los demás.

En un buen equipo de UX no hay un “dueño”, pero si debe de haber un líder, un “campeón” que debe tomar dos roles adicionales a su contribución al equipo: primero, debe ser el representante del usuario, alguien que vele por los intereses de los usuarios finales y que le recuerde constantemente al equipo que el usuario es lo más importante; y segundo, debe de asumir el rol de facilitador para los otros miembros del equipo puedan conocer, entender los procesos, recomendaciones y mejores prácticas sobre UX.

Sobra decirlo, ser el “campeón” de UX en un equipo de trabajo no es sencillo. La persona que asuma ese rol deberá ser una persona que pueda trabajar con otros y comunicarse con ellos de manera puntual y eficiente, que pueda ganarse su confianza por medio mérito y no por un puesto o por pose.

En muchos sentidos, este “campeón” de UX refleja mucho el rol de un SCRUM Master en un proceso ágil pero con un giro: su principal preocupación no es el producto, sino el usuario final. Puede ser desarrollador, diseñador, project manager, el mismo CEO o alguien más. No necesita tampoco ser la misma persona todo el tiempo o en cada proyecto, o siquiera un “experto” en el tema. Es más: puede que sea una persona que trabaja fuera de la empresa, ¡o incluso un cliente!

Lo que es cierto es que cada equipo necesita a alguien que peleé por el usuario (¡como TRON!), pero no contra sus compañeros de trabajo. Si esta persona logra convencer a sus colegas que el usuario es lo más importante en el desarrollo de tecnología y los ayuda a trabajar en ese sentido, el resultado serán siempre productos increíbles y memorables.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.