Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Posts from the ‘desarrollo ágil’ category

La velocidad y la colaboración de Agile imponen nuevas condiciones a la práctica del Diseño. Por otra parte, en el desarrollo de productos es imprescindible que un buen diseño de experiencias pueda abrirse paso a través de la ingeniería ágil. ¿Cómo deberían integrarse las prácticas del Diseño y Agile?

Ya vimos en un post anterior que, aunque la ingeniería Ágil y el Diseño de experiencias de usuario implican enfoques originalmente diferentes, la adopción cada vez mayor de ambas filosofías para el desarrollo de nuevos productos está forzando a una convergencia y a una integración de las dos.

Dual track agile design

Una mala integración entre el Diseño y Agile produce problemas como estos:

  • Ineficaz planificación de las iteraciones porque falta una visión del producto y los elementos del backlog están mal definidos
  • Baja velocidad del proceso global porque muchos detalles se están elaborando durante la iteración
  • Despilfarro de recursos y reproceso elevados porque los elementos del backlog no han sido validados con los clientes y otros afectados
  • Productos con funcionalidades correctamente implementadas pero que no coinciden con las que necesita el mercado ni proporcionan una experiencia de usuario adecuada.

Integrando Diseño y Agile

Para evitar estos problemas han ido cristalizando algunas buenas prácticas que ayudan a integrar el desarrollo de experiencias de usuario en entornos de construcción ágil de productos. A continuación os resumo algunas, adaptadas de un muy referenciado post de Jeff Patton “Twelve emerging best practices for adding UX work to Agile development” (un poco antiguo pero de lectura obligada para todos los interesados en este tema):

  • Jefes de producto, diseñadores  e ingenieros deben trabajar integrados en equipos multidisciplinares de gestión y desarrollo de producto. Todos deben colaborar a través de las actividades de descubrimiento, validación y construcción de soluciones para el mercado.
  • Investigar, modelar y diseñar al principio… pero solo lo justo. La idea es realizar al inicio un diseño “suficiente” que proporcione un marco sobre el cual ir construyendo el diseño detallado a medida que el proyecto avanza. Resulta primordial identificar y comunicar las líneas generales de la funcionalidad y la experiencia de usuario para poder trabajar luego en sus partes manteniendo el contexto. Esta actividad debe estar totalmente integrada en nuestros esfuerzos para descubrir el producto: encontrar una solución a nuestro problema de mercado que sea útil, usable, deseable, factible y viable. A pesar de lo que algunos apóstoles agilistas proponían hace algunos años, las empresas que tienen éxito incorporando Diseño y Agile sí hacen un trabajo previo de investigación y modelado que genera personas, escenarios, modelos de flujo, etc. Sin embargo, han aprendido a comprimir la duración de su trabajo mediante las siguientes prácticas:
    • Priorizar el tipo de usuarios a investigar y reducir drásticamente el tiempo dedicado a usuarios de baja prioridad
    • Modelar rápidamente, aplicando métodos ligeros y colaborativos
    • Diferir los trabajos menos urgentes de investigación hasta la fase de implementación
    • Construir escenarios y artefactos (mockups, wireframes) de alto nivel que comuniquen la interacción y look-and-feel generales
    • Estas actividades se suelen realizar en una fase de planificación previa o una “Iteración 0”, junto con otros trabajos de prototipado de arquitectura, puesta en marcha de plataformas, etc.
  • Los diseñadores deben acostumbrarse a trabajar “por partes” y a una cadencia más rápida. En Agile la construcción se realiza por elementos  de funcionalidad (usualmente expresados como “historias de usuario”) que tienen valor y son comprobables desde la perspectiva del cliente. Hay que aprender a dividir el trabajo de especificación y diseño en partes coherentes que puedan ser diseñadas, construidas y validadas independientemente. Asimismo, la velocidad de iteración de Agile puede requerir que los diseñadores trabajen a un ritmo más rápido que el que les podría resultar cómodo. Algunos diseñadores y algunas metodologías de diseño son más compatibles con la filosofía ágil que otros.
  • Utilizar tracks paralelos de diseño e implementación. Los equipos en contacto con el cliente deben trabajar con uno o dos períodos de antelación para definir y diseñar lo que será construido en los futuros períodos. Esto permite validar las features más complejas con tiempo suficiente para mejorarlas. Es primordial evitar que el trabajo de diseño se realice durante el mismo sprint en que está teniendo lugar la implementación. Sin embargo, alguien del equipo de ingeniería debe revisar las ideas y prototipos en cada etapa para aportar feedback sobre factibilidad y costes y proponer mejores soluciones. Cuando el equipo de implementación está trabajando en la iteración T, el equipo de diseño está:
    • Investigando a los clientes sobre lo que se implementará en T+2
    • Validando con clientes prototipos de diseño que se implementarán en T+1
    • Colaborando con el equipo de ingeniería en las implementaciones actuales (T)
    • Validando con clientes lo construido en la iteración anterior (T-1)
  • Utilizar prototipos como especificaciones. En lugar del documento tradicional de especificaciones utilizar prototipos, habitualmente anotados “sobre la marcha” en una discusión con el equipo de implementación.

La adopción de una ingeniería ágil en la construcción de productos puede tener un impacto muy notable sobre cómo se practica el diseño en nuestra empresa:

  • Si la práctica de Diseño en nuestra empresa era débil antes de adoptar Agile, este cambio no le va a favorecer
  • Si la práctica de Diseño en nuestra empresa era fuerte antes de adoptar Agile seguirá siendo fuerte después, pero tendrá que evolucionar y adaptarse.

Aunque la convergencia de Agile y Diseño no está exenta de fricciones, crea muchas oportunidades y mejoras: haciendo que diseñadores e ingenieros trabajen juntos les permite enfocarse en objetivos más claros a corto plazo y eso puede beneficiar a la calidad de nuestros productos y al tiempo de salida  al mercado.

