Buscar en Gazafatonario IT

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

jueves, enero 09, 2020

El último día del sprint

Imagen tomada de Pixabay
"Comenzar fuerte es bueno. Terminar fuerte es épico". [Robin Sharma]

Desde siempre he visto como los equipos de desarrollo de producto, especialmente los de desarrollo de software, emprenden los más titánicos proyectos con unas ganas inconmensurables, una fuerza interior, personal y grupal, que parece infinita y una pasión energizante que enciende los motores de la creación, el trabajo en equipo y los deseos de triunfar.

Nada muy distinto a lo que ocurre hoy en cada iteración de cualquier iniciativa o esfuerzo de desarrollo: el primer día los equipos planifican su propósito de vida para las siguientes jornadas y hasta son capaces de hacer un pronóstico de cómo alcanzarán la meta del sprint que comienza. Y diariamente acuden a la cita de la colaboración y la creación de valor con la mejor sonrisa y disposición.

O así es… ¡hasta que se acerca el fin de la iteración!

Un sprint es un bloque de tiempo breve en el que hay que mantener el foco y el esfuerzo regulado para terminarlo como lo empezamos. Con brío y pundonor. Pero eso no está ocurriendo con muchos equipos. En mis continuos ejercicios de acompañamiento y consultoría me sigo encontrando las historias de nunca acabar:
  • Es que no hicimos retrospectiva para terminar las historias de usuario
  • Programadores escribiendo programas minutos antes de la revisión con los interesados. ¿Y las pruebas?
  • Vamos a aplazar la revisión. Mañana hacemos la planificación del próximo sprint, luego la retrospectiva. Pasado mañana hacemos la revisión de este sprint que termina.
  • Solicitemos un aplazamiento del paso a producción para el próximo sprint.
  • Pidamos una extensión del sprint. Necesitamos dos o tres días más para terminar lo prometido.
  • Y la lista continúa.
Entre otras cosas, es a lo que se refieren Jeff y Ken cuando dicen que Scrum es “difícil de llegar a dominar”. Pero no se trata solo de Scrum. Es esa falta de disciplina que tenemos para hacer que las cosas terminen, ese apego a lo que es y no queremos dejar ir, inherente a todo ser humano. Es esa facilidad para conjugar el verbo empezar pero a la vez esa dificultad para conjugar la voz finalizar.

El último día del Sprint comienza el primer día del Sprint

Imagen tomada de Pixabay
Hagamos un plan hasta el penúltimo día del sprint, sea cual fuere su duración. Sí, con historias de usuario más pequeñas es posible. Y sí, todavía pueden ser entre 6 y 10 historias de usuario.

Recordemos en la planificación que la revisión y la retrospectiva requieren de preparación. No es algo que ocurre solo porque llegó la hora de hacerse o porque el marco de trabajo lo exige. Nunca veo esas tareas de preparación en el backlog del sprint. Y no, no son historias de usuario. Son actividades que bien pueden realizar el Scrum Master, pero también el Dueño de Producto o cualquier otro miembro del equipo, aunque preferiblemente uno de los dos primeros.

En cada reunión diaria, examinemos efectivamente cómo vamos hacia el cumplimiento de la meta del sprint y qué estamos haciendo específicamente para preparar esa gran fiesta que es la revisión del incremento con los interesados, no solo con el Dueño de Producto. Y, ni más faltaba, vayamos pensando qué clase de retrospectiva queremos hacer. Y sí, quince minutos es suficiente para ello. Durante la preparación de estos eventos finales también surgen impedimentos que hay que resolver con prontitud.

Recordemos, si no aseguramos la calidad del producto, no está terminado. Siempre pongamos de manifiesto que solo revisaremos lo que verdaderamente está terminado. Y no, casi terminado no es terminado.

El Scrum Master bien puede crear una campaña de expectativa hacia el exterior del equipo, dirigida a los interesados, sobre la próxima revisión, el siguiente gran hito. Y también hacia el interior del equipo: la siguiente gran oportunidad de inspección y adaptación, la retrospectiva. Sin que esto quiera decir que los demás eventos no son oportunidades de evaluación y ajuste, en el sentido de mejora continua.

Promovamos el descanso placentero y el sueño profundo, incluso la relajación y la meditación, la noche antes del día final del sprint. Descansemos, estemos con nuestras familias o amigos, salgamos a cenar, a disfrutar de una caminata a la luz de la luna con quien mejor nos sintamos o simplemente reposemos al ritmo que nuestro corazón dicte. Preparémonos así para la gestación de un día de buenas noticias con el resto del ecosistema organizacional.

