Buscar en Gazafatonario IT

miércoles, julio 18, 2018

Apuntes sobre transformaciones ágiles: las personas, sus miedos y qué hacer al respecto


(Tiempo aproximado de lectura: 7 minutos, 30 segundos)
Las personas son lo más importante de una organización y los gerentes deben hacer todo lo que puedan para mantener a las personas activas, creativas y motivadas, o algo así nos dice Jurgen Appelo a propósito de energizar a las personas en sus ya muy conocidas técnicas de Management 3.0. Los agentes de cambio también tenemos esa obligación con las personas: motivarlos, energizarlos, enamorarlos de las nuevas propuestas, de las nuevas formas de hacer las cosas.
Por ejemplo, promover el uso de herramientas simples que se adapten a las personas puede ser una magnífica idea cuando introducimos nuevas formas de trabajar en una organización. Instrumentos cuyo aprendizaje no tome mucho tiempo y cuyo uso sea natural y hasta espontáneo y que no intimide. Los radiadores de información como los tableros de tareas son un buen inicio.
Ahora bien, la revitalización casi nunca viene de arriba (de la alta gerencia). La revitalización comienza en los suburbios de la organización, conducida por líderes de área que crean planes para solucionar problemas concretos. A través del alineamiento de tareas –dirigiendo las responsabilidades de las personas hacia la tarea competitiva central de la empresa– estos líderes enfocan su energía en el trabajo y no en abstracciones como “empoderamiento” o “cultura”.
Revisar el propósito y la visión de la empresa, publicar la declaración de la misión y lanzar programas diseñados para causar un cambio en la organización, no siempre tienen el resultado esperado. ¿Cuál es el papel de la alta gerencia en este proceso? Establecer en qué dirección irá la compañía, sin necesidad de implantar lo que para el resto de la empresa puede verse como soluciones dictatoriales. Después, simplemente tiene que dedicarse a respaldar y divulgar las lecciones aprendidas de las áreas renovadas en toda la compañía.
Por su parte, los equipos son dueños de su propio destino. Los líderes están allí para suministrarles las piezas necesarias y suficientes y las guías apropiadas para el uso de esas piezas: armar el rompecabezas sigue siendo responsabilidad de cada uno de ellos y de sus miembros.
Durante los procesos de transformación te encuentras con dos tipos de personas: las que quieren el proceso para seguirlo, aquellas que no son capaces de hacer nada sin un proceso riguroso, meticuloso, estricto, universal, absoluto, paso a paso, detallado y definitivo. Y las que quieren ese conjunto de reglas rigurosas, estrictas, detalladas, obligatorias, para no seguirlas. En cualquiera de los dos casos, el pensamiento Ágil no les cae bien porque no establece o prescribe ni lo uno ni lo otro.
Algunos enemigos de la innovación son también enemigos del cambio y generan aprensión, estudia y practica cómo lidiar con ellos:
1.  Cultura de culpa
2.  No hay espacios seguros para experimentar
3.  Deseo de complacer a todos
4.  Grandes egos
5.  Dudas
6.  Microgestión del talento
7.  Miedo al fracaso
8.  Demasiado rigor en los procesos
9.  Impaciencia
10.      Abundancia de recursos
11.      HIPPO (Opiniones de las Personas más Altamente Pagadas en la compañía, muchas veces consultores externos que no conocen el ambiente organizacional actual)
12.      Necesidad de KPI medibles inmediatos
En síntesis, lograr una transformación sostenible requiere de compromiso, coordinación y competencia y nada de eso se logra por decreto. Las ordenanzas, por el contrario, producen más temor en las personas y estas se retraen y terminan alejándose del cambio. Algunos de estos consejos te pueden ayudar a lidiar con este fenómeno[1]:
1.  Haz que el compromiso a la transformación se logre mediante el diagnóstico conjunto de problemas. Sé inclusivo, logra la participación de todos en la organización.
2.  Desarrolla una visión compartida de cómo prepararse y organizarse para la competitividad. Las empresas más exitosas actualmente tienen un alto grado de colaboración y de innovación pero no olvidan el mercado.
3.  Promueve el consenso para la nueva visión, la competencia para promulgarla y la cohesión para avanzar. Esto requiere de liderazgo y de apoyo de la alta gerencia. Sin eso estás perdido.
4.  Energiza todas las áreas de la empresa, empezando por las personas que las integran. Eso sí, no presiones ni busques que la alta gerencia presione. Necesitas crear un entorno cooperativo, no uno coercitivo.
5.  Cuando hayas probado el cambio, cuando hayas logrado que la organización deguste lo que viene, institucionaliza la revitalización a través de políticas, sistemas y estructuras formales.
6.  Monitorea el proceso de energización, ajustándolo en respuesta a los problemas que encuentres, a los escenarios actuales. No trates de copiar una receta o un modelo calificado como exitoso en otra organización, el que obtengas el mismo resultado será apenas una feliz coincidencia.
Influenciar el grado de resistencia al cambio es un esfuerzo colectivo. Cada que puedas, une a más personas, a más áreas en la organización y con todos, haz un nuevo esfuerzo para influir en el resto aun no “convencido”, esta vez con más ahínco que antes. Y sin importar a cuántos logres convencer esta vez, prepara de inmediato la siguiente actividad. Esto es constante, hasta que la transformación sea sostenible.
Finalmente, si dejas de preocuparte por el porcentaje de avance, por el número de historias de usuario que vas a recibir, por el tiempo que te va a tomar recibirlas y por quién es el responsable de hacer qué y cuándo, lo que te queda es atender el valor recibido y con qué calidad lo recibes.
Liderar o fomentar el cambio requiere que las personas enfrenten problemas dolorosos y renuncien a los hábitos y creencias que aprecian. ¿Resultado? Algunas de estas personas intentan eliminar el agente visible del cambio: ¡ese eres tú!
No te desanimes por ello. Aprende a manejar tu entorno y tus propias emociones. Por sobre todas las cosas, mantente fiel a tus principios.
Finalmente, muchos no esperan o no están preparados para hacer la inversión necesaria para cambiar. Un jefe seguirá queriendo ser el jefe, no un líder al servicio de nadie (léase Scrum Master). ¡Es la forma cómo los inspires lo que motivará una real y profunda transformación!

