Buscar en Gazafatonario IT

lunes, abril 13, 2015

Los trinomios cuadrados perfectos no son ágiles… o del principio de la simplicidad

“La perfección no se logra cuando no hay nada más que añadir, sino cuando no hay nada  más que quitar” [Antoine de Saint Exupéry]
En el último conversatorio sobre Scrum que facilitamos en la Comunidad de Ágiles Colombia en Medellín, hablamos de lo que significa ser ágil y llegamos necesariamente a los valores y principios del Manifiesto ágil.  Uno de los principios llamó especialmente la atención: “La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Luego me encontré un artículo* de alguien que decía que había vivido gran parte de o toda su vida sin usar el trinomio cuadrado perfecto y muchas otras cosas complejas que le enseñaron en la escuela. A pesas de mi fascinación por el Álgebra, tuve que ceder un espacio en mi mente para estar de acuerdo con este pensamiento.

La tarea que me quedó fue entonces definir qué significaba #simplicidad y qué era eso de ‘maximizar’ el trabajo no realizado. Aquí algunas pistas:

Simplicidad es:

  • Tener un equipo totalmente horizontal, sin títulos ni especialidades adheridas a la frente de  cada miembro, sin protocolos que seguir para comunicarse unos con otros, incluyendo al usuario, donde cada uno sea responsable de sincronizarse con los demás y que nadie le rinda cuentas a nadie. Son equipos altamente productivos.
  • Usar un framework que te permita adaptarte a los continuos cambios del entorno, que te permita inspeccionar tu situación y la de tu equipo y con el que puedas modificar tu comportamiento basado en la experiencia que vas adquiriendo. Un framework que no sea una fuente de artes adivinatorias, sino más bien que evolucione contigo.
  • Priorizar las características del producto y construir solo aquellas que entreguen valor al usuario y al negocio. Según algunos estudios más del 65% del software que se construye se deja de usar muy pronto o nunca llega a instalarse, así que ¿por qué no construir solo lo que el usuario verdaderamente necesita y que genere un alto valor para la organización? Construye solo necesario para obtener rápida retroalimentación.
  • No realizar estimaciones a mediano/largo plazo ni prometer una fecha fija de entrega. No componer planes súper elaborados sino planificar continuamente: planificar las entregas/salidas a producción, planificar las iteraciones o sprints, planificar cada día de trabajo. A la larga, los planes no son nada, pero la planificación lo es todo.
  • Usar herramientas simples, como tableros de tareas simples que estén a la vista de todos, tarjetas simples con lo que quiere el usuario (las historias de usuario: como <<usuario>> quiero <<hacer algo>> para <<obtener algún valor>>): no hagas nada a menos que su valor esté plenamente establecido. Elaborar la documentación suficiente para cubrir las necesidades de la organización.
    "Pero no más simples"
  • No usar trinomios cuadrados perfectos todo el tiempo. Einstein lo dijo, las cosas deberían hacerse lo más simple posible… para construir algo, una funcionalidad por ejemplo, usa la técnica de reusar-comprar-hacer. Consulta primero si ya la tienes o la tiene alguien cercano a ti. ¿No? Búscala entonces en el mercado. ¿No la encontraste? Fabrícala, pero hazlo de manera simple, sin artificios exagerados, no vuelvas el software más complejo de lo que es por naturaleza.
  • Aprender continuamente. Si conoces muchas cosas, encontrarás respuestas cada vez más simples a problemas cada vez más complejos, como los que surgen en la construcción de productos de software. Así que nunca pares de aprender. Y conviértete en maestro, pero recuerda, no se trata solo de decir las cosas, porque tu aprendiz las olvida; tampoco se trata solo de enseñar, porque quizás solo logres que él/ella las recuerde; involúcralo y verás que también aprende.

¿Qué más se les ocurre que es #simplicidad? Háganmelo saber por este medio o por cualquiera de los medios habituales de comunicación.


*El artículo al que me refiero lo encuentran haciendo clic aquí.