Participemos de los preparativos, una revisión interna previa del producto no está demás. Lleguemos antes que todos los demás y recibamos a los invitados a la revisión, si los hay, con una gran sonrisa, con sendos mensajes de bienvenida, con una bebida. Y no, no es hora de licor.

[De la revisión propiamente dicha hemos hablado en variadas ocasiones así que no voy a entrar detalles sobre lo que debe o debería ocurrir durante la misma]*.

Aunque esto es del ámbito de la reunión misma, no dejemos de solicitar y recibir con la mente bien abierta toda la retroalimentación que nos brinden los asistentes. Ese será el motor que nos permita hacerlo mejor la siguiente vez. Y finalicemos con los agradecimientos respectivos, los aplausos, los abrazos, ¿por qué no? Después de todo, estamos todos en el desafío de deleitar a los consumidores finales de nuestro producto.

Finalmente, hagamos una pausa, tomemos un café y vamos a la retrospectiva. Esa cita íntima y necesaria en cada iteración. [Tampoco me extenderé mucho en este apartado]**

Al final del día, piensa que mañana seguirás mejorando. Es todo lo que necesitas para triunfar.


Apostilla:

No solo el último día, sino todos los días de tu vida, tiende la cama antes de salir. Si al final tienes un mal día o muchos malos días, siempre te recibirá una cama limpia y tendida. ¡Es la clave para cambiar el mundo!


-----
* Por ejemplo, además de lo que dice la guía de Scrum, mi gran amigo Jorge Abad ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:





Los invito a que los lean. Encontrarán consejos muy útiles cuando de preparar y realizar este evento del que les he hablado se trata.

** Por ejemplo, pueden leer mis artículos:




Aquí mismo en este Gazafatonario.


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/
*************************************************************
Parte 2 de los apuntes:
La segunda parte de esta serie de apuntes está en:
http://www.gazafatonarioit.com/2018/07/apuntes-sobre-transformaciones-agiles.html

Puedes descargar la presentación complementaria del siguiente enlace:

miércoles, octubre 26, 2016

Ecce homo o el Ágil es algo que eres

Ecce Homo restaurado de Cecilia Giménez
En el mundo moderno, las personas profesionales tienen una preocupación, con visos de ansiedad, vinculada a su ADN, sobre todo quienes trabajan en o alrededor de compañías de TI: ser competitivas, exhibir un alto desempeño y lograr metas en plazos cortos. Las actividades que realizan y los resultados, productos o servicios generados, deben ostentar estándares elevados de calidad. Este escenario sube el nivel de estrés de quienes lo intentan día a día, aunque también acentúa el grado de satisfacción cuando se alcanzan esos objetivos.
Es precisamente bajo esta atmósfera donde el enfoque ágil presume de sus incontables beneficios. El movimiento Ágil, que no es una metodología, nos permite encontrar y poner en práctica alternativas a la gestión tradicional de personas, proyectos y organizaciones. Esta perspectiva Ágil ayuda a los equipos a responder de manera oportuna a la poca o incierta predictibilidad a través de cadencias de trabajo incremental e iterativo y de la retroalimentación empírica.
Este modelo de desarrollo repetitivo o de ciclos de trabajo abreviados, también nos habilita a las personas y a los equipos para ser cada vez más expertos en cada uno de los aspectos de la construcción de productos. En el caso de la Ingeniería de  Software, hablamos de los requisitos, diseño, programación, pruebas, integración, etcétera. Pero este enfoque puede aplicarse en muchos otros entornos de producción y operación, una oportunidad que no teníamos con el modelo tradicionalista en Cascada, donde solo había una única  ocurrencia para hacer las cosas.
Esta evolución de la eficacia en el trabajo relacionada con proyectos de desarrollo sistémico es notoria y nos permite, a su vez, ofrecer una mayor garantía de calidad y de cumplimiento con las fechas límite, aunque surgen algunos efectos colaterales de la aplicación del modelo: nos volvemos menos predictivos (¡bueno, tampoco es que antes fuéramos altamente predictivos!), se acaba eso de culpar a alguien más si las cosas no salen bien y el hecho de que Ágil requiere mucho más compromiso y esfuerzo (¡aun a ritmo sostenido!) de todos los involucrados.

Ágil es algo que eres, las prácticas y los frameworks son algo que usas

