Buscar en Gazafatonario IT

lunes, abril 06, 2020

Diez comportamientos atípicos en Ágil y Scrum

Escucha el audio de este artículo aquí:
De valores y principios

La agilidad es una capacidad de las personas, los equipos que forman esas personas y las organizaciones que cobijan esos equipos, de crear Valor y de responder eficiente y efectivamente al cambio para tener éxito en un entorno lleno de incertidumbre, pero también de ambigüedad, altamente complejo y volátil.


El pensamiento y el comportamiento ágil se funda en lo que conocemos como el Manifiesto Ágil, que enuncia cuatro valores, que conducen nuestro comportamiento de agilistas, intrínsecos a nuestra forma de pensar y de interpretar el mundo que nos rodea, de alguna manera subjetivos, emocionales y hasta debatibles. Pero valores al fin y al cabo.  Los valores ágiles son importantes para nosotros y los practicamos incluso de manera inconsciente, sin ningún esfuerzo. Estos valores se complementan con doce principios, extrínsecos o manifiestos que nos ayudan a hacer objetivos los valores, a hacerlos más concretos, incluso impersonales y a poner esos valores en evidencia. Los principios ágiles son indiscutibles. Los valores ágiles se basan en los principios.

A su vez, marcos de trabajo como Scrum nos señalan el camino de cómo poner en práctica esos valores y principios. Por ejemplo: “hemos aprendido a valorar la respuesta ante el cambio sobre el seguir un plan”. Un principio ágil nos dice que “Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. Otro nos dice que “A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia”. Más adelante, Scrum nos enseña a trabajar en períodos cortos de tiempo, llamados Sprints, y a tener un backlog de producto que está cambiando todo el tiempo. Y además nos proporciona distintas oportunidades de hacer inspección y adaptación, al producto, al proceso y a las personas, en los distintos eventos que propone el marco de trabajo.

Incluso el mismo Scrum no está desprovisto de espíritu. Los cinco valores de Scrum no son solo un complemento a los valores ágiles, como que “los miembros del Equipo Scrum se respetan entre sí para ser personas capaces e independientes”, que es más de “personas e  interacciones”, sino que también nos sirven de guía de comportamiento Sprint tras Sprint.


Los comportamientos atípicos

Sin embargo, es muy común encontrar personas y equipos cuyo comportamiento ágil deja mucho que desear. No solo dentro de las empresas, sino también en las comunidades ágiles, al menos por este lado del planeta. Por ejemplo, en los foros de las comunidades, cuando se trata de preguntas o de solicitudes de ayuda de personas, he notado algunos patrones, algunos comportamientos sobre los que invito a reflexionar y, de ser necesario o de efectivamente encontrarlos hostiles, a mejorar. He encontrado:

1.    Respuestas que denotan intolerancia. Intemperancia con quien no conoce de algo en particular. Esto malogra el efecto de la comunicación. De hecho, con este mensaje corro el riesgo de que me tachen de intolerante.

2.    Respuestas "automáticas", de esas que se repiten en muchos de los foros de los grupos, la misma respuesta a muchas preguntas, sin considerar el contexto de cada una. Como si se tratara de una receta única y prescriptiva a “todos los males” de la humanidad.

3.    Respuestas “a la ligera”, sin detenerse a revisar el paradigma actual del solicitante. No porque estemos en una o cual comunidad ágil, ya tenemos claro lo que significa el pensamiento ágil, ser ágil o la agilidad.

4.    Respuestas escuetas o cortantes que muchas veces no brindan ninguna solución a la cuestión. Al menos, no una solución proclive a responder la inmediata necesidad de quien pregunta.

5.    Respuestas erróneas o, al menos, inexactas o carentes de precisión.

Imagen de Gerd Altmann en Pixabay
En este sentido, siempre que tengo la oportunidad, sugiero a los participantes de los foros:

·       Leer nuevamente la pregunta o solicitud.

·       Detenerse un poco a pensar en la respuesta antes de enviarla.

·       Solicitar contexto a quien pregunta. Estamos actuando como si hubiera una receta prescriptiva para todo y nos olvidamos de que los escenarios son distintos, los de ellos, los de aquellos, los nuestros y los tuyos. Estamos en un mundo VICA (VUCA). “Tu escenario es diferente al mío”.

·       Ser más respetuosos no solo con quien nos interpela, sino con el resto de tertulios.

·       Liderar con el ejemplo.

·       Finalmente, hagamos de nuestras comunidades unas a las que sea un privilegio pertenecer. Los valores Scrum nos ayudan mucho a ello. Acordemos estar abiertos a todo y a los desafíos que se nos presenten al participar en los grupos y comunidades ágiles.

“Malos” comportamientos Scrum

Imagen de Kate Baucherel en Pixabay
En particular, cuando se trata de usar Scrum para sacar adelante proyectos o esfuerzos de desarrollo de productos o servicios, he encontrado:

6.    Las ganas de hacer la Planificación del Sprint rápida o muy rápida. Con la excusa de que hacen un buen refinamiento. ¿Seguros? ¿Cuántos Sprints adelante? Son infinitas las planificaciones Scrum que terminan sin un trabajo planificado por el Equipo de Desarrollo para los primeros días del Sprint, descompuesto en unidades de un día o menos, y sin “una proyección de lo que (el equipo) cree que puede completar en el Sprint que comienza”. Tampoco incluyen una Meta de Sprint que les de visión y les motive a autoorganizarse y les proporcione una razón de reflexión diaria sobre si se están acercando o no a esa meta. Recordemos además que “Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”. Sobre todos estos asuntos escribí hace ya algún tiempo: Planificación del Sprint: el primer paso para producir el máximo efecto. Clic aquí.

7.    Mantener al Dueño de Producto alejado del resto del equipo Scrum. ¿Dónde quedó aquello de que “los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto”? En particular, sobre la ausencia del Dueño de Producto en la retrospectiva, escribí: Dueño de Producto, usted ha sido invitado a la Retrospectiva. Clic aquí. Tenemos que ayudar a que el Dueño de Producto se enamore de su rol, todos, Scrum Masters, coaches ágiles y similares y Equipo de Desarrollo.

8.    El síndrome del bravucón. Los seres humanos tenemos la naturaleza de “ir por más”, de querer hacer más. Con buenas intenciones. O, al menos, partimos de ahí. Y si tenemos autoestima elevada, nos fijamos metas cada vez más elevadas. Pasa, por ejemplo, con las estimaciones. Durante la planificación del Sprint. El problema radica en que muchas veces no hemos cumplido la promesa o lo que planificamos en los últimos tres o cuatro Sprints y en el que comienza no solo queremos seguir insistiendo en que esta vez sí lo lograremos sino que prometemos hacer más, mucho más. A veces esto da resultado en el plazo inmediato. Pero a la larga, es algo insostenible. Y cuando de nuestro trabajo depende mucha gente, incluso una organización entera o más, miles o millones de consumidores, no es bueno incumplir. Eso desanima no solo al propio equipo, a la empresa sino también a los usuarios finales del producto o servicio. Para la solución a este síndrome escribí sobre el muy conocido patrón de Scrum “El clima de ayer” en: El clima de ayer, o el arte de prever lo que sucederá hoy. Clic aquí.

9.    La adicción a las herramientas. Cuando venimos del paradigma tradicional no tiene nada de malo si nos aferramos a lo que conocemos. Pero cuando el tiempo pasa y seguimos anclados a esa antigua formula de trabajo, es que nos falta incorporar parte o toda esa nueva forma de pensar y de hacer las cosas: nos hace falta agilidad. Esa búsqueda continua de instrumentos automatizados para hacer esto y aquello. Ese deseo incontrolable de tener control sobre el proceso, sobre el producto y sobre las personas mediante el registro de su trabajo en herramientas de todo tipo. Las conversaciones se vuelven discusiones eternas sobre evaluación de proveedores, precio de licencias, RFP ininteligibles, licitaciones y presentaciones sin valor para la empresa. ¿Y de aquello? Sí, de aquello, del producto probado y funcionando, útil, de valor para la organización y para sus clientes. De eso nada. Allí es cuando necesitamos trabajar más en formas de interacción entre personas y valorar más esto que a esas herramientas y a los procesos. Scrum, por su parte, nos provee de ricos momentos para interactuar, cinco eventos más uno, sí, el refinamiento. Literalmente, todos los días podemos tener conversaciones cara a cara, que se han convertido en “el método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros”. Escribí sobre este asunto en: La Conversación Cara a Cara en Tiempos de la Comunicación Digital. Clic aquí.

10. La falta de espíritu. En la introducción a este artículo les dije que Scrum no carece de espíritu. De hecho el Espíritu del Juego es el patrón Scrum que nos proporciona el contexto, el entorno que necesitamos para ejecutar cualquier otro patrón: se trata del marco de trabajo mismo, Scrum. A veces es útil pensar en Scrum como un juego. Cuando usemos Scrum, el equipo de desarrollo de producto, no solo el Scrum Master ni mucho menos el Dueño de Producto, debe enfocarse en crear una cultura donde la personas conozcan, interioricen, practiquen y promuevan el espíritu de Scrum. Todos en el equipo Scrum y quienes trabajamos con ellos debemos ayudar a instanciar esa cultura y a que esta evolucione liderando con el ejemplo. Sobre esto, hemos aprendido a promover y a premiar comportamientos que consideremos apropiados o “correctos” para la cultura que queremos, y a desanimar y castigar otros comportamientos que creemos inapropiados o “erróneos”. En el largo plazo, esto da como resultado que una nueva cultura emerja: la cultura Scrum, la cultura ágil. Sobre esto último escribí hace muchos años: Cultura Ágil, ese oscuro objeto del deseo. Clic aquí. Además de muchos otros artículos en este mismo Gazafatonario. Y sobre Scrum, con mi gran amigo Jorge Abad estamos en el proceso final de edición de nuestro libro Scrum: epítome de una década de experiencias, que reúne mucha de nuestra propia experiencia lidiando con estos comportamientos atípicos y con muchos otros. Clic aquí.