Fuentes:
1-  Why Change Programs Don’t Produce Change. By Michael Beer, Russell A. Eisenstat, and Bert Spector.

domingo, abril 01, 2018

Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio

4 estacions cicles arbre, por Espai Satvas

(Tiempo aproximado de lectura: 7 minutos, 15 segundos)
“Uno de los principales problemas con las Transformaciones Ágiles es que nosotros, las personas que hacemos estas transformaciones, no estamos realmente cambiando nuestros valores, nuestros corazones. Queremos practicar la Agilidad sin cambiar nosotros mismos. Eso nos impide hacer y liderar la Agilidad”. (Junio 7 de 2017)
Mike Beedle. En su honor…

El marco de trabajo Scrum y mucho menos el pensamiento Ágil o la Agilidad se venden en cajas o se prescriben como recetas en clínicas de coaching.
De allá venimos, de las propuestas de marcos metodológicos “mágicos” que, según sus promotores, funcionaban en cualquier lugar del universo, aun en una galaxia muy muy lejana, sin importar los escenarios locales, la idiosincrasia, la cultura organizacional o las personas involucradas.
Hoy por hoy las áreas de TI y las organizaciones en general saben que necesitan un cambio en su forma de trabajo y han escuchado poco o mucho del enfoque Ágil, este se ha vuelto un objeto del deseo, uno oscuro, pero no están dispuestas a generar el entorno que se requiere para cambiar. ¡Quieren empezar a jugar Rugby pero con las reglas del Fútbol!
El pensamiento Ágil es como un caleidoscopio para las personas, los equipos y las organizaciones del tercer milenio. Debido a la enorme cantidad de factores y al cambio continuado de contexto, dadas la volatilidad y la incertidumbre inherentes a las empresas actuales, una leve vibración del caleidoscopio genera una forma muy diferente a la anterior.
En cualquier caso, una imagen (modelo) apropiada para una organización puede no ser la correcta para otra, aun entre áreas de la misma empresa la estrategia y las tácticas pueden llegar a ser muy distintas. Cuánta agilidad necesita cada quien es una cuestión muy subjetiva que debe abordarse a nivel local.
La agilidad es la capacidad de evolución de las personas y de las compañías. Aquellas y estas deben estar conscientes de que, al igual que la evolución, el viaje de Agilidad no tiene un destino final, es un desplazamiento continuo, un éxodo perenne si así lo queremos ver.
Lo advertía hace siglos Nicolás Maquiavelo: nada más difícil de emprender ni más peligroso de conducir que tomar la iniciativa en la introducción de un nuevo orden de cosas, porque la innovación tropieza con la hostilidad de todos aquellos a quienes les sonrió la situación anterior y solo encuentra tibios defensores en quienes esperan beneficios de la nueva.
Es muy difícil que una persona cambie sus hábitos y mucho más complejo puede resultar si quiere cambiar su forma de pensar. Ni hablar entonces de lo caótico que puede resultar hacer esto para todo un equipo, por pequeño que este sea, y más aún para una organización entera.

