Buscar en Gazafatonario IT

domingo, enero 20, 2019

Scrumdamentalismo: o de la dogmática ágil




Tengo que confesar que no voy a satanizar a Scrum ni mucho menos a quienes lo practicamos, ¡yo soy uno de ellos! Lo practico no solo en las organizaciones que acompaño, con ímpetu, con altivez cuando es necesario, lo enseño, acompaño a otros a enseñarlo, a practicarlo y he aprendido mucho en el camino. Lo practico con la suficiente apertura como para saber que nunca es suficiente y que debo seguir inspeccionando la realidad para hacer adaptaciones razonables y lograr un cambio sostenible. También lo práctico en mi vida personal, con la pasión y el coraje que se necesita para recargarme cada día y sentir el poder de enfocarme en lo que me emociona y me hace feliz al lado de mi familia.
No, no me malentiendas. Con Scrum en particular y con el pensamiento ágil en general he aprendido que el liderazgo no se trata de una credencial o una designación. Se trata de impacto, influencia e inspiración. Y también he experimentado que a donde sea que vayas, tienes que ir para ser el mejor sin tener que serlo, que no hay fórmulas con la solución para cualquier cosa que ocurra, y que se trata de entusiasmo, honor y trabajo duro. Pero ojo, no nos equivoquemos, es muy fácil confundir pasión, esa determinación con la que hacemos las cosas, sobre todo para promover el cambio, con este scrumdamentalismo que casi siempre, por no ser totalitario, es un sinsentido.
Lo que ocurre es que muchas personas, agilistas o no, siguen buscando la respuesta a todo en las prácticas ágiles, aun en los valores y principios ágiles; lo hacen de manera literal, cuando muchas veces la pregunta correcta es “¿qué te dice el sentido común?”. He trabajado en procesos de mejoramiento (de software) durante las últimas dos décadas y desde siempre he usado este lema: cuando se trata de procesos, marcos de trabajo o prácticas, no subestimes tu poder de pensar. ¡Funciona para mí!
La causa de este fenómeno es que entendimos mal Scrum, sus valores principales o la teoría que lo soporta y tratamos al marco de trabajo como una religión o un dogma, donde todas las respuestas a cada uno de los problemas y escenarios que enfrentamos diariamente vienen de Scrum (esto es precisamente scrumdamentalismo en toda la extensión del término). O bien, hemos entendido Scrum y, sin embargo, le seguimos dando tratamiento de doctrina porque nos gusta su estructura, ese conjunto riguroso y limitado de parámetros que nos hace fácil y llevadera la vida en este universo VUCA que muchas veces nos da temor enfrentar. Es el anhelado “paso a paso seguro” que nos lleva del punto A al punto B sin miedo a equivocarnos.
Es fácil convertirse en scrumdamentalista. Parece un estado inevitable por el que todos hemos pasado. De eso se trata el Shu de Shu-Ha-Ri en donde, si eres Scrum Master sigues con precisión la guía de Scrum, te concentras en cómo hacer las ceremonias con el equipo, que se tengan los artefactos y que cada miembro del equipo se desempeñe como lo plantea la guía o como te dijo el instructor en el curso que tomaste, sin preocuparte demasiado por la teoría subyacente, como por ejemplo: cómo planificar en un entorno empírico.
Lo que convierte a este síntoma en un estigma es querer quedarse allí para siempre. Algunas manifestaciones de los scrumdamentalistas incluyen:
1.     En la Reunión Diaria siempre se responden “las tres preguntas”.
2.     El sprint debe tardar 2 semanas, siempre.
3.     La planificación de un sprint de dos semanas debe tardar máximo cuatro horas.
4.     Solo podemos usar historias de usuario para representar lo que el usuario quiere.
5.     El Scrum Master es el único que puede conducir la retrospectiva.
6.     El Dueño de Producto es el único responsable de definir el incremento de producto para el sprint.
7.     Pensar que cualquier “otro” scrumdamentalista tiene que o debe cambiar, sobre todo después de leer este artículo.
8.     Las herramientas son las armas del demonio de la agilidad.
9.     La documentación tiene que reducirse, ojalá hasta llegar a nada, a cualquier costo.
10.  Tenemos que evitar, incluso alejarnos de, cualquier persona cuyo pensamiento no esté cubierto por el mantra ágil.
Los scrumdamentalistas ven a las organizaciones, comunidades ágiles y consultoras como alquimistas que se presentan ante ellos con sonrisas congruentes y manos extendidas para ofrecer soluciones, transformación cultural, reducción de desperdicios y aumento de felicidad, compitiendo como si se tratara de un mercado persa. Pero solo es porque tienen el recuerdo aciago de un pasado en el que otras organizaciones, comunidades y consultoras se comportaron de manera bárbara cuando eran fuertes y hacían ofertas que no podían rechazar.
Hoy tenemos que partir del precepto de que todos queremos, en efecto, soluciones, cambiar la cultura organizacional, reducir desperdicios, mejorar continuamente y ser más felices. Y que lo hacemos partiendo de la base de que tenemos buenas intenciones, con la información, las habilidades y los recursos que tenemos disponibles. Y reconociendo que la trayectoria pasada no es garantía del desempeño actual y mucho menos del futuro, porque los escenarios cambian.
El mismo Scrum nos muestra la solución a esta disfunción dogmática con sus valores: el empirismo en el que se basa la teoría de Scrum requiere de transparencia, de franqueza (léase apertura). Esto nos enseña a tener la disposición suficiente y necesaria para aceptar las ideas y propuestas de las personas en el equipo y en la organización, aun en procesos complejos de transformación cultural. Precisamos de una apertura tal que nos permita desaprender y aprender en todo momento; y también necesitamos un entorno donde experimentar, fallar y volver a intentarlo.
También debemos tener el coraje para admitir que no somos perfectos y que siempre podemos mejorar y cambiar el rumbo de nuestro pensamiento; coraje para dejar de lado las convicciones del pasado. En resumen, la guía de Scrum, breve y liviana como la han mantenido sus autores, es un compendio pletórico de riquezas, una serie efectiva de propuestas para ayudarnos a hacer las cosas bajo el manto de la mentalidad ágil, pero sin que hagamos a un lado nuestra habilidad, humana y humanizante, de sentir y de pensar.
Incluso yo puedo parecer un scrumdamentalista al escribir este artículo, ¿quién sabe? Quizás sea el más scrumdamentalista de todos, pero estoy trabajando en ello. Solo dame tiempo y ayúdame a sanar.
Lucho Salazar. Lima, 20 de enero de 2019.