Este post en “Marketing & Innovación”.

[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]

Anuncios
6 comentarios

Agile y Diseño tienen orígenes y enfoques muy diferentes. Las prácticas ágiles minimizan el diseño previo y su velocidad de iteración deja poco tiempo para la investigación de clientes y la experimentación de nuevos modelos de interacción con el producto. Pero la necesaria confluencia entre ambos está imponiendo nuevas condiciones a los profesionales de uno y otro lado.

(IMPORTANTE: cuando en este post hablamos de Diseño nos referimos al diseño de experiencias de usuario o UX, no al diseño técnico.)

A primera vista, Agile y Diseño tienen muchos aspectos en común: aplicados al desarrollo de productos ambos ponen su foco en el usuario y aplican un proceso iterativo de refinamiento del producto guiado por el feedback del mercado, que se captura mediante artefactos “provisionales” (mockups, prototipos, versiones preliminares y limitadas del producto…). Los dos enfoques comparten el objetivo último de proporcionar productos dotados de significado para sus clientes.

Fight Agile UX

Agile y Diseño son fundamentalmente diferentes

Pero esas similitudes no nos deben impedir ver las diferencias –en algunos puntos antagónicas– entre ambos enfoques. Especialmente en el desarrollo de productos para un mercado (no de proyectos a medida para un cliente) estamos hablando de filosofías, ámbitos de aplicación y resultados muy diferentes:

  • El diseño de experiencias de usuario consiste en realizar investigación de clientes y en conceptualizar o representar el comportamiento del producto que se va a construir. Y el diseño de experiencias no es algo que se pueda hacer completamente por piezas: hay que considerar la experiencia de usuario holísticamente (si no en profundidad al menos sí en sus líneas generales y su filosofía). Por eso sus partidarios defienden que, análogamente a los planos de un edificio, el diseño de un producto debe realizarse antes de empezar a construirlo.
  • Agile es principalmente implementación (es decir, entrega de versiones funcionales del producto) y generalmente entra en acción cuando hemos decidido que vamos a construir la “unidad 0” de algo. Agile hace énfasis en la entrega rápida e iterativa de productos operativos, lo que en el caso de algunos enfoques anticuados o extremos se consigue a costa de prescindir de una planificación y diseño elaborados.

No olvidemos que Agile proviene del mundo del desarrollo de proyectos a medida (y no tanto en desarrollo de productos replicables), un escenario donde tradicionalmente no se ha concedido una gran importancia a la experiencia de usuario. Cuando el objetivo prioritario es proporcionar una serie de features, la experiencia de usuario suele ser un “subproducto” no muy logrado. Por el contrario, en productos para un mercado la experiencia del usuario es primordial y el Diseño nació para esos escenarios.

A principios de la pasada década, cuando Agile y Diseño empezaron a pasar al primer plano, las diferencias entre ambos eran más patentes. En un debate clásico que tuvo lugar en 2002, Alan Cooper (pionero del diseño de interacción) y Kent Beck (creador de XP) no sólo fueron incapaces de ponerse de acuerdo, sino que ninguno de los dos parecía entender al otro. Reconozcamos que era la “prehistoria” y que desde entonces ambos metodologías han evolucionado, pero la conversación nos da idea de sus diferencias en origen.

Para reducir el riesgo y mejorar la calidad del producto, en Agile una release se divide en varias iteraciones, en cada una de las cuales se implementa un conjunto de “historias de usuario” (u otro artefacto para especificar funcionalidad). Este foco en las features nos puede hacer olvidar que la experiencia del usuario no se puede diseñar por partes: debe tener sentido para ese usuario en cada release. Si en Agile renunciamos a modelar con antelación lo que se va a implementar podemos acabar con un producto fiable y bien construido pero que carezca de un significado, una integridad y una interacción coherente. Y es que algunas cosas a las que se deja que “emerjan” terminan resultando criaturas muy feas.

Condenados a entenderse

Tal vez el principal beneficio del diseño de UX es la capacidad para imaginar y representar cómo un conjunto desordenado de funciones y significados se puede sintetizar armoniosamente. Por desgracia, algunas prácticas ágiles extremas relegan su papel al de esfuerzos a corto plazo para diseñar y rediseñar elementos pequeños y aislados. Y aunque en este campo Agile puede mejorar la usabilidad del producto, los resultados tienen a menudo un carácter incremental.

La velocidad de ciclo y la cadencia que impone Agile ha sido uno de los aspectos más difíciles de reconciliar con el Diseño. ¿Con unos ciclos tan cortos tenemos realmente tiempo para entender completamente las necesidades de nuestros usuarios? La respuesta corta es “no”. Pero la respuesta correcta es que si estamos descubriendo las necesidades de los usuarios durante la implementación estamos haciendo algo rematadamente mal. La urgencia por alimentar los ciclos de Agile y por dedicarnos a los “árboles” de la actual iteración nos puede impedir ver el “bosque” de la experiencia holística de usuario y descubrir nuevos y rompedores modelos de interacción que diferencien a nuestro producto de sus rivales.

Además, la falta de un diseño inicial validado con los usuarios puede llevar en fase de construcción a un rediseño o un refactoring excesivo que incremente los costes y retrase la salida al mercado; algo que, paradójicamente, impide alcanzar los objetivos de Agile. Hay que buscar un equilibrio: combinando un esfuerzo inicial con pasos pequeños y constantes que avanzan hacia un producto coherente, el Diseño tiene que abrirse paso. De lo contrario Agile se acaba convirtiendo en una serie de experimentos de diseño de muy alta fidelidad y coste.