Además, nuestro cerebro es muy bueno esgrimiendo argumentos de por qué no salir de su zona cómoda. El “siempre lo hemos hecho así” y otras razones corporativas para no cambiar.
Las organizaciones del siglo XXI quieren mejorar pero no quieren cambiar. Se mantienen en un estado de inmovilidad colmado de voluntades de cambio fingidas. A lo largo de mis años como agente de cambio me he encontrado con entidades cuyo propósito de renovación es simplemente un disfraz con el que ocultan su ánimo de permanecer estáticas en el tiempo. Lo que no saben estas compañías es que de no cambiar se exponen a su desaparición o al trágico rezago del que difícilmente podrán volver.
Para ninguno de nosotros es desconocido que la visión de la mayoría de las empresas es obsoleta en este siglo que apenas comienza. Las evidencias abundan: Blackberry, Xerox, Kodak, Nokia y Blockbuster, solo para mencionar algunas cercanas a nuestro sector. En general, el 88% de las compañías Fortune 500 de 1955 habían desaparecido de la lista o de la faz de la Tierra en 2014 (ver referencia). Lo que no están dispuestas a hacer estas corporaciones o no quieren hacer o simplemente no saben cómo, es cambiar su forma actual de trabajar, sus procesos y procedimientos. Por ejemplo, quieren medir el progreso de los cambios como miden sus proyectos tradicionales.
En general, este tipo de empresas no está interesado en sacrificar su “modus vivendi”. Las personas que pone a conducir la iniciativa de cambio no están allí exclusivamente para ello. Lo que ocurre casi siempre es que les asignan trabajo adicional al que ya realizan. Son personas que inician su nueva labor desmotivadas y cansadas, muchas veces sin entender del todo lo que está por suceder.
Lo que sí sabemos los agentes de cambio es que al iniciar una transformación no podemos ir contra ese “statu quo” de manera frontal o “guerrerista” como anuncian algunos, tratando de cambiar todo de una buena vez. Esto es así porque en un entorno complejo, altamente volátil y vulnerable, incierto y ambiguo, como el que rodea a las empresas hoy, no sabremos qué acciones conducirán al resultado deseado.
Primero tenemos que conocer la cultura organizacional, hacernos a una percepción de las personas, los escenarios, los equipos, su forma de trabajo vigente y una vez adentro iniciar la transformación de manera natural u orgánica, en pequeños pasos, sin violentar las estructuras o procedimientos actuales pero con paso firme y con determinación.
Curva de adopción/innovación de Rogers
Esta será útil para dispersar aquellas conductas que, inevitablemente, seguirán exhibiéndose hostiles incluso cuando el cambio se encuentre en un estado avanzado, esos comportamientos de los grupos de la mayoría tardía y de los rezagados identificados por nuestro amigo Everett Rogers en su muy referenciada curva de adopción/innovación.
Otra cosa que ocurre es que nuestras organizaciones están sobrecargadas de gestión y de gerentes en todos los niveles y siguen sin desarrollar su capacidad de ejercitar el liderazgo de sus miembros. Recordemos que los líderes de hoy son todas las personas que puedan transformar su contexto o generar nuevos y mejores espacios para los demás y cuya confianza, eficiencia y alcance combinados sirvan de base para la cultura de la organización.
Y bueno, mientras preparo más apuntes, cuéntanos amigo lector, sobre tus vicisitudes y rendimientos durante el proceso de cambio en el que estás comprometido. Puedes dejar tus propios apuntes en el foro, más abajo.
Coletilla de los apuntes:
Cada quien debe encontrar su significado de Valor y de Temprano y de Frecuente, para aquello de “entrega temprana y frecuente de valor”.
Lucho Salazar, Ciudad de los Reyes, marzo 30 de 2018
Referencias
http://www.aei.org/publication/fortune-500-firms-in-1955-vs-2014-89-are-gone-and-were-all-better-off-because-of-that-dynamic-creative-destruction/

jueves, febrero 01, 2018