domingo, enero 06, 2019

Algunos errores comunes que están haciendo tu transformación ágil más difícil y frustrante

http://www.freepik.com Designed by macrovector / Freepik


Iba a escribir algo sobre las fallas con las que me he encontrado estos años en mi viaje, acompañando y liderando cambios culturales ágiles, entrenando y sirviendo a personas y equipos con algunos de mis colegas y mejores amigos en el terreno.

Como siempre, respiré hondo mientras volvía a leer (¡otra vez!) el tan ampliamente aclamado pero en su mayoría malentendido manifiesto ágil para el desarrollo de software y de repente me llegó esta destornillada idea de escribirlo al “estilo del manifiesto ágil”.

Y así es como surgió este nuevo Manifiesto por la Transformación de Mentalidad FrÁgil, de ahora en adelante llamado aquí “Manifiesto por la Transformación Frágil”.

Esta es solo una forma de expresarme sobre las faltas en las cuales están cayendo los coaches ágiles, líderes ágiles y gerentes de todos los niveles, haciéndole más difícil a las personas entender, aceptar y participar más activa y apasionadamente en las transformaciones ágiles de las organizaciones en este mundo VUCA.

Manifiesto por la Transformación FrÁgile

Estamos descubriendo formas peores de realizar transformaciones ágiles tanto por nuestra cuenta como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Marcos de trabajo, prácticas y herramientas sobre Mejoramiento Continuo

Muchos equipos Scrum sobre Entregar Valor

Silos basados en habilidades y personal en proyectos múltiples sobre Verdadera Colaboración

Medir lo que satisfaga a los gerentes sobre Inspeccionar y adaptar

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Principios detrás del Manifiesto de Transformación FrÁgil

Seguimos estos principios a cualquier costo:

Nuestra mayor prioridad es satisfacer la gerencia tradicional a través de la creación temprana y continua de equipos Scrum

Aceptamos más prácticas, marcos de trabajo y herramientas ágiles, incluso en etapas tempranas de la transformación. Las transformaciones ágiles complacen el ego de los patrocinadores y de su personal.