Como no podía ser de otra forma, en los últimos años hemos asistido a un acercamiento entre UX y Agile, con prácticas de uno que pasan al otro (y, curiosamente, con primeras figuras de cada una de las corrientes participando en los eventos de la otra). Las prácticas del nuevo Agile Product Management recogen el uso de mockups y prototipos para generar lo que se conoce como “visión” del producto, y que recoge los resultados del análisis de la oportunidad de mercado y de la definición y especificación general del producto. Esta visión se traduce en “épicas” y “temas”, que son los artefactos con los que Agile especifica la funcionalidad a alto nivel. Aún así, queda mucho camino por recorrer en cuanto a la integración del Diseño en Agile.

La adopción de Agile está obligando a cambiar la forma de trabajar de los diseñadores, pero la combinación de Agile y UX abre nuevas oportunidades tanto para los profesionales como de proporcionar mejores productos a los clientes. Y al diseño ágil de experiencias de usuario (lo que se conoce como Agile UX) dedicaremos un próximo post.

Este post en “Marketing & Innovación”.

[El diseño de producto es mucho más que un barniz estético a posteriori y especialmente en áreas como la experiencia de usuario constituye un gran eje de diferenciación. Descubre en este documento el papel del diseño en el desarrollo de productos.]

5 comentarios

Las metodologías de “desarrollo ágil” hacen muchas cosas mejor, pero también pueden llegar a hacer otras cosas (algunas muy importantes) peor. En este post pasamos revista a las bajas colaterales que puede provocar en entornos de desarrollo de productos una agilización mal entendida.

En la primera parte de este post hablábamos de que las que se suelen vender como metodologías de “desarrollo ágil” tienen grandes ventajas pero no se pueden considerar una solución completa para el desarrollo de nuevos productos para un mercado (algo muy diferente al desarrollo a medida para un cliente específico).

En esta segunda parte abundamos en la opinión -que puede resultar herética para algunos- de que Agile no es la nueva panacea universal y que, si bien hace muchas cosas mejor (fiabilidad, velocidad, calidad…), implementado “según el manual” puede llegar a hacer otras cosas (algunas muy importantes) peor. Aquí tenéis algunas de las bajas colaterales provocadas por una agilización mal entendida:

Beatings Will Continue

  • Análisis de la oportunidad de mercado y conocimiento profundo de los clientes. El feedback de los clientes durante la implementación es muy valioso, pero no puede sustituir a un conocimiento del mercado y a unos customer insights previos -y continuos- que nos van a permitir detectar y definir oportunidades rompedoras. Por ejemplo, el Product Owner típico de Scrum debe estar continuamente disponible para el equipo de implementación y por ello puede no disponer del suficiente tiempo de contacto con los clientes o de análisis de los competidores como para entender el mercado. Frecuentemente el resultado es un producto que satisface literalmente las solicitudes de mejora expresadas por uno o dos clientes particulares (los últimos que hablaron con el Product Owner), pero lamentablemente el cliente voluntarioso/colaborador no representa al cliente típico.
  • Estrategia de producto, visión a largo plazo y roadmap. Un excesivo énfasis en ciclos de desarrollo cortos y en la priorización continua de las features puede hacernos perder de vista dónde querríamos estar a medio y largo plazo -en términos de mercados y oferta- y qué camino debemos seguir para llegar allí. Por no hablar de cierta afición a priorizar features por ROI (desde mi punto de vista, algo en general ilusorio y contraproducente). Agile no debe ser una excusa para carecer de estrategia de producto y para cambiar constantemente de visión y vagar sin rumbo fijo.
  • Feedback temprano y frecuente. Agile promueve el feedback de los clientes durante todas las iteraciones de la implementación. Sin embargo, confiar la validación inicial de la solución a esas primeras iteraciones es un error ya que para entonces puede ser demasiado tarde. Este feedback se debería haber recogido durante las fases previas a la implementación -definición y diseño-  y no mediante un producto real (aunque incompleto) sino utilizando prototipos rápidos y desechables. Los prototipos pre-implementación son los únicos que nos permiten recoger la opinión de los clientes con la rapidez, velocidad de iteración, fidelidad y bajo coste necesarios para asegurarnos de que no empezamos a construir algo que el mercado no quiere.
  • Diseño de la solución (especialmente en lo relacionado con la experiencia de usuario). Una experiencia integrada y consistente no “emerge a trozos” de una construcción incremental sino que debe ser fruto de una concepción holística y -al menos en sus grandes líneas- de un diseño deliberado previo. Este diseño integral (siempre iterativo) es el que realmente permite descubrir modelos innovadores de interacción con el usuario, que elevan el nivel de la experiencia de uso. Por su parte, el refinamiento iterativo durante la implementación puede optimizar interfaces e interacciones, pero se trata a menudo de una mejora incremental. Las metodologías ágiles se están extendiendo para conjugar un diseño holístico con una implementación incremental, hasta el punto de que el “Agile UX” es uno de los temas de actividad en la comunidad (al que dedicaremos un próximo post).
  • Arquitectura. Un excesivo foco en las features puede llevar a postergar a un segundo plano la especificación técnica. Y, sin embargo, la arquitectura es primordial para garantizar que durante la construcción vamos a poder iterarlo y “pivotarlo” fácilmente y que el producto final va a ser replicable, fiable, escalable, evolucionable y adaptable a varios segmentos de clientes (a través de “productos derivados”). La arquitectura es otro de los aspectos del producto que requieren un enfoque holístico y en implementaciones desafortunadas de Agile puede acarrear una gran “deuda técnica”.
  • Puestos con funciones claras y no redundantes. Las metodologías Agile van evolucionando y extendiéndose más allá de la implementación, entrando en los terrenos de la estrategia, la visión y la definición del producto. Sin embargo, en las empresas ya existen puestos que tienen la responsabilidad sobre esos temas (llámense estos Chief Product Officer, Product Manager, Business Analyst o Technical Product Manager) lo que puede crear conflicto con alguno de los puestos o roles propios de Agile, especialmente el del Product Owner. Incluso ha habido intentos de describir un “Agile Product Manager” como una especie de Súper-Product Owner aunque en mi opinión las responsabilidades y actividades que le asignan son incompletas y las técnicas que les recomiendan son demasiado rudimentarias. También hablaremos de ello en otro post.