Diferencias en el tratamiento de los requisitos entre los enfoques Cascada y Ágil


¡Una pregunta de un viejo amigo me llevó una vez más por este sendero!
Es un hecho. Muchos profesionales trabajan actualmente en circunstancias desafortunadas y, sin embargo, no toman la iniciativa de cambiar su situación porque están condicionados a un formato de seguridad, conformidad y conservación, donde todo puede parecer tranquilo pero, en realidad, nada es más perjudicial para el espíritu innovador y de transformación que requerimos hoy quienes vivimos en los tiempos del VUCA*.
En particular, durante la transición de un enfoque en cascada a uno Ágil tenemos que lidiar con la búsqueda de medios y maneras para acortar el tiempo de salida al mercado y entregar productos de alta calidad y de más valor, más temprano y más frecuente y, si es posible, a un costo menor. Sin embargo, el camino hacia la Agilidad puede ser escabroso, con baches riesgosos y con personas deambulando por allí erráticamente y hasta en dirección opuesta, incluso con temor a o sin saber cómo avanzar.
Y uno de los aspectos que empiezan a diferenciar en profundidad el uso de uno u otro enfoque es este de los requisitos. Abordamos este asunto con Carlos Gil, Johnny Ordoñez, Carlos Quiroga, Luis Mulato y el grandioso equipo de coaches del Scrum Coaching Retreat Cartagena y, como siempre, llegamos a algunas conclusiones que se mueven en el terreno de los principios y, más en el fondo, de los valores Ágiles, la cultura ágil, el Ágil es algo que eres:

  • En Ágil no hablamos de requisitos, más bien de respuestas a necesidades y, en otros casos, de hipótesis de cosas que queremos aprender. Cambiar el enfoque de “requisito” a “necesidad” o respuesta a necesidad, genera un sentido profundo de empatía entre todos los interesados, es decir, equipo de desarrollo de producto y usuarios o clientes finales.
  • A propósito de clientes finales, en Ágil, el cliente siempre es el centro de atención. Esto habilita a los equipos a buscar las mejores formas de suplir esa necesidad o de comprobar las hipótesis. Estas en últimas son necesidades de aprendizaje.
  • Creemos que esta es la distinción más grande entre las dos propuestas: el requisito te lleva a algo preestablecido, definitivo o definible claramente. Hablar de necesidades o de hipótesis abre la puesta al cambio.
  • En el enfoque Cascada se definen experiencias orientadas al proceso, con momentos de interacción preconcebidos por los formularios y procesos definidos en los requisitos, y aun hablamos de interacciones y no de conversaciones con las soluciones tecnológicas. En Ágil, aspectos como la experiencia de usuario, momentos de verdad, conversaciones, son esenciales para la definición de la historia de usuario que guía el desarrollo de producto.
Vamos con las disparidades entre uno y otro enfoque cuando de requisitos se trata
Son muchas las diferencias que existen en la forma de abordar los requisitos de un producto cuando usamos (o usábamos) la forma Cascada y lo que hacemos ahora, motivados por el pensamiento Ágil. Estas que describo a continuación son apenas algunas de ellas, algunas más relevantes que otras pero significativas todas al fin y al cabo.
Al principio del proyecto o del esfuerzo de desarrollo