Creamos escuadrones, tribus y células frecuentemente, desde un par de equipos por semana hasta docenas de ellos por mes, con preferencia a la meta más alta posible.

Los responsables del negocio y los desarrolladores no deben infundir la experimentación y la iteración en el ADN de la organización.

Pensamos que todos los individuos en la organización tienen la misma alta motivación acerca del proceso de transformación. Los tratamos como si todos tuvieran la misma energía, confianza y visión en el cambio.

El método más eficiente y efectivo de informar sobre la transformación en curso es la falta de comunicación a través de toda la organización.

Las herramientas, marcos de trabajo, prácticas instaladas y el número de escuadrones son la medida principal del progreso.

Muchas palabras diferentes flotando sobre la esfera ágil promueven la transformación sostenible. Los patrocinadores, gerentes y responsables de la transformación deben poder pronunciarlas bien, aun si no las entienden en absoluto.

La atención continua a hacer reuniones diarias y retrospectivas sin sentido desmejora la agilidad.

La complexidad, o el arte de usar marcos de escalamiento y contratar expertos en Cynefin, es esencial para presumir.

Los mejores cambios culturales, prácticas ágiles y retroalimentación emergen de equipos internos, sin un acompañamiento y entrenamiento sólidos.

Muy temprano en el proceso, la organización reflexiona sobre cómo ser más ágil para a continuación implantar marcos de escalamiento en consecuencia.

La lista de errores puede ser bastante extensa, así que incluye los tuyos apropiadamente. ¿Y estás preparado para no ser un signatario de este manifiesto? Déjamelo saber en el foro.

Nota:
Publiqué originalmente este artículo en inglés en Pulse de LinkedIn (I originally published this article in English on Pulse from LinkedIn):


viernes, diciembre 28, 2018

Agilistas Pesados (mean agilists)

Escena de la película Chicas Pesadas (Mean Girls)