La lista de comportamientos extraños o irregulares puede ser infinita. Pero es definitivo, “para crear la cultura debes ser la cultura”. Déjame saber en el foro qué piensas de todo esto y qué otros comportamientos insólitos o anómalos has encontrado en tu camino ágil.


jueves, marzo 26, 2020

Aprende Scrum con Lucho Salazar

Clase en línea gratis
Aprende Scrum con Lucho Salazar

Scrum es un marco de trabajo liviano e iterativo que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente.
Ven a esta clase en línea y aprende un poco más sobre el marco de trabajo Scrum para poder aplicarlo mejor en tu entorno de trabajo.
Esta es una primera clase introductoria de una serie de clases, totalmente gratuitas para los participantes.

Lucho es Agile Coach, Consultor, Facilitador en marcos de trabajo y prácticas ágiles. Coautor del libro Historias de usuario: una visión pragmática. Autor de los libros "Asuntos de la Ingeniería de Software", Volumen I y Volumen II. Creador del User Story Conversation Canvas, un lienzo para conversar sobre historias de usuario. Creador del Agile Triangle Extended, un enfoque integral ágil para la gestión de proyectos, equipos y personas. Coautor del libro Scrum: epítome de una década de experiencias, que será publicado en abril de 2020. Traductor al español de la guía oficial de Scrum y de la Guía de Nexus de Ken Schwaber.
Me he dedicado a habilitar entornos más productivos para equipos de proyectos y esfuerzos de desarrollo de productos. Como Agile Coach mi foco es llevar a los equipos a pensar en Mejoramiento Continuo a la vez que interactúen como un sistema complejo que les permita entregar frecuentemente productos de valor para el negocio mientras se divierten haciéndolo.
Regístrate totalmente gratis en:
https://www.eventbrite.com/e/aprende-scrum-con-lucho-salazar-tickets-101247086762
¡Cupos limitados!

Clase 1 - 2020-03-31
Enlace al documento de la clase:

Puedes descargar la presentación de la clase 1 del 2020-03-31 aquí.




Puedes ver el video de la clase 1 del 2020-03-31 aquí.




Clase 2 - 2020-04-03
Enlace al documento de la clase:

Puedes descargar la presentación de la clase 2 del 2020-04-03 aquí.





Puedes ver el video de la clase 2 del 2020-04-03 aquí.


martes, marzo 24, 2020

[Web] La delegación en tiempos del covid-19


Imagen de Gerd Altmann en Pixabay 

Son tiempos difíciles. Estamos atravesando una crisis sin precedentes en la humanidad. Con asombrosa rapidez, hemos tenido que adaptarnos a un entorno que no imaginábamos posible hace apenas algunas semanas.

Afortunadamente, para quienes hemos navegado en la incertidumbre y la volatilidad, estos escenarios no son del todo novedosos. Hemos insistido hasta la saciedad en la última década que debemos practicar y promover la adaptación a los cambios. Sabemos que la vida, como la conocemos, es capaz de transformar hábitats de una perfección inescrutable, en ambientes aún más complejos y virtuosos.

Los cambios están ocurriendo por doquier, sin parar y sin que haya un comando y control superior para dar órdenes y, para ello, en las organizaciones hemos puesto de manifiesto la necesidad de delegar. Y los tiempos actuales requieren de medidas actuales. El trabajo remoto, cuya necesidad es a todas luces evidente, demanda un alto nivel de confianza y de empoderamiento en las personas.

El objetivo es lograr que nos ocupemos de todas las tareas habituales sin supervisión, que se establezca una meta, una dirección y se fijen prioridades, se analicen los problemas, se hagan planes, se ejecuten y se tomen decisiones difíciles. Todo sin la mirada del Gran Hermano sobre nosotros. Se trata de que las personas y los equipos sean efectivamente autónomos y autoorganizados.

¿Cómo lograrlo? En esta sesión hablaremos de ello, delegación y empoderamiento, cómo no controlar mientras nos cuidamos de una pandemia para sobrevivir en este universo pletórico de ambigüedades y complejidades, niveles de delegación y qué tiene que ver la confianza en todo esto. Se trata de hacerlo gradual aunque hoy no tenemos mucho tiempo, pero es posible pensar en delegar una gran tarea mientras nos tomamos treinta segundos para lavar bien nuestras manos y cuidarnos de la enfermedad.

¡Los esperamos!





Pueden descargar la presentación aquí.




Puedes ver el video de esta presentación, facilitada para la Tribu Ágil de Perú el 17 de abril de 2020:

lunes, marzo 16, 2020

El clima de ayer, o el arte de prever lo que sucederá hoy

Imagen de truthseeker08 en Pixabay