En Cascada se toman o "levantan" (casi) la totalidad de los requisitos y de muchos de ellos se toma en gran detalle. En Ágil no. Se establece un alcance, sí, una visión, pero de muy alto nivel, muy horizontal, es decir, no se llega a ningún detalle excepto quizás para esas necesidades de los dos primeros Sprint (a lo sumo), la porción de producto que se va a construir durante las primeras de cambio. El llamado Mínimo (o Minimísimo) Producto Viable.
En Cascada nos tardamos semanas y hasta meses haciendo esta primera actividad. En Ágil nos tardamos unas pocas horas, a lo sumo unos pocos días, se establece un bloque de tiempo (time-box) y cuando este se acaba, se acaba.
En Cascada participa una persona del lado del equipo de desarrollo o un "subequipo", el o los analistas funcionales o de requisitos. Quizás en algún momento entra uno que otro rol, como el Arquitecto de Software. En cualquier caso, no participa todo el equipo. En Ágil participa todo el equipo de desarrollo desde el inicio, escuchando a los usuarios e interesados en el producto.
Más adelante, cuando el proyecto está en marcha
En Cascada se refinan los requisitos, hay ajustes, controles de cambios. El sobrevaluado CCC (léase Comité de Control de Cambios que se reúne el último jueves de cada mes, mientras el cliente ve impaciente cómo su competencia se adelanta y le quita parte del mercado. Mientras tanto, en Ágil se van refinando los requisitos iteración tras iteración. Siempre nos concentramos en lo que se va a construir en los siguientes 2 sprints o iteraciones, a lo sumo. Más tiempo no, porque las cosas pueden cambiar. Los equipos Ágiles aprovechamos los cambios para brindar ventaja competitiva a nuestros clientes.
En Cascada los requisitos siempre los "administra" una persona o un subequipo (analistas), con los usuarios. En Ágil hay un Dueño de Producto (representante de los usuarios), pero la responsabilidad es de todo el equipo.
En Cascada los requisitos se construyen, como sabemos, siguiendo un proceso secuencial donde ellos se tratan aparte y son una entrada al resto de ese proceso; además, el producto se entrega como un todo. En Ágil se construye un incremento del producto en cada iteración (de muy pocos días), esto es, producto probado y funcionando con valor, potencialmente desplegable y que genera retorno de la inversión (ROI) o, al menos, permite recibir retroalimentación, con lo que podemos aprender muchísimo del comportamiento y de la reacción de los usuarios al uso del producto.
En Cascada normalmente el orden de construcción lo decide el equipo de desarrollo (quizás en cabeza de un arquitecto o un subequipo). En Ágil el orden de construcción lo decide el usuario (dueño de producto), es él quien tiene la última palabra sobre esto.
En Cascada, el énfasis en cuanto a requisitos está en la especificación (documentación) de los mismos, en otras palabras, en escribir y escribir requisitos. En Ágil, el énfasis está en la conversación que tienen los usuarios o su representante (dueño de producto) con el equipo de desarrollo. Esta conversación es cara a cara y continua, durante todo el proyecto o esfuerzo de desarrollo.
Esta última característica es lo que nos empieza a volver ágiles, cuando lo logramos nos damos cuenta que estamos usando el pensamiento Ágil y estamos dejando atrás la cascada y otras formas tradicionales de trabajo.
En Cascada se espera que prácticas de aseguramiento de calidad permitan que se entregue un producto que cumpla con casos de prueba previamente definidos y aprobados con el área de negocio. En Ágil damos espacios a prácticas como TDD y BDD para guiar la definición de los criterios de aceptación, identificando de manera temprana la respuesta real que espera el usuario final, la prueba es guiada por la retroalimentación continua, lo cual mejora el uso y por lo tanto la aceptación del usuario.
Y sobre medios o herramientas para “recolectar” y administrar requisitos
Una diferencia en cuanto a los medios o mecanismos para "recolectar" requisitos:
En Cascada se usan medios como los documentos escritos tradicionales llenos de expresiones tipo "el sistema debe hacer esto" o "el sistema debe hacer aquello", o se usan mecanismos como casos de uso, entre otros. En cualquier caso, como mencioné antes, la fuerza está en elaborar grandes cantidades de documentación de requisitos. Escribí mucho sobre esto aquí en el Gazafatonario durante la década pasada y publiqué un libro al respecto. Lo pueden encontrar en Amazon.
En Ágil, por su parte, usamos medios o mecanismos que promuevan la conversación entre los interesados (usuarios y equipo de desarrollo). Las Historias de Usuario se han constituido en el medio esencial para esto. Pueden encontrar una especie de índice de mis artículos y propuestas y las de mi gran amigo Jorge Abad sobre este tema en bit.ly/lashistoriasdelucho.
Ahora sí, cuéntame en el foro de otras diferencias a la hora de recolectar y administrar requisitos o necesidades que consideres importantes.



*VUCA: siglas en inglés de Vulnerabilidad, Incertidumbre, Complejidad, Ambigüedad

miércoles, enero 17, 2018

Revisión a la Guía de Nexus 2018


Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.
Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.
Estos son los cambios más significativos:
1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.
2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.
3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.
4.    Claridad alrededor del rol del Equipo de Integración Nexus:
a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.
b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.
c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.
5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.
a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.
b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.
c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.
6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.
a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.
b.    Se eliminó de la Tabla de Contenido.
7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.
a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.
b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.
8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.
9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.
a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.
10. El Incremento Integrado representa el estado actual del trabajo integrado.
11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.
12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.
13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.
14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.
Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.
La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.
Para conocer más de Nexus, pueden leer mi artículo:
En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.