6 comentarios:

  1. Interesante nota.

    Me deja las siguientes dudas:
    1. Cómo logras la horizontalidad en la organización si el empuje viene desde abajo (los técnicos) hacia arriba y debes convencer a una estructura establecida.
    Opción: Presión sobre la empresa: si no cambias en el 2016 no existirás. Puede ser.

    2. Los equipos cambian, la rotación es alta, lograr un ambiente motivador no es fácil cuando cambias de personas cada 2 o 3 meses.
    Opción: motiva a través de un producto desafiante. Aquí el tema es que según los países las que hacen productos son las menos.

    3. Valor al usuario y al negocio. Es correcto en la medida en que toda la estructura conozca el negocio de la empresa y como ésta gana dinero. Cosa no tan común.
    Opción: que la Dirección explique continuamente el negocio a las personas de la organización de modo que estas tengan decisión propia.

    4. Cambiar la forma de estimar está asociado con que quien recibe la estimación o compra sepa que está comprando y como esta compra difiere de comprar otro tipo de servicios.
    Opción: no la veo en las estructuras de Abastecimientos actuales. Hay un largo camino.

    5. Aprender continuamente. Coincido totalmente.

    El resumen, muy buena tu nota, creo que cada vez vemos más que “agile” es quizás un nombre hoy ya pequeño para el cambio que implica. Más que agiles, que muchas veces y erróneamente se lo asocia con desarrollo de software deberíamos hablar de organizaciones “reactivas” como empiezo a ver en muchas publicaciones, ser reactivo comprende a ser ágil.

    Aprovecho este comentario para recomendar nuevamente el libro “Value proposition design” de A. Osterwalder, que si bien lo podríamos clasificar como de negocios, contiene gran cantidad de tips y técnicas aplicables a nuestra profesión. De hecho estoy armando un seminario sobre el tema.

    Si interesa ver mi comentario sobre el libro les dejo el link. http://ideassobresoftware.blogspot.com.ar/2015/03/value-proposition-design-comentarios.html

    Saludos,
    Raúl
    @RaulMartinez582

    ResponderBorrar
    Respuestas
    1. Hola Raúl, sobre tus dudas, aquí algunas de mis notas:

      1. La horizontalidad de la organización viene con la transformación. Precisamente, si los equipos maduran a tal punto que la autogestionan se vuelve común, parte o toda la gerencia media desaparecerá. Pero el proceso es más complejo que eso. Se trata de un cambio de la cultura organizacional y de la mentalidad de las personas. Algunos de mis artículos abordan este asunto.

      2. Consecuentemente, si le das al equipo el entorno y el apoyo suficientes para trabajar, y le confías la ejecución de ese trabajo, como reza otro de los principios del Manifiesto Ágil, estarás un paso adelante en la consecución de personas bastante motivadas, que no querrán irse de la empresa. Si además trabajan a un ritmo sostenido todo el tiempo, nada de picos de trabajo (de subir la intensidad por temporadas que a veces se vuelven eternas), irás más allá en la consecución de esa meta. Los ciclos de entrenamiento son otra llave motivadora para las personas. Son apenas algunas ideas. Hay muchas más.

      3. En efecto, es el negocio, las personas del negocio, quien conoce el verdadero Valor de las cosas, no solo en términos del mero costo de elaboración de un producto, hablamos de ROI, de satisfacción, de usabilidad, de transformar la vida de las personas con un producto, uno cuyos componentes generen resonancia y tengan trama y causen impacto en quien lo usa. Si el negocio se involucra, seguramente esto va a ser posible.

      4. Lo importante es que ya lo estamos haciendo. Otra vez, si el negocio se involucra, seguramente encontraremos atajos en ese largo camino.

      5. Muchas gracias, Raúl. Ágil, en efecto, involucra cambio, transformación, no solo en las organizaciones sino también en las personas. Y, de hecho, Scrum se usa en muchos tipos de industria, más allá del desarrollo de software. Recordemos además que enfoques como Lean, prácticas como Kanban y tantas otras, vienen de otras industrias, por ejemplo, del sistema de manufactura de Toyota (TPS). El espectro es amplio.

      Veré el libro de Osterwalder y tu comentario. Interesante lo del seminario. Nos vas contando, por favor.

      Salud@s,

      Lucho

      Borrar
  2. Buena respuesta.

    Coincido en varias cosas y en otras estoy un poco más lejano.

    Aun así me declaro partidario de todas las técnicas y herramientas que permitan a las empresas competir en este nuevo ambiente de negocio y no hay dudas que agile es una de ellas.

    Saludos,
    Raúl
    @RaulMartinez582

    ResponderBorrar
  3. Este comentario ha sido eliminado por el autor.

    ResponderBorrar
  4. Aclaración al anterior: Estimado Lucho, ante todo gracias por tus reflexiones, mi opinión al respecto es que tener afirmaciones absolutistas que no den paso a la posibilidad de mejora me hace ruido aún en los discursos más agilistas. Cosas como: "Tener un equipo totalmente horizontal, sin títulos ni especialidades adheridas a la frente de cada miembro, sin protocolos que seguir para comunicarse unos con otros, incluyendo al usuario, donde cada uno sea responsable de sincronizarse con los demás y que nadie le rinda cuentas a nadie. Son equipos altamente productivos." Me suena tan fanático como lo contrario. Como el definir que lo "correcto" ahora es esto. Para mí, abrazar el cambio implica estar abierto a la co-creación de mejoras aún en los principios más racionales si el contexto y el equipo lo requiere. Y nuevamente, muy buen post, que invita a la reflexión!

    ResponderBorrar
    Respuestas
    1. Hola Lucho, excelente tu anotación. Estamos de acuerdo si hablas de ‘fanático’ en el sentido de entusiasta, apasionado, incluso fogoso; porque esa es un tanto la intención. No fanático en el sentido de vehemente, extremista o sectario, para nada. Ya en tantos otros artículos y entornos hemos hablado de ello, de lo adaptativo y generativo de ágil, contrario a lo predictivo, tipo receta de cocina, y rígido. También hemos expuesto el hecho de que ágil no es la solución definitiva a los males del mundo, tipo bala de plata, de que aprendemos de la experiencia y de que reflexionamos continuamente para adaptarnos y para mejorar continuamente. Kaizen.

      ¡Enhorabuena por tu participación en el bog, muchas gracias!

      Salud@s,

      Borrar