Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Transformación. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Transformación. Mostrar todas las entradas

martes, abril 26, 2016

Del triángulo de hierro al triángulo ágil (modificado)


Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!


Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:
  • Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
  • Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
  • Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.


Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:


Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:



Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil

miércoles, mayo 13, 2015

Ágil es algo que eres

Foto de http://pixshark.com
Para implementar una verdadera Cultura Ágil se requiere un nivel más alto de confianza de lo que es necesario en los enfoques tradicionales.  Responsabilidad y transparencia son dos de los beneficios clave de tener una Cultura Ágil. Más sobre Cultura Ágil en “Cultura Ágil: ese oscuro objeto del deseo
Para alcanzarla, para establecer una verdadera Cultura Ágil, debemos revisar las ideas que tenemos de los enfoques tradicionalistas e iniciar un camino que quizás sea o se vea poco confortable para muchos en la organización, puesto que ese camino hacia la cultura ágil expone las debilidades existentes no solo en la estructura sino en el comportamiento organizacional, es como si el ojo del Gran Hermano se posara sobre todos los miembros de la organización y les permitiera observarse a sí mismos, como en un espejo virtual, y al resto del entorno: clientes, proveedores, socios de negocio y mercado potencial, a observarlos desde el exterior.
Por ejemplo, respuesta ante el cambio sobre seguir un plan, uno de los valores del Manifiesto Ágil, es apenas una de las divergencias filosóficas cardinales entre los enfoques enraizados desde siempre en el desarrollo de software y esta visión emergente que significa ser ágil. Sobre este valor en particular, pueden leer mi artículo relacionado aquí. Más sobre el Manifiesto ágil en este enlace.
La Cultura Ágil es un continuum:
  • Empieza con la persona, se irradia primero hacia los equipos y luego a toda la organización, y termina en la persona.
Cuando hablamos de los productos, además de los atributos de excelencia que deben tener, es relevante interiorizar que:
  • El responsable de la calidad de un producto es Todo el Equipo Ágil. Además, una vez que el equipo entregue el producto, que este deje la sala de desarrollo, es porque está preparado para salir a producción.
  • Un error, una falla, no se ve como un evento crítico sino como una oportunidad de aprender acerca de los componentes del producto (el código, por ejemplo), del proceso y de cada uno de los miembros del equipo.
En su libro, “Being Agile”, Mario Moreira nos dice que “crear o adoptar una cultura ágil no se hace por accidente” y yo agrego: tampoco se hace por decreto. Moreira enumera algunas actividades que te ayudarán a moverte a una cultura ágil:
  • Reconocer que moverse a Ágil es un cambio cultural
  • Compartir los Valores y Principios Ágiles (continuamente)
  • Establecer y compartir objetivos y motivaciones
  • Obtener retroalimentación continua de los empleados. (Podemos extrapolar esto a conseguir retroalimentación de los socios de negocio, de los clientes, de los proveedores, es decir de todo el ecosistema organizacional)
  • Adaptar el sistema de recompensas para alinearlo con la nueva cultura
  • Identificar técnicas para ayudar a mitigar la resistencia de manera agradable
  • Evaluar a la administración y ver si los empleados tienen una personalidad que les permita alinearse con la nueva cultura
  • Comenzar a vivir los valores y principios que te ayuden a alcanzar la cultura que estás buscando
  • Proporcionar mecanismos de comunicación que se alineen con la cultura que quieres
  • Identificar y aplicar los procesos, métodos, prácticas y herramientas ágiles que estén alineados con tus objetivos
  • Aplicar un enfoque de inspeccionar y adaptar para medir el progreso
Debo insistir en que la vía hacia una transformación ágil, más que adopción, es un salto en la evolución, en el sentido de los saltos que ha dado la naturaleza durante millones de años, solo que aquí no tenemos tanto tiempo, pero un cambio de este nivel puede llevar un quinquenio, quizás una década, sobre todo para organizaciones que llevan 30 o 40 años usando enfoques y técnicas tradicionales.
Es decir, no se trata simplemente de cambiar un proceso por otro e institucionalizarlo, no se trata estrictamente de pasar de “manual” a “automatizado”, o de ir de integración bajo demanda a integración continua. Estas apenas son señales de que “lo estás haciendo ágil” y, en últimas, ágil no es solo algo que haces, ágil también es algo que eres.
-----------------------------------------------------------------------------
*La imagen interior es de [http://kidskidskids.tumblr.com/]

jueves, abril 23, 2015

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

“El Control conduce al cumplimiento; la autonomía conduce al compromiso.”
Daniel H. Pink (Autor de “A Whole New Mind: Why Right-Brainers Will Rule the Future”)

Imágen tomada del artículo de Computer.org
En 1982, Tom DeMarco escribió su renombrado libro “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982). La primera frase del libro, su primerísima idea, quedó ensamblada en los anales de la industria de software durante las siguientes décadas y nos ha llegado intacta hasta esta era. Se trata de su: “No puedes controlar lo que no puedes medir”.