Personas y equipos disfuncionales pululan por todo el universo. Agilistas de esta clase también. Son comunes en organizaciones y comunidades de todo tipo, como las nuestras. Basado en un artículo original de Tom Schorsch, capitán de la fuerza aérea estadounidense, escrito en 1996 para CrossTalk Magazine, y que hacía referencia a niveles negativos de CMM, los dejo con esta tipología liviana y fácil de entender pero difícil de llegar a dominar.
El Agilista Certificado
¡Como tenía que ser! Este espécimen siempre comienza su discurso presentando su más reciente certificación y enumerando todas las demás, enfatizando en que los certificados le dan el poder suficiente y necesario para ejercer su papel no solo en la organización sino en la comunidad mundial. Conoce los detalles de todos y cada uno de los marcos de trabajo, prácticas y, sobre todo, de las herramientas que según él son requeridas para una agilidad apropiada e impecable, pero nunca o casi nunca ha participado como miembro de un equipo de campo. Algunos ejemplares de esta colección leen mucho, hablan bastante bien en público y son empáticos. Pero la mayoría solo cree que están por encima del bien y del mal. No necesitan mejoramiento, mucho menos continuo.
Creen y promulgan que son más rentables que quienes no tienen sus calificaciones, independientemente de la calidad del trabajo que producen.
El Agilista Negligente
Es un líder que presta a la organización un servicio muy especial, de hecho, a menudo con excesiva fanfarria, sobre todo para implementar procesos semirígidos y rígidos alrededor de una seudoagilidad enmascarada. Sin embargo, este personaje incluso carece de la voluntad suficiente para llevar a cabo el esfuerzo necesario de cambiar y de hacer cambiar a su equipo y mucho menos a su organización. Generalmente no producen ni ayudan a producir nada y, cuando lo hacen, buscan solo su gloria personal y lo hacen usando procedimientos tradicionalistas de emergencia, argumentando que ya no hay tiempo de hacerlo de la manera “correcta”.
El Agilista Obstructivo
Su lema es: los procesos, aunque sean inapropiados e ineficaces, se implementan con rigor y tienden a obstruir el trabajo. Para esta raza de agilómanos, la adhesión al proceso es la medida universal de progreso y del éxito. Conocen bien los nombres de las secciones de la guía de Scrum y de otros marcos de trabajo y practican aquello de que los roles, eventos, artefactos y reglas del marco de trabajo son inmutables y que el marco de trabajo solo existe como un todo. Cualquier creación real de un mínimo producto viable es incidental. La calidad de cualquier producto no se evalúa, presumiblemente suponiendo que dicha evaluación es innecesaria, ya que si se sigue el proceso adecuado, se garantiza una alta calidad.
Según mis observaciones en la última década, esta es la raza más abundante en el ecosistema ágil universal.
Promueve fervientemente que se sigan las guías oficiales de las prácticas ágiles y los procedimientos definidos, pero al carecer de la voluntad para medir la efectividad de tales prácticas, rara vez tienen éxito en su tarea básica de crear trabajo. Incluso impulsa el que a los equipos se les pague no por el valor de sus productos, sino por la cantidad de horas dedicados a construirlos y fomenta la realización de actividades sin valor agregado pero relacionadas con la adherencia a los marcos de trabajo.
El Agilista Desdeñoso
Los agilistas de esta estirpe se las han arreglado para lograr que los equipos en los cuales están involucrados y la alta gerencia ignoren o intenten neutralizar las percepciones desfavorables suscitadas a raíz de la ineficacia de la organización a la cual pertenecen, asunto que ya se ha hecho evidente para el mercado circundante. Sin importar el impacto negativo a mediano y largo plazo, las métricas de embellecimiento son las preferidas y, sin embargo, las mismas se someten a un proceso de embellecimiento antes de salir a la luz en reuniones de comités primarios y directorios donde se alimenta el ego de quienes no se comprometen.
Con desdén pero con una alta dosis de lisonja, logran que la volatilidad en las especificaciones y los cronogramas se refundan como evidencia de la "agilidad" de la organización. Presentan las certificaciones sobre los "mejores procesos" como evidencia de que la organización está funcionando de manera óptima; comprometen a la organización con la adherencia a la “sección ágil” de los métodos tradicionalistas (léase CMMI Ágil, ISO Ágil, ITIL Ágil y un largo etcétera). Atribuyen los malos resultados a factores fuera del control de la organización. Finalmente, consiguen que la organización se comprometa con los procesos ineficaces, lo que lleva a un ciclo de retroalimentación de creciente desorganización.
El Agilista Roedor
Trabaja habitualmente para minimizar y socavar los esfuerzos de quienes buscan hacer la diferencia, a quienes este ejemplar ve como antagonistas. Rivaliza especialmente con quienes están tratando de hacer la diferencia como agentes de cambio y solo está pendiente de lo que hagan estos para copiarlo y anunciarlo como propio. Abundan en organizaciones que disponen de recursos escasos para cambiar su cultura y solo quieren aprovechar los recursos de organizaciones más efectivas y las habilidades de líderes genuinos.
El Agilista Inocente
Si llegaste hasta aquí, espero que hayas reído al menos un poco. Era el propósito de todo. ¡Pásala por inocente!

¿Qué te pareció la charada? Por favor, dejámelo saber en el foro.
Lima, 28 de diciembre de 2018

sábado, diciembre 01, 2018

Las mejores o buenas prácticas ágiles no existen


¡Las peores o malas tampoco!
Veamos la historia de cómo es esto.
Hace quince años escribía un artículo que dio pie a mi primer libro Asuntos de la Ingeniería de Software (clic aquí), se trata de las muy comentadas hace un par de décadas: Seis Mejores Prácticas (clic aquí), las mismas que promulgaba el Proceso Unificado (UP o RUP, dependiendo de la edición que hayamos usado de la metodología - clic aquí).
Lo nuestro ahora son los experimentos, usamos lineamientos “tipo Scrum” basados en la teoría del control empírico de procesos, planteamos hipótesis y las probamos en períodos muy cortos de tiempo, tratando de aumentar el número de experimentos por unidad de tiempo. De esta manera, si fallamos, lo hacemos rápido y barato; pero si tenemos éxito, entregamos valor igual de rápido y de barato.
De esta forma, toda práctica, toda idea es bienvenida. El hecho de que una práctica no le funcione a un equipo o a una organización no quiere decir que no le servirá a otro equipo o a otra organización, incluso entre equipos de la misma empresa esto puede suceder. Los escenarios y las variables del entorno son diversos, es por ello que dejamos atrás las recetas predefinidas tipo RUP, CMMi y similares. Pero el sentido inverso de esta afirmación también se cumple: el que funcione en un contexto no es garantía de que una práctica funcione en otro.
Hoy por hoy aprendemos por experimentación, descubrimos por experimentación (por ejemplo, descubrimos el software que escribimos), innovamos por experimentación, diseñamos por experimentación, cambiamos por experimentación. En este apartado quiero referirme precisamente a lo que Jason Little llama Gestión Lean del Cambio (clic aquí).
 Gestión Lean del Cambio