La velocidad de los equipos es algo que nos preocupa desde siempre, sobre todo para quienes venimos de paradigmas tradicionales y formas convenciones de medir el rendimiento de las personas y de los equipos. ¿Cómo la calculamos? ¿Cuánto tardamos en conocerla? ¿Cómo sabemos si esa es la velocidad real del equipo? Son algunas preguntas que surgen en conversaciones en las organizaciones que empiezan a usar Scrum y la forma ágil de hacer las cosas.

¡La desconfianza impera en el ambiente! Se trata de ese temor a lo desconocido, a perder el control de las cosas, natural por demás en nuestro ADN humano. Pero ya basta.

Hemos aprendido que ya no es tan importante saber cuántos Sprints vamos a tardar para conocer más o menos la velocidad del equipo. Como siempre, empezamos con un estimado, con lo que creemos que el equipo puede lograr cuando inicia “labores” ágiles y vamos afinando. El juicio de un experto viene bien; o un cálculo matemático basado en la capacidad del equipo, o la propia experiencia previa del equipo si este ya viene trabajando como tal.

Para ello, usamos un patrón que llamamos “El clima de ayer”, Yesterday’s Weather en inglés. El clima de ayer es un concepto que heredamos de eXtreme Programming (XP) y que usamos para sortear esa determinación a veces excesiva que tienen los equipos para comprometerse en exceso durante los Sprints y que hemos acogido muy bien en Scrum. Nos recuerda que un buen predictor del futuro es lo que hemos hecho en el pasado reciente.

El nombre proviene del hecho de que la mejor forma de pronosticar el clima de hoy es precisamente el clima de ayer. En la mayoría de los casos, el número de Puntos completados en el último Sprint es el vaticinador más confiable de cuántos Puntos se completarán en el Sprint que comienza.

En síntesis, el clima de ayer es un patrón Scrum que ayuda a los equipos a calcular o a determinar rápidamente cuántos puntos probablemente se terminarán en el Sprint por iniciar. Si hiciste 35 puntos este Sprint, sea cual fuere la escala que estés usando para medir, ¿cuánto es lo más probable que hagas en el nuevo Sprint? ¿49? ¿37? ¿23? ¡Yo creo que 35!

Recomendación: es importante tener cautela y no dejarse llevar por nuestra propia naturaleza humana, esa que nos acusa a las personas y a los equipos con alta autoestima de establecer metas cada vez más altas para sí mismos.

Imagen de StockSnap en Pixabay
Este Sprint hicimos 29, en el nuevo podemos hacer un 10% o un 20% más o más aun, porque hemos aprendido, porque sabemos más, porque somos muy buenos, porque el trabajo en casa rinde más y un sinnúmero de razones por las que siempre intentamos hacer más. Incluso llevamos muchos Sprints sin atinarle a lo prometido y en vez de bajar seguimos subiendo, porque ahora sí, porque la quinta es la vencida, porque ya le “cogimos el tiro al vaina”*, porque ya sabemos cómo es, porque ya nos certificamos en historias de usuario, porque ya leímos el libro de Jorge y Lucho y otro largo etcétera.

¡No hay que caer en eso! Andemos con cuidado por este mar de turbulencias. El clima de ayer es la mejor forma de predecir lo que va a pasar hoy.

Quizás puedes ir hasta tres Sprint más atrás, sí. Hay que experimentar. ¿Pero más de allí? Es que hace 24 Sprints hicimos 54 puntos y desde entonces no subimos de 31, ¡vamos con 55 esta vez! Este año sí. Bueno, no.

Así que mi punto es: ya no se trata de "estabilizar" la velocidad del equipo. La experiencia nos ha demostrado que, aunque posible, estamos en un mundo VICA (VUCA en inglés). Anoche (hoy es 16 de marzo de 2020, en plena crisis mundial por el COVID-19), antes de las 8 de la noche en Perú, ningún equipo Scrum sabía que hoy no iría a trabajar a sus oficinas. ¿Sirve la estabilidad en la velocidad? Creo que no. Toca empezar. Empecemos con el clima de ayer.

Miremos la velocidad que teníamos el viernes y vamos estudiando cómo se dan las cosas para los siguientes Sprints.

Incluso tengamos en cuenta la capacidad del equipo, si sale alguien, si alguien no estará durante algunas horas o días, si alguien se va de vacaciones o se va de luna de miel.

Finalmente, se trata de empirismo, no de prescribir una receta, allí es donde un patrón como este juega un papel importante, ¡aprendamos de la experiencia!
“El conocimiento previo no se puede obtener de fantasmas y espíritus, no se puede obtener por analogía, no se puede descubrir por cálculo. Debe obtenerse de personas, personas que conocen las condiciones del enemigo".
- Sun Tzu, El arte de la guerra

Nota:
* “Coger el tiro a la vaina” en Colombia significa “descubrir o aprender la manera de hacer algo bien”.

Para conocer más sobre el patrón El clima de ayer, pueden ir a:

viernes, marzo 13, 2020

Sobre el Incremento de Producto y el Refinamiento

Imagen de mohamed Hassan en Pixabay
Llegan algunas preguntas de colegas a mi buzón:

En el review:

¿A quién se le hace la entrega el incremento?