Este pensamiento influyó de manera certera en los modelos de calidad, procesos de producción, enfoques de mejora* y herramientas de construcción de software, quizás como ninguna otra idea de aquellos tiempos. Pero incluso Tom DeMarco cambió de opinión. En 2009 publicó este artículo en la IEEE Computer Society: “Software Engineering: An Idea Whose Time Has Come and Gone?”  (Ingeniería de Software: ¿una idea cuyo momento ha pasado?)” que pueden encontrar haciendo clic aquí.

En el artículo, DeMarco reflexiona sobre si este consejo era correcto en ese momento, sobre si todavía era relevante (al momento de escribir ese artículo en 2009) y que si todavía creía que las métricas eran un deber ser para cualquier esfuerzo exitoso de desarrollo de software. Sus propias respuestas fueron unos tajantes no, no y no.

Es bien conocida la historia de que los enfoques rígidos más tradicionalistas adhirieron completamente a este precepto y crearon áreas de proceso y de conocimiento dedicadas en su totalidad al establecimiento, gestión y control de métricas en los proyectos (de software). A partir de allí, se empezó a medir el éxito o fracaso de los proyectos, en principio, con tres de esas medidas: el tiempo, el presupuesto y la calidad, siendo esta última un poco más abstracta y más subjetiva si se quiere. Después, con muchas otras que no vale la pena mencionar aquí.
Esa institucionalización de métricas derivó a su vez en algo que con el tiempo se convirtió en uno de los mayores desincentivos para quienes trasegamos por los laberintos azarosos de la construcción de productos de software: el trabajo intensivo, esas largas jornadas de trabajo de doce, dieciséis y más horas diarias durante largos períodos de tiempo previos a la entrega del producto. Mi amigo y colega Jorge Abad dice en su blog Lecciones-Aprendidas.info que eso trajo como consecuencia la destrucción de hogares, de familias enteras y yo le creo.

Esta forma de trabajo extrema, cuya consecuencia principal, además de la citada por Jorge, era la de un bajón en productividad, acompañado de una entrega de producto con mala o malísima calidad, con el tiempo degeneró en algo mucho más grave que es de todos conocido: desmotivó a las nuevas generaciones a estudiar carreras relacionadas con la TI: Ingeniería Informática, de Sistemas, de Software y afines. El mismo Tom DeMarco (¡otra vez!) enunció en su otro libro, “Peopleware : Productive Projects and Teams” (2ª edición, 1999), que “no trabajamos horas extras en demasía para terminar el trabajo a tiempo sino para protegernos de culpa cuando inevitablemente no conseguimos hacer el trabajo a tiempo.” En efecto, lo hacíamos simplemente para cumplir, no para ser más productivos, ni para mejorar la calidad del producto. Y a eso nos llevó la fuerza ejercida por el modelo de Comando y Control y de la medición de cosas que no reflejaban la realidad del proyecto, al menos no la realidad de las personas que ejecutaban el proyecto.

La reflexión de DeMarco en el artículo que ya he citado termina también de manera asombrosa para quienes seguimos sus cánones durante casi tres décadas: “Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.”

Bien sabemos ya que lo más importante en los proyectos de software es la entrega continua y frecuente de Valor al negocio, desde el inicio del proyecto. Y que nunca más apostaremos o usaremos artes adivinatorias para establecer la fecha de entrega, ni qué parte del producto entregaremos en ese momento, ni cuánto será su costo. En cambio, empezaremos con planes y alcance iniciales y nos enfocaremos en la revisión continua de esas restricciones a medida que vamos avanzando. Finalmente, nuestra meta será siempre entregar el mejor producto posible, teniendo presente que ningún método con el enfoque de receta de cocina (léase métodos tradicionalistas) hará mejor lo que es mejor. Esta es la filosofía ágil.