Con todo esto no quiero decir que cualquier implementación del desarrollo ágil vaya necesariamente a acarrear estos problemas, sino identificar áreas de posible disfuncionalidad donde hay que poner un especial cuidado.

La decisión de aplicar o no Agile no puede tomarse por modas, sino que depende del tipo de producto, mercado, tecnología y organización. Si los riesgos de cliente/mercado/tecnológicos son bajos, los costes de iteración son altos, y  el equipo de implantación muestra buen rendimiento, coordinación y comunicación puede no ser necesario migrar a Agile ya que los costes incrementales del cambio pueden ser superiores a los beneficios. La realidad en las empresas más avanzadas es que controlan un repertorio de metodologías de implantación, desde el ágil más radical a la cascada más ortodoxa, pasando por enfoques mixtos “Agile Waterfall”, y aplican una u otra según lo que más convenga en cada escenario.

Este post en ”Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

3 comentarios

Las metodologías ágiles se vienen presentando como la solución a los problemas del desarrollo de productos. Pero aunque sin duda pueden aportar mejoras en las actividades de construcción y conseguir que las características del producto se implementen adecuadamente, por sí solas no son suficiente para asegurar que esas características son las adecuadas para conquistar el mercado.

La filosofía y las metodologías ágiles se están proponiendo como solución a los retos del desarrollo de productos en escenarios de alta incertidumbre y velocidad. Por ejemplo, Steve Blank y Eric Ries incorporan el Agile Development como una de los pilares de su Startup Stack, junto a Customer Development y Business Model Canvas. En este blog hemos hablado de desarrollo ágil en varias ocasiones y tal vez vale la pena recordar algunas ideas:

Proceso Scrum

Pero las diferencias entre ambos escenarios son enormes: desarrollar un producto que satisfaga a un mercado va mucho más allá del desarrollo de un proyecto a la medida de un cliente específico. La gestión y desarrollo de productos consiste fundamentalmente en entregar productos repetibles a un mercado de clientes y ello requiere inicialmente de una identificación de las necesidades de dicho mercado, una validación de la oportunidad que representa y una comprensión profunda de los requisitos esenciales de los clientes. Las metodologías de “desarrollo ágil” cubren las actividades de implementación o construcción de la “unidad 0” de un nuevo producto y por tanto entran en acción cuando ya se ha decidió que se va a construir algo, pero no fueron pensadas para evaluar una oportunidad de mercado o para definir el tipo de solución a proporcionar. No podemos confundir una parte (la construcción del producto) con todo el proceso de desarrollo y mucho menos con la gestión estratégica de productos.

Personalmente soy un convencido de los beneficios de las filosofías flexibles/ágiles de desarrollo de nuevos productos, especialmente en escenarios de alta incertidumbre. Y sin duda la flexibilidad y la iteración centrada en el usuario que aportan las metodologías Agile benefician enormemente al proceso de desarrollo. Pero una aplicación “de manual” de algunas metodologías a escenarios para los que no fueron creadas puede traer efectos secundarios indeseables.

Por su enfoque principalmente táctico y orientado al proyecto, Agile puede aportar grandes mejoras en el propio proyecto (o proyectos) de construcción de un nuevo producto: programación predecible de releases, menos features incompletas, mayor usabilidad… pero puede relegar la visión más estratégica del producto a un segundo plano. Agile puede acelerar el desarrollo y mejorar la calidad de las features individuales, pero lo hace a menudo a expensas de otros trabajos más importantes y costosos que aportan un valor para el cliente y una diferenciación competitiva reales, p.ej., una comprensión profunda y una priorización de los problemas a resolver o un diseño holístico (al menos en sus líneas generales) de la funcionalidad y la experiencia de usuario.

Desde luego que una  implementación ágil puede mejorar muchos aspectos del producto, pero esas mejoras son a menudo incrementales. Esencialmente, Agile asegura que se va a poder “entregar algo aceptable rápidamente”, pero ¿ese “algo” nos va a servir para vender más en un mercado? Mi opinión es que las metodologías ágiles por sí solas son insuficientes para asegurar que se construyen las features adecuadas para satisfacer a unos clientes heterogéneos y desconocidos.

Cuando Agile se implanta “a ciegas” su cadencia y sus prácticas llegan a apropiarse del proceso de desarrollo de producto y la vorágine de la implementación absorbe a toda la organización. Resulta difícil pensar estratégicamente cuando se está sometido a las demandas constantes del corto plazo. La urgencia por “alimentar a la bestia” de los procesos de Agile nos puede impedir prestar atención a algunas otras cosas realmente importantes. Para evitarlo, estas metodologías han tenido que ir adaptándose y extendiéndose de modo que fueran más adecuadas a un escenario de desarrollo de productos y no de proyectos a medida.

En la segunda parte de este post pasaremos revista a algunas “bajas colaterales” de un agilismo mal entendido. Mientras tanto ¿cuál ha sido vuestra experiencia en el desarrollo de productos aplicando metodologías ágiles?

Este post en ”Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

12 comentarios

¿Es Agile válido para algo más que el desarrollo de software a medida? ¿Sirve para desarrollar productos no software?

En la segunda parte de este post hablamos de cómo las metodologías Iterativas y ligeras se vienen aplicando con éxito en la construcción de productos softwareincluso desde mucho antes de la actual “fiebre Ágil”. ¿Quiere esto decir entonces que cualquier empresa de producto software se beneficiaría de Agile? ¿Nos deberíamos administrar todos la típica “receta Scrum+XP” (o la que esté de moda)?