¿Este incremento debe ponerse en producción antes o después del review? (Si es antes, ¿qué pasa si el PO no lo avala o si es después, sería una tarea del siguiente Sprint?)

En el refinamiento:

¿En qué momento se contextualiza al equipo de trabajo sobre una funcionalidad o cambio sobre las funcionalidades pactadas? Es que entiendo que el refinamiento puede ser en cualquier momento entre todo el equipo.

¿Debería existir un día en el Sprint para refinar? ¿Eso no distrae al equipo de desarrollo?

Veamos algunas ideas al respecto:

Sobre la entrega del incremento

En la Revisión del Sprint se presenta el incremento del producto funcionando. El responsable de entregar este  incremento de Valor es el Equipo Scrum en pleno. ¿A quiénes se hace la entrega? A un grupo de interesados en el producto: patrocinadores, usuarios finales o consumidores, jefes, alta gerencia, personas de mercadeo y ventas, publicidad, operaciones u otras áreas que tengan que ver con el producto, entre otros. Tampoco se trata de una reunión “amplia” con mucha gente, se trata de algunos “interesados clave” invitados por el Dueño de Producto.

Esta es una reunión informal, no de seguimiento. El Dueño de Producto ya debe tener conocimiento previo de lo que se va a entregar, de su estado (solo se entrega producto terminado), de la calidad, etcétera. Después de todo, se supone que el Dueño de Producto está trabajando con el equipo de Producto de manera cotidiana. 

Dos aspectos clave de la reunión son que:

  • El Dueño de Producto explica qué elementos del backlog de Producto se han “Terminado” y cuales no se han “Terminado”; y
  • El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;

Pero la reunión va más allá. Es en este momento cuando siempre sugiero volver a leer la guía de Scrum.

Además de lo que dice la guía de Scrum, Jorge ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Sobre el incremento

Imagen de Gerd Altmann en Pixabay
El incremento debe estar probado y funcionando, es decir, debe ser potencialmente distribuible, que se pueda poner en producción. Este incremento cumple la Definición de “Terminado” del Equipo Scrum. Debe representar en buena medida la meta del sprint. En la práctica, no concibo un Incremento de Valor que no aporte en un altísimo porcentaje hacia el cumplimiento del objetivo del Sprint.

Normalmente el incremento se pone en producción después de la Revisión. Es posible que sea antes pero es algo difícil en los entornos actuales. Este asunto de la puesta en producción tiene su propia complejidad porque, si no estamos en un entorno con cultura DevOps, donde haya automatización y herramientas, el incremento quizás se tenga que entregar a un equipo externo y este, a su vez, deberá pasar por uno o más comités de "Paso a Producción", entre otras restricciones y, las cosas así, el paso final puede tardar desde algunas horas, hasta algunos días o semanas. En cualquier caso, es el Dueño de Producto quien autoriza el paso, al menos por el lado del producto. Ya los demás comités y áreas harán lo suyo.

Importante: el objetivo del Equipo Scrum es entregar un incremento de producto en cada Sprint. Que tenga valor para el negocio, los usuarios o consumidores. Es decir, que genere retorno de la inversión, que haga ganar más dinero, que minimice costos, que mejore procesos, que evite más costo de la demora innecesario, entre otros aspectos. Si tu equipo no lo está logrando, es tiempo de una retrospectiva cuyo foco sea precisamente este de la no entrega de valor.

Sobre el refinamiento

Imagen de Gerd Altmann en Pixabay 
La contextualización sobre una funcionalidad o cambio en las funcionalidades pactadas se hace, precisamente, durante el refinamiento. Es el mejor momento.

El refinamiento es una tarea diaria del Dueño de Producto, con su equipo de producto, con los usuarios, con los interesados, con los consumidores finales, etcétera. Y, de tanto en tanto, durante el Sprint, se reúne con el equipo para contarles sobre las funcionalidades que vienen en los dos siguientes Sprints. 

Scrum nos sugiere que podemos usar hasta un 10% del tiempo del sprint para el refinamiento. Pero el equipo debe o debería estar completo con el Dueño de Producto a bordo. Para que todos vayan con el mismo conocimiento a las siguientes planificaciones y refinamientos. 

Sobre cuándo hacer el refinamiento

Se puede seleccionar un día del sprint o dos, dependiendo de la duración del mismo. Por ejemplo, sesiones de 2 horas o de 4 horas máximo vienen bien. Se recomienda que sean a mediados del sprint, nunca al principio y mucho menos al final. De hecho, el equipo puede tomar este tiempo como un "respiro" de sus tareas más complejas de desarrollo, así que puede ser beneficioso. Lo que no puede suceder es que se hagan tres o más reuniones de refinamiento en el sprint, que sean breves, eso no. Aunque es cuestión de experimentar, no creo que este último sea el camino, eso sí puede distraer al equipo, puede hacer que pierdan el foco continuamente, en fin, veo algunas desventajas en hacerlo así. Una o dos sesiones máximo.

Más sobre refinamiento en:

Purga ágil de producto
http://www.gazafatonarioit.com/2016/06/purga-agil-de-producto.html

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto
http://www.gazafatonarioit.com/2017/06/sobre-el-backlog-de-producto-el.html

En este mismo Gazafatonario.

lunes, marzo 09, 2020

El imposible y desatinado caso de SCRUMStudy®

Imagen de Sophie Janotta en Pixabay
Una colega lanzó esta pregunta en una comunidad de Scrum Masters:
Que tal grupo, […],
Duda: (corríjanme si estoy mal, por favor)
Entre las diferentes compañías tales como SCRUMstudy®, Scrum Alliance, Scrum.org, etc.
En cuestión a la teoría que imparten todas las diferentes compañías/empresas ¿existe alguna diferencia entre el contenido que imparten para enseñar a sus receptores Scrum? o ¿Todas las compañías en cuestión a teoría enseñan lo mismo pero te certifican según la compañía en la que tomaste la capacitación o curso?
[…]
Saludos.
[Texto copiado con permiso de su autora]

Recordé que hace ya algún tiempo estuve involucrado en otro foro sobre la muchas veces discutida pregunta “¿dónde me certifico?”. Mis ideas de entonces quedaron registradas en:

Pero esta nueva pregunta iba más allá. Hablaba de la teoría. Y lo que más me llamó la atención fueron las respuestas iniciales de otros foristas quienes, de alguna manera, no diferenciaban en el tratamiento de Scrum que hace el así llamado SBOK® y la guía oficial de Scrum, escrita por sus creadores.
Como es un tema escabroso, de esos que elevan las pasiones, lo pensé mucho antes de involucrarme. Finalmente, pudo más la responsabilidad que tengo con el “hacer bien las cosas”, el compromiso que tengo con el mejoramiento del uso de Scrum por parte de las personas, equipos y organizaciones a mi alrededor. Así que esta fue mi respuesta:

Imagen de David Mark en Pixabay
A ver si trato de explicar esto con una analogía:

Aunque la FIFA no inventó el Fútbol, es hoy el organismo que “rige” los estándares, que regula, que establece las “reglas” de ese deporte. A pesar de ello, es posible jugar al fútbol con variantes y no “pasa nada”: fútbol playa, fútbol 5, fútbol 7, fútbol sin porterías, etcétera. Cada una de estas otras versiones tiene distintas reglas, creadas o inventadas por nosotros mismos, las personas, o por algún organismo distinto a la FIFA. Hay menos jugadores en algunos, hay variaciones en las reglas, en fin. Pero en definitiva, el Fútbol como tal, el deporte del balón, el universal, es el de la FIFA.

Así ocurre con Scrum. Este marco de trabajo fue creado por Jeff Sutherland y Ken Schwaber y fueron ellos quienes escribieron originalmente lo que hoy se conoce como la guía de Scrum. El primer documento lo presentaron al mundo en 1995. Puedes encontrar más de los orígenes de Scrum en:


Ahora bien, son Jeff Sutherland y Ken Schwaber quienes siguen actualizando y manteniendo la guía (la teoría) de Scrum de tanto en tanto. Ellos reciben la retroalimentación de la comunidad pero finalmente ellos son sus creadores y, por decirlo de alguna manera, sus guardianes. Aunque bien todos nosotros deberíamos ser custodios de esa guía oficial también.

Después de Scrum llegaron organizaciones como la Scrum Alliance, creada precisamente para fomentar el uso del framework. Ellos crearon algunas certificaciones asociadas: Scrum Master, Product Owner y Scrum Developer. Y basaron sus cursos y certificaciones en la guía de Scrum escrita por Sutherland y Schwaber.

Más tarde aparecieron empresas como Scrum.org de Ken Schwaber y Scrum Inc., de Jeff Sutherland.

Y luego otras empresas certificadoras. Incluyendo SCRUMStudy®. Casi todas estas últimas empresas certificadoras de Scrum son independientes, de terceros, pero basan sus certificaciones en la guía de Scrum escrita por Sutherland y Schwaber, la guía oficial.