Coletilla

Aquella aciaga prescripción de DeMarco sobre lo que se puede medir y controlar derivó en procesos rígidos, tradicionalistas, que dieron poder solo a algunas personas en la organización; pero lo realmente hermoso, lo humanamente divino, es que los métodos y las prácticas ágiles dan poder a todo el mundo… o a nadie.



--------------------------------------------------
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”

viernes, abril 17, 2015

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos tipo CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se está hablando en el  #RSGECU2015.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.

miércoles, abril 08, 2015

Presentación sobre Transformación Sostenible



Este martes 7 de abril, nos reunimos participantes de las Comunidades del Próximo Capítulo del PMI Antioquia y de Ágiles Colombia a hablar sobre Transformación Organizacional Sostenible. Al margen de la sesión, creo que es una excelente idea que se realicen este tipo de encuentros entre Comunidades ya que el objetivo que buscamos todos es el mismo: hacer las cosas bien y encontrar formas de mejorar continuamente.

Facilité la sesión alrededor del trabajo que realizáramos el magnífico equipo de coaches del que hice parte durante el Scrum Coaching Retreat Latin America  (#SCRLA15) en marzo de 2015, en Buenos Aires, Argentina. Se trata de un marco para Sostenibilidad de las Transformaciones Organizacionales que publicamos al final del encuentro. Un trabajo en progreso.

Los dejo con el material de la presentación: Transformación Sostenible

Más información sobre el trabajo del equipo y de los demás equipos en el Scrum Coaching Retreat Latin America 2015, puede encontrarse en:


Sobre Adopción y Transformación pueden leer mi artículo en:


Sobre el cambio a ágil, temores infundados y penas frívolas, pueden leer mi artículo en:


miércoles, abril 01, 2015

Sobre Adopción y Transformación

“Todos los modelos son útiles, pero algunos fallan más rápidos que otros.” [Jurgen Appelo]
Me llamó la atención uno de los números del recién salido ‘State of Agile Survey’ de la consultora VersionOne [1]. Se trata de las barreras que encuentran las compañías a la hora de realizar la adopción Ágil. Revisando los tres últimos informes (2012, 2013 y este último correspondiente a 2014), encuentro que los principales obstáculos para adoptar Ágil son:
  1. (Falta de) Habilidad para cambiar la cultura organizacional
  2. Resistencia general al cambio
  3. Intento de introducir elementos ágiles en un framework no ágil
  4. (Falta de) Disponibilidad de personal con las habilidades necesarias
  5. (Falta de) Apoyo de la dirección
Figura 1. Fuente: VersionOne 7th State of Agile Survey 2012. Haga clic en la figura para ampliar.

Mientras que las tres últimas causas que menciono se mantienen en porcentaje más o menos estable, aunque me interesa hablar más delante de la cuarta (falta de personal idóneo), quiero concentrarme en la dramática reducción que hubo en los números de las dos primeras.

Mientras que en 2012 y 2013, el peso de la inhabilidad para cambiar la cultura organizacional fue se mantuvo más o menos constante, 52% y 53%, en 2014 este número descendió a un 44%. Es decir, menos de la mitad de los encuestados dijo que ese es el parapeto más fuerte por derribar a la hora de adoptar métodos y prácticas ágiles en las organizaciones.

Figura 2. Fuente: VersionOne 8th State of Agile Survey 2013. Haga clic en la figura para ampliar.

Algo similar ocurrió con la Resistencia general al cambio, natural por demás en la gran mayoría de las organizaciones y personas. De un 41% y 42% en 2013 y 2013 respectivamente, bajó hasta un 34% este último año. Es una encuesta al fin y al cabo, basada en la percepción y, como esperamos todos, en la experiencia de quienes respondieron las preguntas, entre ellos yo mismo.

Aunque el estudio no presenta ni analiza las causas de esos cambios porcentuales, quisiera especular un poco al respecto. Se trata precisamente de lo que hemos aprendido y experimentado durante los últimos tres años. Hasta principios de esta década, había “una confusión entre adopción y transformación. Tristemente, los agentes de cambio hablaban acerca de adoptar Ágil y no acerca de transformar la cultura de una compañía para que esta soportara la mentalidad ágil” [2] y todo lo que ello significaba. Sahota lo llamó “miopía de los agentes de cambio”. En definitiva, muchas de las fallas en la adopción Ágil radicaban entonces o eran el resultado de no entender la cultura organizacional.
 
Figura 3. Fuente: VersionOne 9th State of Agile Survey 2014. Haga clic en la figura para ampliar.

Pero creo que hemos aprendido que para ser ágiles necesitamos conformar equipos con personas que sean capaces de estar juntas a través del tiempo, que se conviertan en equipos de alto desempeño y que construyan escenarios de confianza con sus usuarios/clientes. Si no lo tienes claro, lo que debes hacer es crear equipos ágiles alrededor de los objetos persistentes en tu organización, es decir, los proyectos. Usa Scrum o Kanban o XP (aunque según el estudio que he citado, eXtreme Programming se usa cada vez menos –menos del 1% de los encuestados dijeron que usaban XP en 2014) o cualquier otro método ágil que permita llevar tu organización a puerto seguro a nivel de equipos.

Tus equipos ágiles deben enfocarse en validar continuamente sus hipótesis y en generar valor lo antes posible. En mi artículo “Cultura ágil: ese oscuro objeto del deseo” decía que esta es la base para formar equipos de alto rendimiento que enfrentan alta incertidumbre, como la presente en los proyectos de software. En estos equipos cambiamos la planificación basada en especialidades por un enfoque en la propagación de conocimientos, de experiencia. Además, en los equipos ágiles invocamos continuamente energías innovadoras para encontrar formas mejores de aumentar la productividad y el entusiasmo de los participantes.

Eso es lo que creo que está pasando. Como dice VersionOne en el estudio, “Ágil está ganando momento” y lo que no dice es que quienes lo estamos haciendo, quienes somos ágiles también. Ágil es algo que eres, ágil es algo que soy.

Una nota final sobre la falta de personal con las habilidades necesarias en Ágil

Aunque ligeramente, fue mayor el porcentaje de encuestados que respondieron a esta barrera en relación con los dos años anteriores, en los que el número fue del 33%. Esta vez, 35%. En este sentido es vital entonces no solo aumentar el entrenamiento sino también mejorarlo. Y valga aquí la pena decir que no es suficiente con obtener certificaciones, sea cual fuere la casa o escuela certificadora. Ya sabemos que en Ágil, sobre todo en Scrum, es extremadamente fácil obtener un certificado de Scrum Master o de Scrum Developer, pero, al igual que el propio marco de trabajo, es considerablemente difícil hacerlo valer en proyectos reales.


El certificado conseguido después de un  Scrum nos asegura que sabemos construir ciudades con piezas del set #6177 de Lego y que hicimos 240 puntos en el Ball Point Game y que quizás nuestro próximo proyecto con Scrum será exitoso, pero nada más. La experiencia es fundamental para una verdadera transformación. Lo menciono porque me sigo encontrando con personas, colegas, amigos y hasta familiares que insisten de manera agotadora en este asunto de la certificación y no en ir directamente al fondo de las cosas: al hacer ágil y al ser ágil.


Ciclo Sensei - Senpai - Kohai


Es necesario que haya más ciclos “sensei – senpai – kohai”[3], para aprovechar el conocimiento y, sobre todo, la experiencia de otros. Es necesario hacer Comunidad, algo que seguimos insistiendo con amigos como Jorge, Wilmar, Leonardo, Carlos, Robinson y Lucho y tantos otros en Ágiles Colombia y Ágiles Latinoamérica, con quienes nos reunimos constantemente. El autoaprendizaje también ayuda. Más allá de todo esto, tener el coraje de decir que necesitamos ayuda, que no podemos hacerlo solos.




Referencias

[1] VersionOne. 9th State of Agile Survey. 2015.

[2] Sahota. Michael. “An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture”. 2012

[3] Ciclo Sensei – Senpai – Kohai, algo que aprendimos en el último #SCRLA15 del amigo Hiroshi y que usáramos en nuestro trabajo sobre Sostenibilidad de la Transformación Organizacional, algo de lo cual les hablaré más adelante. El ciclo se refiere a los estudiantes nuevos (Kohai) aprendiendo de estudiantes más avanzados (Senpai) y estos a su vez aprendiendo y practicando con maestros experimentados (Sensei).