Pues no necesariamente. Como ya sabemos, la flexibilidad de Agile no es gratis. Algunos factores a tener en cuenta:

  • Si los clientes, requisitos y tecnologías son conocidos y estables, las metodologías lineales siguen siendo una opción.
  • Si el equipo humano ya dispone de unos buenos mecanismos de gestión, coordinación y comunicación, el introducir algunas prácticas “extremas” de Agile puede resultar disruptivo y contraproducente.
  • Con su énfasis en codificar y en desarrollar features, algunas metodologías de Agile minimizan (o eliminan) aspectos cruciales como el análisis significativo del mercado, la visión del producto o el diseño de una experiencia integral de usuario, lo que puede llevar a innovaciones incrementales y a productos poco atractivos.

De todos modos, el papel de de Agile en el desarrollo de productos software sigue siendo objeto de debate: en un próximo post discutiremos algunas de sus limitaciones. Y esto nos lleva a la última cuestión que vamos a considerar en esta serie de posts.

¿Se puede aplicar Agile a productos no software?

La respuesta es “sí y no”. Trasplantar a otros sectores los aspectos más ligados al software (p.ej., el pair programming de XP) probablemente no tiene sentido ni es posible. Pero es evidente que muchas industrias se beneficiarían de la filosofía y los principios de Agile en cuanto que pueden aportar  flexibilidad ante un entorno cambiante, mayor velocidad y calidad en el desarrollo y equipos humanos coordinados e involucrados.

En realidad, algunos elementos de la filosofía Agile están tomados de los enfoques de fabricación y calidad de productos de Edward Demming y del Lean Manufacturing System de Toyota. Particularmente Scrum, la metodología de gestión de proyectos más ligada a Agile, se inspiró en algunas ideas sobre el desarrollo de productos (por cierto, no software) de los años ochenta.  En efecto, en su famoso artículo de 1986 “The New New Product Development Game”, H. Takeuchi e I. Nonaka argumentan que el enfoque secuencial tradicional del desarrollo de productos, que denominan “carrera de relevos”, colisiona con los actuales imperativos de velocidad y flexibilidad.

En su lugar proponen un enfoque holístico, que asimilan al deporte del rugby, donde los miembros del equipo interactúan constantemente y recorren juntos el proceso de principio a fin “desplazando la melé” (por cierto, melé en inglés se dice scrum ;- ). Los autores analizar los proceso de desarrollo de diversos productos de éxito en los sectores de las fotocopiadoras, los automóviles, los ordenadores y las cámaras fotográficas y descubren que esos procesos se caracterizan por el solapamiento entre las fases del desarrollo, la autoorganización, comunicación y multidisciplinariedad del equipo y un enfoque iterativo y dinámico de prueba y error. Algunos pioneros de Scrum, como J. Sutherland y K. Schwaber, han reconocido en numerosas ocasiones la influencia de estas ideas en su pensamiento.

Resumiendo, y teniendo en cuenta que muchos de los enfoques y prácticas de Agile provienen del mundo de los productos no software, la pregunta de si Agile puede aplicarse en ese campo no deja de ser algo retórica. Un punto crucial radica en el papel de la iteración en el proceso: en la primera parte de este post argumentamos que en el caso de desarrollos a medida en sectores intensivos en materiales (como por ejemplo la construcción de edificios, naves, etc.), los elevados costes de los cambios durante el desarrollo pueden limitar las posibilidades de iterar, ya que al tratarse de un proyecto singular se le deberían repercutir todos los costes de las iteraciones y el presupuesto podría incrementarse exageradamente.

Sin embargo, cuando se trata de desarrollar un producto (es decir, construir su “unidad 0”, que luego habrá que replicar en el proceso de fabricación) los costes de las iteraciones durante el desarrollo son menos relevantes ya que pueden ser repercutidos sobre un número mayor de unidades. El prototipado, la búsqueda del feedback de los clientes y la iteración se ha convertido en una constante en el desarrollo de productos materiales debido a la influencia del “pensamiento de diseño” y a la disponibilidad de tecnologías como la simulación, la realidad virtual o la impresión 3D que permiten generar, explorar y validar múltiples alternativas incluso en las fases de conceptualización y diseño, sin necesidad de esperar a la construcción propiamente dicha.

En un próximo post hablaremos de las limitaciones y problemas de Agile en el desarrollo de productos.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

7 comentarios

¿Es Agile válido para algo más que el desarrollo de software a medida? ¿Sirve para desarrollar productos?

En la primera parte de este post nos planteábamos si Agile sirve para proyectos singulares/desarrollos a medida más allá del software. Ahora nos preguntamos si se puede aplicar en el desarrollo de productos, tanto software como no.

Y antes que nada conviene aclarar una cuestión terminológica. Cuando la gente de Desarrollo/Tecnología Software habla de un “desarrollo a medida” o un “desarrollo de producto” se suele referir a lo que constituye el núcleo de su labor: a lo que -dependiendo de la metodología- cubre desde la captura de requisitos hasta la prueba final (pasando, obviamente, por el diseño técnico y la programación) del proyecto. En definitiva, estamos hablando de la “construcción” del sistema a medida o de la “unidad 0” de un producto.