Casi todas, excepto SCRUMStudy®, que basa sus entrenamientos (teoría) y exámenes de certificación en un libro que ellos llaman Scrum Body of Knowledge (SBOK®). Un libro de más de 400 páginas la última vez que lo consulté. Mientras que la guía oficial solo tiene unas 18 páginas en español.
Imagen de LhcCoutinho en Pixabay
Este SBOK® es como esas otras versiones de Fútbol de las que te hablé al comienzo. Tiene otras reglas, muy diferentes a las que tiene la guía de Sutherland y Schwaber, los creadores de Scrum.  Imagina las diferencias nada más en número de páginas. De 18 a más de 400. Pero quisiera poner tres ejemplos de las disparidades que presenta la una versus la otra:
  1. Roles propuestos: en Scrum “oficial” (en la guía de Sutherland y Schwaber, la de 18 páginas), los tres roles propuestos son: Dueño de Producto, Scrum Master y Equipo de Desarrollo. Solo tres y nada más que tres. Estos tres roles forman lo que conocemos como Equipo Scrum. Mientras tanto en el SBOK® se proponen 2 tipos de roles: Roles Core y Roles Non-core. A los primeros pertenecen los tres roles de la guía oficial aunque con una discrepancia: el equipo de desarrollo se llama Equipo Scrum. En la guía oficial, como dije antes, este Equipo está compuesto por los tres roles. Aquí no. Y los roles non-core son Stakeholders (dentro de los cuales cuentas Customer, Usuarios y Patrocinador), Vendedores y Cuerpo de asesoramiento de Scrum. En definitiva, son reglas distintas.
  2. En la guía oficial de Scrum, el tamaño del equipo de desarrollo va de 3 a 9 personas. En la sección 3.6.2 (Tamaño del Equipo Scrum), el SBOK® dice que “El tamaño óptimo de un Equipo Scrum es de seis a diez miembros”. Otra vez, una regla disímil.
  3. En la guía oficial de Scrum, la duración máxima del Sprint es de un mes. Mientras que en la sección 2.7.1 (Scrum Time-boxes), el SBOK® dice que “Un Sprint es una iteración Time-boxed de una a seis semanas de duración”. Otra disparidad.

Y así podemos encontrar muchas. De 18 a más de 400 páginas. Simplemente son reglas desiguales, algunas muy opuestas. El SBOK® No es Scrum.

Con esto solo estoy tratando de señalar que la guía de Scrum, la cual puedes descargar de inmediato desde https://www.scrumguides.org/download.html o directamente la edición en español desde: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf, es la guía oficial que te presenta la teoría y las reglas de Scrum. Es la única fuente fiel, escrita y mantenida por sus creadores.

¿Quién sabe? Seguramente, si vas a jugar Fútbol y tomas el balón con la mano o si en tu equipo hay trece jugadores en la cancha recibirás una infracción y quizás hasta no puedas jugar.

Espero que sea de utilidad.

Saludos,

Las primeras reacciones a mis ideas en el foro fueron bastante positivas. De hecho, mucho más de lo que merezco. Pero eso me motivó a trasladar la explicación hasta mi Gazafatonario, para que más personas tuvieran acceso a ella. Por favor, déjame saber qué piensas al respecto.

domingo, febrero 02, 2020

Soy un buen Scrum Master pero la empresa no está preparada


O “Soy un buen Scrum Master pero la empresa no es ágil”

Imagen de mohamed Hassan en Pixabay
Cuando eres Scrum Master, sea cual fuere tu nivel de experiencia o de madurez en el rol, nunca más se da el caso de “no soy yo, son ellos”:
  • Es que apenas están implementando Scrum, ellos (la organización, los equipos, las personas) no están maduros. | ¿Es posible “implementar” Scrum?
  • Es que todavía están (los equipos, las personas) atascados en los modos tradicionales de gestión y creen que soy el jefe o el gerente.
  • Es que ellos necesitan entender la nueva forma ágil de trabajar que quieren adoptar. | ¿”Adoptar”, luego no era “implementar” Scrum?
  • Es que están esperando que yo comande al equipo desde alguna suerte de puesto de control o cabina de mando.
  • Es que yo no tengo autoridad sobre el equipo. Soy solo un líder servicial a su servicio, como dice la guía de Scrum. Y el equipo es autogestionado. Funciona por sí solo. | ¿Un equipo “funciona”?
  • Y la lista de razones puede llegar a ser interminable.
Muchas organizaciones con una fuerte cultura de comando y control no te tomarán en serio como Scrum Master si no muestras habilidades para tomar el control de la situación. Las formas de hacer las cosas y mucho menos las formas de pensar actuales se cambian en pocos meses. Hacer que la empresa, los equipos y las personas maduren o siquiera estén conscientes de su nivel de agilidad es tu responsabilidad también.

Imagen de Gerd Altmann en Pixabay
No puedes simplemente ignorar la cultura actual de la organización y conducirte sobre los nuevos preceptos que te “dicta” la agilidad, el pensamiento Lean o prácticas como Scrum. “Es que ellos no entienden nada de liderazgo servicial ni de mejoramiento continuo”. No hay tal cosa como “ellos y nosotros” en el pensamiento ágil.

No te apresures. Da un paso a la vez y aprende de la reacción del entorno. Concéntrate primero en el equipo y ve escuchando al resto de la organización sin atribularte por la avalancha de ideas, solicitudes, advertencias, restricciones, desafíos, oposiciones y demás escenarios que vas a vivenciar. Para ello, viene bien hacerse acompañar de otros Scrum Masters, coaches ágiles o de cualesquiera que te proporcione ideas y que desee llevarlas a cabo contigo.

Estás allí para enseñarle a cada miembro del equipo a ser un líder, para empoderarlo y ayudarlo a aclarar su rol en este nuevo orden de las cosas, para remover algunos de los obstáculos en su camino pero más que a nada para instruirlo en cómo eliminarlos por sí mismo. Por sobre todas las cosas, no pierdas de vista que vienen de la cultura de ser recursos, así que piensa en ellos como personas y haz todo lo que esté a tu alcance para aumentar su felicidad.