Un modelo no lineal, basado en la retroalimentación, para gestionar el cambio
Algo que nos ocurre muy seguido es que fallamos al tratar de identificar el problema correcto a resolver, lo que confluye en la insalubre generación de desperdicio. Toda práctica que nos posibilite el evitar esa falla se convierte en una sinfonía para nuestros oídos.  Los experimentos nos ayudan a reconocer a gran velocidad si el problema que tenemos entre manos es el oportuno, es el que debemos resolver a continuación.
De hecho, los experimentos están en el corazón de la innovación. También, las mejoras incrementales a los productos y servicios que desarrollamos requieren que hagamos experimentación continua. Para todo esto es necesario:
  • Trabajar en equipo: el trabajo colaborativo, en equipo, la inteligencia colectiva es lo que permite el éxito. El ejercicio de la colaboración siempre está en la cima de mis prioridades.

  • Simplicidad: no se trata solo de no generar desperdicio, sino también de refinar el problema, dividirlo en problemas cada vez más pequeños.

  • Dar un paso a la vez: no tratemos de experimentar con todo y de todo de una sola vez. Esto casi siempre es un camino al abismo. Lo que quizás sí podemos hacer es realizar varios experimentos al tiempo. ¡Funciona para mí!

  • Obtener conocimiento pronto y con frecuencia: hay que recorrer rápidamente todo el camino. El objetivo son los consumidores finales, no grupos controlados de clientes o usuarios.  Los MVP funcionan pero no todos pueden quedarse en el laboratorio.

  • Estar preparados para fallar y aceptarlo: nos va a ocurrir. ¡Me ha ocurrido! Simplemente levántate mañana con más energía, con una gran sonrisa y con una nueva idea. En esto de la agilidad siempre sale el Sol, radiante, así que vuelve a invitar a tus amigos e inicia un nuevo experimento.

  • Cerciorarse de que tu organización considere la seguridad como un prerrequisito valioso (agilidad moderna – clic aquí – donde, de hecho, experimentar y aprender rápidamente es otro principio).
 Agilidad Moderna

De todo esto he logrado:
  • Ahorrar dinero: tanto para mí como para las organizaciones para las cuales he trabajado y no hablo solo de mis empleadores, sino de los clientes también.

  • Fallar de forma positiva: y también a evitar que se produzcan fallas más significativas que produzcan resultados desastrosos, grandes pérdidas de tiempo, dinero, oportunidad, marca y hasta de felicidad de todos los comprometidos.

  • Desarrollar mejores productos y servicios: o ayudar a diseñarlos, descubrirlos y ponerlos en funcionamiento, al servicio de miles o de millones de personas.

  • Aprender más y más rápido: la experimentación nos permite estar más informados y tomar mejores decisiones sobre nuestras ideas y proyectos. Muchas cosas parecen de sentido común, pero he aprendido que el sentido común muchas veces no es la práctica común.

  • ¡Ser más feliz!

Y esta es la historia del porqué no existen las buenas, mejores, malas o peores prácticas en agilidad.
Por ello, la próxima vez que alguien te diga (incluso a veces levantándote la voz) que algo no se puede hacer bajo el manto de la agilidad o al usar Scrum o algún otro marco de trabajo ágil, indaga primero los hechos, los datos que dieron origen a tal aserción. O no lo hagas del todo. Simplemente realiza tu propio experimento y déjanos saber de los resultados. 

martes, noviembre 13, 2018

¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?

Por:
Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)



Aunque en varios foros hemos compartido que contratar en Cascada (o tradicional, o con alcance, tiempo y costo fijos) un proyecto (o mejor, producto) ágil es completo dolor de cabeza para ambas partes, es como querer jugar rugby con las reglas del fútbol, en este post, quisiéramos compartirte unas ideas claves de por qué no te conviene hacer esto tanto desde el punto de vista del Cliente como del Proveedor, vamos pues:

Problemas desde el punto de vista del Cliente

  • El alcance no puede ser fijo en estos tiempos de alta disrupción  (VUCA (1)) y es un error tratar de definir los requisitos a priori dada esta misma volatilidad(2)
  • El proceso de control de cambios (no te agregaría ningún valor)haría muy lenta las decisiones, y retrasaría el Time to Market, considerando que en ágil existe una continua repriorización y modificación de los requisitos en función del valor.
  • Tal vez  (la verdad, muy seguramente) te obligues a construir lo innecesario.
  • Como la responsabilidad no es compartida, se genera una relación de competencia en vez de una relación de colaboración, impidiendo maximización del valor del producto. 
  • Las estimaciones y costos con seguridad estarán inflados debido a la incertidumbre 
  • Quemarás al proveedor y al equipo de trabajo, pues estos fallarán continuamente en sus estimaciones.
  • Los contratos tradicionales se basan en la desconfianza. Esto aumenta la incertidumbre y maximiza los riesgos. La incertidumbre y los riesgos nunca son buenos para el cliente, generan presión y desgaste. Se pierde el foco en lo que es realmente importante: el valor para la organización y la oportunidad.
  • Los planes se basan la percepción y no en la realidad. Lo que conduce a que haya una dedicación exclusiva a "cuidar" esos planes. Esto es desperdicio. Pérdida de dinero. Dinero del cliente.
  • La realidad es lamentable: con un contrato tradicional siempre o casi siempre hay desviación por sobrecostos, esto “hiere” mortalmente la confianza interna del cliente, es decir, entre las áreas involucradas.
  • Los continuos cambios pueden ocasionar modificaciones en las cláusulas en el contrato. Allí surgen roces entre las partes, proveedor y cliente.


Problemas desde el punto de vista del Proveedor

Nota: este tipo de espantajos metodológico-contractuales por lo general se contratan bajo la siguiente forma: un alcance definido o que se define durante los primeros dos o tres meses y luego se hace una estimación que se parte en sprints.


  • De entrada sabes que la estimación es fallida, que debes incrementar costos y tiempos y no tienes como justificarlo, y aunque lo justifiques el cliente no te creerá haciendo reducir costos y tiempo (pues el alcance lo dejan fijo) y exponiéndote a un riesgo financiero, reputacional o de penalidades.
  • Aunque estimes a priori el proyecto y ejecutes por sprint, te atrasarás debido a la incertidumbre de reinante en el mundo del software, incrementando la presión sobre el proyecto y la ejecución
  • Te la pasarás reunión tras reunión justificando por qué no estás cumpliendo el plan (sabiendo que trabajas en scrum con sprints) y tratando de reacomodar el plan
  • Los controles de cambio son un dolor de cabeza que no te permite realizar priorización por valor que le conviene más al cliente y al proyecto (producto)
  • Las métricas de seguimiento cascada aplicadas al proyecto (o producto) en ágil generan un desgaste pues no hacen match con las métricas de seguimiento ágil.
  • Quemarás a tu equipo tratando de ponerte al día con el cronograma de sprints comprometido al principio del proyecto.


Soluciones

  • Contrata en ágil los proyectos ágiles (ver nuestro video sobre contratos ágiles - https://www.youtube.com/watch?v=872uF0dPYd8) 
  • Pon cláusulas de terminación anticipada, que te sirvan cuando decidas no continuar con el cliente o con el proveedor según el caso.
  • En un contrato ágil nunca pongas el alcance fijo.
  • Si te preocupan los ANS o SLA, en Scrum tienes software funcionando cada dos semanas lo que permite validar si el proveedor está construyendo el producto de forma satisfactoria.


Si tienes alguna otra disfuncionalidad a compartir, no dudes en hacerlo en la zona de comentarios.

Saludos Ágiles,

Lucho Salazar (@LuchoSalazarC) y Jorge Abad (@Jorge_Abad)


Referencias, comentarios, notas y aclaraciones
1. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
2. Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software - http://www.lecciones-aprendidas.info/2015/04/radioactividad-de-los-requisitos.html 

3. Este artículo fue escrito a cuatro manos y fue publicado en las Lecciones Aprendidas en http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html