Por el contrario, cuando la gente de Negocio habla del Desarrollo de un Nuevo Producto (NPD, New Product Development) se está refiriendo a un proceso más amplio, que incluye a la propia “construcción”, pero que también abarca desde la generación de ideas y detección de oportunidades hasta la prueba de mercado y el lanzamiento. Dependiendo de las características en cuanto a incertidumbre, velocidad y grado de innovación del producto/mercado serán aconsejables para el NPD unos enfoques y metodologías u otros, por ejemplo:

  • En casos de necesidades conocidas, mercados estables e innovaciones incrementales puede ser más eficiente utilizar un proceso lineal y faseado como por ejemplo el Stage-Gate clásico (siguiente figura)

  • Con necesidades emergentes, requisitos de cliente inestables, mercados nuevos o en evolución e innovaciones radicales resulta más eficaz aplicar un proceso iterativo (en el que las fases están interrelacionadas y se solapan) que facilite la involucración temprana y constante de los clientes. Estos procesos -cuyo objetivo primordial es descubrir espacios de mercado y validar nuevos modelos de negocio– están menos asentados y formalizados que los lineales.  Y probablemente el que más atención está recibiendo últimamente es la combinación de Customer Development y -precisamente- Agile Development propuesta por Steve Blank y Eric Ries.

Por lo tanto, desde ese punto de vista la pregunta correcta no es si Agile constituye una solución o respuesta completa al Desarrollo de Nuevos Productos, sino si Agile es una herramienta útil para dicho proceso. En realidad, si bien las metodologías de Agile originalmente no cubren todas las actividades de estos procesos en los últimos tiempos se han ido extendiendo, llegando a abarcar algunas de las funciones de la Gestión de Productos más estratégica. Incluso se ha llegado a asimilar el papel del Product Owner de Scrum con el del Product Manager: hablaremos de ello en otro post.

¿Se puede aplicar Agile a productos software?

Este es un asunto bastante actual y polémico porque en los últimos años se ha vendido la filosofía Ágil (especialmente Scrum y XP) como la panacea para el desarrollo de productos software, eliminando la rigidez y la burocracia del modelo en Cascada. Pero vamos a revelar un pequeño secreto: las empresas de productos software de éxito llevaban aplicando metodologías de desarrollo incrementales/iterativas/en espiral/de prototipado rápido etc. desde antes de que se acuñara el término Agile y de que su uso se popularizara en los proyectos de software a medida.

Las metodologías más pesadas y rígidas fueron relegadas muy pronto del desarrollo de productos software para mercados innovadores y competitivos. ¿Por qué? Pues porque ese sector es el paradigma de clientes desconocidos, requisitos complejos y cambiantes, volatilidad competitiva y tecnológica… y todo ello con la imperiosa obligación de ganar dinero.  Y en esa situación las metodologías ligeras pueden ayudar. Personalmente doy fe de que a principios de los años 2000 eso era así incluso en el sector de las aplicaciones corporativas (ERP, CRM, SCM…) ya que en aquella época trabajé en un par de multinacionales estadounidenses en ese campo. Y si quieres competir contra SAP -a eso es a lo que nos dedicábamos- más te vale introducir una absoluta flexibilidad en todo lo relacionado con el desarrollo de producto (empezando por su propia arquitectura).

Es evidente que desde principios de los pasados años noventa las empresas de producto software vienen aplicando filosofías de desarrollo iterativo y flexible. Por ejemplo, en su libro de 1995 “Microsoft Secrets”, M. Cusumano y R. Selby describen el proceso “Sync-and-Stabilize” usado en Microsoft. Posteriormente, un estudio realizado en 2000-2001 por M. Iansiti, R. Verganti y A. MacCormack sobre el volátil sector del software para Internet consiguió identificar las características que poseían los procesos de desarrollo aplicados en los productos con más éxito en el mercado. En “Product-Development Practices That Work: How Internet Companies Build Software” A. MacCormack analiza dichas prácticas de éxito, que se basan en un enfoque evolutivo del desarrollo:

  • Poner lo antes posible en manos de los clientes una versión preliminar del diseño, e ir evolucionando
  • Incorporar diariamente nuevo código software y conseguir un feedback  rápido sobre los cambios en el diseño
  • El equipo humano debe poseer una amplia experiencia en la realización de proyectos diversos
  • Invertir en el diseño de la arquitectura del producto

En definitiva, las metodologías Iterativas y ligeras se vienen aplicando con éxito en la construcción de productos software desde antes de la “fiebre Ágil”. ¿Quiere esto decir entonces que cualquier empresa de producto software se beneficiaría de Agile? ¿Nos deberíamos administrar todos la típica “receta Scrum+XP”? Trataremos de responder en la tercera parte de este post.

Este post en Marketing & Innovación.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

6 comentarios

El Desarrollo Ágil se ha venido postulando como la solución a todos los problemas del desarrollo de productos. Pero ¿es Agile válido para algo más que el desarrollo de software a medida?

En el transcurso de los últimos diez años, Agile se ha convertido en un enfoque practicado por muchos departamentos de TI y Desarrollo: en la encuesta Global Developer Technographics publicada por Forrester y Dr. Dobbs, casi el 39% de los profesionales de TI consultados afirmaba seguir un método Agile (con Scrum, Agile modeling y Test-driven development a la cabeza). Y con esta explosión del Desarrollo Ágil uno de los temas de debate es si sus principios y metodologías son válidos en entornos diferentes al del software a medida, que es donde nació. ¿Funciona en desarrollos a medida no software? ¿En desarrollo de productos software? ¿Y en productos no software?

Dejemos a un lado la obviedad de que el Agile Manifesto se refiere exclusivamente al software y analicemos si su filosofía y principios y las diversas metodologías asociadas con Agile (Scrum, XP…) se pueden aplicar en otros entornos.  Y vamos a empezar sintetizando las diferencias entre estos diversos escenarios:

Por resumir, las diferencias entre un desarrollo a medida y uno de producto es que el primero es un desarrollo más o menos singular, definido para resolver el problema de un cliente dado. Por el contrario el desarrollo de producto va dirigido a resolver las necesidadesa veces latentes– de un mercado de clientes en general desconocidos (individual y, muchas veces, colectivamente). Además, lo que se conoce como Desarrollo de Nuevos Productos (NPD, New Product Development) abarca varias fases previas a (o concurrentes con) su “construcción”, que incluyen el descubrimiento de la oportunidad, la comprensión del mercado, la identificación de necesidades, la validación del modelo de negocio o la elaboración del caso de negocio. Finalmente, la vida de un producto abarca esas fases previas y otras posteriores como su lanzamiento, comercialización, evolución o retirada del mercado (generalmente a través de una sustitución ordenada mediante nuevos productos de la empresa)… lo que tradicionalmente constituye el área de Product Management y Product Marketing.

En cuanto a las diferencias software – no software, la más evidente es la posibilidad de replicar (“fabricar” y “entregar”) unidades adicionales de un producto software a coste prácticamente cero. Pero desde el punto de vista de desarrollo de un proyecto singular o de la primera unidad de un producto, una diferencia vital es que los costes de realizar cambios a mitad del proceso son mucho más bajos en el software que en otro tipo de industrias más intensivas en materiales y equipamiento. Esto hace viables los enfoques iterativos de desarrollo.

Finalmente, entre un desarrollo a medida de software y un producto software aplican las diferencias generales entre desarrollos a medida y producto, pero además en un desarrollo a meda lo importante es la cobertura funcional mientras que en un producto (especialmente en B2C) adicionalmente resultan clave aspectos como la experiencia de usuario y otras medidas de calidad.

¿Se puede aplicar Agile a desarrollos a medida más allá del software?

Por desarrollo a medida entendemos un proyecto nuevo y diferente que se ejecuta para cubrir una necesidad identificada de un cliente dado -no la replicación de un desarrollo previo- por ejemplo, la construcción/ elaboración de un edificio, un barco, un informe de consultoría… o un coche de Formula 1.

Por supuesto que algunos principios de Agile y aspectos de sus diferentes metodologías pueden beneficiar a proyectos de muy diversa naturaleza. De hecho, marcos de gestión de proyectos como Scrum no nacieron ligados inicialmente al software. Por otra parte es obvio que metodologías específicamente de programación como XP (con su pair programming y otras prácticas) no van a encontrar un acomodo fácil en otros ámbitos.

Los principios básicos de Agile (iteración, desarrollo incremental, feedback continuo de cliente…) proporcionan los mejores resultados en escenarios donde existe gran incertidumbre e incógnitas que deben ir despejándose durante el proyecto, en los que es imposible recabar todos los requisitos del cliente al principio o estos no son estables y donde el coste de realizar cambios durante el desarrollo no es prohibitivo. Pero ya sabemos que la flexibilidad que aporta Agile no es gratis: si no se dan las anteriores circunstancias es menor aplicar una gestión “predictiva” (no evolutiva) basada en definir-planear-ejecutar.

Por ejemplo, con el estado actual de la tecnología no podemos de manera eficiente “iterar” durante la construcción de un edificio, so pena de que un presupuesto de 27 millones se convierta en 110 (aunque si el cliente es la administración pública y quien paga es el contribuyente todo es mucho más “flexible”, como bien sabemos en nuestro país). Por contra, sí que es más sencillo iterar y aprovechar la flexibilidad de Agile en proyectos más inmateriales, como los relacionados con contenidos digitales. No obstante las tecnologías de simulación, prototipado rápido, realidad virtual, etc. pueden facilitar el feedback y la iteración desde la fase de diseño en muchos tipos de desarrollos a medida, sin necesidad de esperar a la construcción.

En la segunda y tercera partes de este post analizaremos si Agile es útil para el desarrollo de productos, tanto software como no software.

Este post en “Marketing & Innovación”.

[Desarrollar nuevas ofertas y modelos de negocio en mercados tecnológicos plantea retos muy particulares. Descubre en este documento cómo desarrollar productos que los clientes necesitan.]

14 comentarios

En la primera parte de este post anterior hablamos de cómo las características particulares de la tecnología software y el tipo de problemas que resuelve fueron abonando el terreno para la aparición de metodologías de desarrollo ligeras e iterativas, en un intento de mejorar las metodologías pesadas y por fases -influidas por las técnicas del desarrollo de proyectos en otros campos- que habían predominado hasta entonces.

En febrero de 2001 diecisiete expertos en desarrollo de software publicaron el “Manifesto for Agile Software Development”, que dio un nombre, una carta de naturaleza y una “marca” a todos esos métodos. Básicamente el Manifiesto consta de cuatro puntos en los que se da prioridad a los individuos y las interacciones, al software que funciona, a la colaboración con el cliente y a la respuesta ante el cambio frente a aspectos como los procesos, la documentación y los planes, que son prioritarios en otros enfoques. Como complemento incluye los doce principios básicos de Agile, entre los que se cuentan la satisfacción del cliente, la entrega temprana y continua de software que funciona, la cooperación y la autoorganización.

Es importante señalar que cuando se habla de Agile se suele hablar en realidad de alguna de las metodologías precursoras que mencionábamos en nuestro post anterior, y en particular de dos que son las más aceptadas (y que son anteriores al Manifiesto):

  • Scrum (1995), un marco iterativo e incremental para la gestión de proyectos, inicialmente propuesto para proyectos de desarrollo de productos y cuyo uso se ha centrado en proyectos de desarrollo de software.
  • XP (Extreme Programming, 1996) una metodología iterativa de desarrollo de software que aboga por entregas frecuentes de software en ciclos de desarrollo cortos y que recibe ese nombre por su énfasis en llevar al extremo esas buenas prácticas.