Eres su entrenador pero deja que ellos también te entrenen. Aprende de la cultura y de los comportamientos imperantes. Luego, comienza a promover y a resaltar nuevos comportamientos “a lo ágil” y a desalentar, sin presión, las conductas actuales que no posibilitan el mejoramiento del equipo. Define un buen conjunto de valores que sean consistentes con el mensaje que quieres enviar y con el nuevo camino que les quieres mostrar, los valores de Scrum te ayudan, sí.

Asegura victorias tempranas. Una matriz de Esfuerzo versus Valor siempre viene bien en estos casos. Asegúrate de hacer con tu nuevo equipo lo que está en la zona de mayor Valor pero menor Esfuerzo y por ningún motivo mires la zona de mayor valor y menor esfuerzo.

Matriz de Esfuerzo versus Valor
Esfuerzo y Valor son relativos. Asume que todo lo que haces genera Valor y requiere de cierto esfuerzo. Pero incluye las variables que necesites para garantizar que algunas tareas, de tres a cinco de ellas, generan más valor que otras y requieren menos esfuerzo que otras. Y así, hasta completar la matriz. Distintos ejercicios te pueden llevar a lograr esto en pocos minutos, aun si tu equipo no es el mejor comunicándose.

Ve a lo seguro, sin dejar de experimentar. Después de todo, de eso se trata, de aprender mediante experimentos rápidos y baratos. Sigue la línea Shu-Ha-Ri como en esta infografía que preparé con mi gran amigo, compañero de batallas ágiles, Jorge Abad (@Jorge_Abad):

Scrum Master Shu-Ha-Ri
En esta etapa inicial, como Scrum Master, sigue la guía de Scrum con cierta precisión. Concéntrate en cómo organizar y llevar a cabo los eventos con el equipo, que se tengan los artefactos y que cada miembro del equipo Scrum se desempeñe como lo plantea la guía, sin preocuparte demasiado por la teoría subyacente; por ejemplo, en cómo planificar en un entorno empírico. Si hay múltiples variaciones sobre cómo hacer algo, solo decídete por la forma en que la guía lo establece o en como lo aprendiste. Tengo que decirlo, en este último caso, quizás estés equivocado, así que igual, hazte acompañar de alguien más experimentado, incluso de miembros de tu nuevo equipo. Ellos ahora son tu familia.

Más adelante pasarás a los demás estados. Recuerda que si ingresaste al equipo y a la organización, hay una alta probabilidad de que la madurez en materia de desempeño de todos quizás se reinicie “a lo Tuckman”, en donde los miembros del equipo tengan miedo (otra vez) de pedir ayuda unos a otros y a ti, no confiarán completamente en ti y te monitorean de cerca cuando estés trabajando en una tarea específica, con o sin ellos; muchos de ellos tendrán sus propias ideas sobre el proceso y las agendas personales serán rampantes; quizás te encuentres con roles específicos dentro del equipo, como líder técnico, facilitador, diseñador, documentador, incluso gerente; volverán las discusiones abstractas (si alguna vez se fueron) sobre distintos conceptos y temas y algunos miembros estarán impacientes con estos debates. Entre otros comportamientos típicos de la etapa de Formación de un equipo tradicional.

Incluso parecerá que estás logrando poco hacia la consecución de los objetivos del proyecto (sí, todavía se llamará “proyecto) y recibirás toda la carga de la culpa cuando te señalen a ti y a la nueva forma ágil de hacer las cosas que intentas poner de manifiesto en el ambiente. No te preocupes mucho por ello, aunque no estén completamente seguros de las metas y problemas del proyecto, algunos, quizás todos, estarán entusiasmados y orgullosos de estar en el equipo y a la expectativa de lo que pueda venir.

Las cosas así, quizás no puedas ir más allá del estado Shu, así te sientas con la fuerza, la experiencia y el coraje para empezar con el estado Ri. Lo leí de Melina Jajamovich (@latodoterreno) recientemente, “No hay seniority que valga cuando se trata de #agilidad | El mindset es un desafío de cada día”. Eres un eterno aprendiz, inculca eso en tu equipo, estás allí para acompañarlos a ser mejores.

Finalmente, empieza a pensar en el futuro del equipo. De hecho, esto se convertirá en lo más común y en lo mejor que podrás hacer en tu nuevo rol. Con el tiempo aprenderás que para un Scrum Master extraordinario no hay tal cosa como “no puedo hacer esto o aquello porque surgió algo urgente”. Debes adelantarte en el tiempo y visionar cómo llevarás al equipo al siguiente nivel de crecimiento, sin dejar de vivir en el presente para estar al frente de las tareas menos mundanas de protección y liderazgo del equipo.

Ya eres Scrum Master, no lo eches a perder solo porque el resto de la organización no te entiende. Asume tu responsabilidad, toma el control y muéstrales las cosas fantásticas que pueden lograr con agilidad. Es tiempo de cambiar.