Dentro de esos innumerables beneficios de la estrategia Ágil encontramos que las características más importantes del producto reciben la más alta prioridad y que incrementos funcionales del producto se entregan desde temprano y frecuentemente; además, las prácticas y marcos de trabajo livianos que acompañan el enfoque simplifican en grande el flujo de trabajo a la vez que solo se produce la documentación necesaria y suficiente para facilitar el control del producto por parte del usuario o cliente; por último, mi beneficio favorito de este conjunto, todo esto conduce a esa eficiencia y eficacia que mencionaba al principio, lo que a su vez confluye en equipos con personas altamente motivadas y felices que exhiben un alto desempeño, sin la carga de estrés impuesta por los métodos antiguos.
Cómo se logra esto es otro asunto pero son esenciales para ello la comunicación y la colaboración no solo entre los miembros del equipo sino con las personas del entorno, los interesados. También es importante que apliquemos la filosofía Ágil donde y cuando genere valor, aunque no se me ocurre en este momento un escenario donde esto no sea posible. No se trata solo de usar Scrum, Kanban o Lean, SAFe o Nexus, o de hacer retrospectivas por hacerlas, que apenas son artefactos y comportamientos visibles, esa porción de la cultura que nos permite hacer Ágil.
Se trata es de entender y practicar las formas de racionalizar y las estructuras cognitivas de elementos como la comunicación cara a cara, la simplicidad, el compromiso, las entregas incrementales de producto funcionando con valor, la calidad y la satisfacción del cliente, entre muchos otros; pero más en el fondo o en la base, este enfoque es acerca de cultivar y experimentar continuamente valores y creencias relacionados con las personas y sus interacciones, el coraje, el respeto, la inspección y la adaptación  permanentes, la transparencia, la respuesta a los cambios constantes y tantos otros elementos que constituyen eso que conocemos como Manifiesto Ágil, es esa otra porción de fondo de la cultura que nos permite Ser Ágil.

Ágil significa reemplazar la predictibilidad falsa por la eficiencia

Las organizaciones que han incorporado estos paradigmas ágiles, por su parte, entienden que las personas experimentadas, con amplias habilidades en la resolución de problemas y en el mejoramiento de procesos, son extremadamente valiosas para hacer realidad la visión organizacional. Estas compañías reconocen que el costo de desarrollar personas con estas habilidades es grande, especialmente si quieren involucrarlas y comprometerlas en la mejora continua de procesos. Por eso no solo les proporcionan las herramientas y los recursos necesarios para entrenarse continuamente sino que también disponen de agentes de cambio que los ayudan a potenciar sus destrezas.
De esta manera es que hemos abierto nuestras mentes para enfocarnos en las personas y nuestras interacciones con ellas y cómo colaboramos con nuestros clientes y en cómo pensamos acerca de nuestro trabajo y en tácticas que nos descubran el camino hacia la superación perpetua. Nos concierne y nos motiva enfrentar los cambios, nos interesa ser la estrategia, no simplemente apoyarla, somos líderes por naturaleza, pero líderes con el poder de influenciar a otros, no de gobernarlos, nos gusta animar a los demás a que compartan nuestra visión y compartimos la de ellos, no miramos al pasado sino para aprender  y nos hacemos cargo del futuro.
Las reglas del juego cambiaron, ¿te diste cuenta? Déjamelo saber en el foro.
---
Más sobre Filosofía Ágil en:

miércoles, octubre 12, 2016

Dueño de Producto, usted ha sido invitado a la Retrospectiva

El Dueño de Producto, ¡ese ilustre olvidado!
Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.
No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:
"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".
Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.
Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.
Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.
  • ¿Y qué pasa si hay problemas con la salud del backlog? 
  • Problemas con la definición de los criterios de aceptación de las historias de usuario.
  • ¿El equipo conoce cómo los usuarios realmente usan el producto?
  • Problemas con la aceptación del incremento sprint tras sprint.
  • ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
  • ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.
En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.
Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:
Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.
El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.
No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!
Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (que si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.
Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.
Entre otras, pero todas absolutamente son "malas" razones.
En definitiva, el Dueño de Producto debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas.
---
¿Y tú, invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en la sección de comentarios más abajo.

miércoles, junio 01, 2016

Los Pilares de Scrum

Los Pilares de Scrum. Clic en la imagen para ampliar.

Sin ninguna duda, para que Scrum sea eficiente y efectivo, cada uno de estos pilares debe estar en pie, deben promoverse desde las personas y los equipos hasta toda la organización y deben apoyarse sin restricciones. Sin uno o más de estos pilares, cualquier implementación de Scrum está condenada a un cataclismo anunciado.

Déjame saber en el foro como te ha ido con la puesta en macha de estos pilares mientras implementas Scrum en tu organización.

Puedes descargar el PDF de la imagen en alta resolución haciendo clic aquí.

O me la solicitas a mi correo: lucho.salazar@gmail.com.