En realidad muchos de los principios de Agile (como por ejemplo incrementar la flexibilidad o la comunicación) son ideas de sentido común pensadas para enmendar el mal funcionamiento de las metodologías tradicionales en ciertos escenarios y para arreglar equipos de proyecto disfuncionales. Pero adicionalmente las metodologías Agile incorporan una serie de prácticas, roles y “valores” (daily scrums, war rooms, programación en parejas, retrospectivas, Scrum Masters, Product Owners…) y un énfasis en el funcionamiento del equipo de desarrollo que crean una “liturgia” y contribuyen a fomentar la identificación y la involucración, a veces casi religiosa, de sus practicantes. Lamentablemente, algunas organizaciones encuentran difícil implantar Agile en toda su extensión -con el cambio de cultura que requiere- y se quedan en sus prácticas superficiales, lo que no deja de ser un caso más de “cerdo con lápiz de labios”.

Los beneficios en cuanto a flexibilidad, adaptación, comunicación y coordinación que Agile aporta en escenarios inciertos y volátiles son evidentes. Sin embargo, en estos años se han alzado voces críticas con esta filosofía debido a posibles limitaciones como las siguientes:

  • Está muy enfocada en la captura de requisitos y el desarrollo, pero pone un foco escaso en el diseño y en la experiencia global del usuario de la solución
  • Falta de estructura y documentación
  • Puede aumentar el riesgo de una expansión incontrolada del alcance del proyecto
  • Solo funciona bien con desarrolladores experimentados
  • Requiere reuniones muy frecuentes con los clientes, con el consiguiente coste
  • Dificultad para escalar a proyectos grandes y con personal distribuido geográficamente

Por eso algunos dicen que, si bien Agile tiene cosas buenas y originales, “las cosas buenas no son tan originales y las cosas originales no son tan buenas”… Ese es también el motivo por el que las prácticas de Agile llevan años evolucionando para solucionar sus carencias y ser aplicables en escenarios más generales. En cualquier caso, es evidente que la flexibilidad que aporta Agile no es gratis y a veces sus costes pueden superar a sus beneficios.

Hasta aquí esta introducción a Agile. En próximos posts iremos abriendo el debate sobre preguntas como las siguientes:

Este post en Marketing & Innovación.

7 comentarios

Desde hace unos años todo es Agile: la creación de software, el desarrollo de productos, las organizaciones… En este post explicamos los orígenes de esta filosofía, los beneficios que aporta y algunas de sus limitaciones.

Desde hace más de diez años las filosofías Agile están revolucionando el desarrollo de software. Por poner como ejemplo a alguien habitual en este blog, Steve Blank y Eric Ries han incorporado el Desarrollo Ágil como una de las bases de su Startup Stack (junto a Customer Development y Business Model Generation). Tal ha llegado a ser el predicamento de esta filosofía que en los últimos tiempos hay quien intenta convencernos de que Agile no solo es la panacea para el desarrollo de productos de cualquier tipo y en cualquier mercado, sino que todo aquel que no se haya convertido a Agile no es más que un “dinosaurio de las cascadas” o -lo que casi es peor- un “cowboy metido a programador”.

Por aportar un poco de contexto y abrir el debate sobre el papel de Agile en el desarrollo de productos vamos a repasar los orígenes y principios básicos de este movimiento (desde la perspectiva de alguien que -aunque hace mucho tiempo que dejó de programar- sí que dedicó los primeros años de su carrera a la Ingeniería del Software).

Lo primero que hay que decir es que lo que ahora se conoce como Agile surgió a partir de los años ochenta del pasado siglo (e incluso antes) en forma de metodologías “ligeras” de desarrollo software, como respuesta a las limitaciones de las metodologías “pesadas” tipo Waterfall (Cascada). Dichas metodologías pesadas se habían definido inicialmente para el desarrollo de software a medida como una adaptación de los métodos al uso en los sectores de la fabricación y la construcción. Estos son entornos intensivos en el uso de materiales y maquinaria específica y donde los costes de hacer cambios cuando el proyecto está avanzado son prohibitivos, lo que exige una exhaustiva definición inicial de requisitos y un diseño cerrado. Las metodologías de desarrollo software tipo cascada asumen que hay un cliente que sabe cuál es su problema (por eso contrata el desarrollo) y se basan en unas fases secuenciales sin solapamientos y un diseño inicial estable e invariable (BDUF, Big Design Up Front).

Sin embargo el desarrollo de programas, por su propia naturaleza, no se ajusta muy bien a dichas condiciones: la complejidad de los problemas que se suelen resolver mediante software, la indefinición de los requisitos del cliente, la importancia de la interacción entre el producto final y sus usuarios, el continuo cambio tecnológico, etc. hacían imposible que aspectos como la solución dada al problema del cliente, los requisitos, el diseño e incluso la arquitectura del programa pudieran mantenerse constantes durante el desarrollo. Y el modelo en cascada no está preparado para encajar bien esos cambios.

Por otra parte la tecnología del software posee algunas características particulares que abrieron la posibilidad de otro tipo de metodologías; entre estas peculiaridades podemos citar la facilidad para “componentizar”/modularizar el desarrollo, crear prototipos o automatizar las pruebas y los (comparativamente) bajos costes de realizar cambios que aporta su naturaleza “inmaterial”. A partir de los pasados años ochenta empiezan a aparecer una serie de nuevos modelos para el desarrollo de software a medida, tales como el Desarrollo Rápido de Aplicaciones, el Espiral o el Proceso Unificado y -más tarde- metodologías como XP (Extreme Programming) o FDD (Feature Driven Development). Estas metodologías se basan en un desarrollo iterativo e incremental en el que los requisitos y las soluciones van evolucionando gracias a la comunicación con los usuarios y la colaboración entre equipos multidisciplinares autoorganizados, todo con el objetivo de mejorar la calidad del software y la capacidad de respuesta ante cambios en los requisitos del cliente y el entorno.

En la segunda parte de este post hablaremos del Agile Manifesto y de los beneficios y limitaciones de estos enfoques.

Este post en Marketing & Innovación.

9 comentarios
A %d blogueros les gusta esto: