Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Comunidad Ágil. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Comunidad Ágil. Mostrar todas las entradas

domingo, noviembre 22, 2020

Ágiles 2020: o del menguado interés por el desarrollo de software en los eventos ágiles

Temas de interés en Ágiles 2020
Imagen tomada de las redes sociales.

Hace poco se llevó a cabo la más reciente edición de Ágiles Latinoamérica, Ágiles 2020. Iba a ser en Uruguay, quizás en Montevideo. Pero, por razones ampliamente conocidas o imaginadas por todos, se realizó de manera virtual. Como siempre, un evento que convoca a toda la Comunidad ágil de la región, incluso de Europa. Por ejemplo, en la charla que facilitara con mi gran amigo Jorge Abad sobre “de qué hablamos cuando hablamos de historias de usuario” había personas de España. La sorpresa es que allá eran las 2 de la madrugada del día siguiente.

A estas alturas del año, con quizás algunos miles de horas más “frente a la pantalla” que en años anteriores debido a la situación mundial, el entusiasmo de algunos no era el mismo. Sin embargo, hicimos lo posible por llegar a la cita y por cumplir con quienes apoyan el evento, con quienes lo organizaron con corazón y con pasión. A todos ellos, muchas gracias.

Pero no quiero referirme a la organización, a las vicisitudes del evento o a las sesiones, sino a su contenido. Específicamente a las categorías de contenido que hubo en el encuentro. El llamado de trabajos a presentar se hizo clasificado en cinco temas o “tracks”:

  • Producto y clientes
  • Liderazgo y cultura
  • Equipos y coaching
  • Software crafters
  • Organizaciones ágiles

Y durante la apertura se hizo una encuesta rápida sobre cuáles eran los intereses de los asistentes. Los resultados están en la imagen superior (lo siento, no pude conseguir una mejor resolución). El hecho es que desde ese mismo momento y aún después del evento llamó a muchos la atención de que el tema “técnico” no fuera del interés general (hablo de la categoría de Software crafters). El resultado muestra un interés de menos del 25 %, con una muestra representativa de 209 personas que seleccionaban sus preferencias de manera ordenada, de mayor a menor predilección. Y una primera cosa que debo aclarar es que esta es la preferencia de los asistentes, de hecho, así nos gusta hacer las cosas, con lo que les interesa a las personas “hoy”, no con lo que alguien más piensa o presume que le puede servir o concernir.

Pues bien, para aquellos que piensan y sienten que esto es un contrasentido, que se está perdiendo el interés por lo “técnico”, que las personas que tenemos responsabilidades o roles como Scrum Master, coaches o mentores ágiles, facilitadores o habilitadores, no estamos interesados o, peor aún, no sabemos de lo técnico, y que todo esto es una consecuencia de lo que ha venido pasando en los últimos no solo en el Ágiles Latinoamérica sino en otros eventos de esa misma índole, los invito a reflexionar un poco sobre lo siguiente:

Yo creo que tenemos que mirar el contexto. Desde mi punto de vista esto quiere decir que el pensamiento ágil se está llevando a todos los rincones de la organización y que ha salido de una vez por todas y para siempre de las áreas de tecnología, sobre todo de las de desarrollo de software.

Es que pensar que los Scrum Masters deben saber de software es decir que solo podemos usar Scrum para hacer desarrollo de software, cuando, de hecho, hace muchos años hemos pasado esa frontera. Scrum se usa hoy en muchos contextos fuera del desarrollo de software y fuera de lo “técnico” (considerando “técnico” el software), porque cada área tiene su “técnico”. Por ejemplo, si son equipos de Talento Humano, de Operaciones, de Logística, de Mercadeo, de Ventas, incluso de la alta gerencia de la empresa, los Scrum Masters no tienen porqué saber de desarrollo de software.

Si uso Scrum o cualquier otra práctica ágil para crear un hospital, para desarrollar un producto o servicio que no tenga nada que ver con software, para investigación y desarrollo, para enseñar (incluso para aprender), para una empresa de preparación de matrimonios, para abrir y gestionar una cafetería o un restaurante o un bar, para llevar a la cúspide a un equipo deportivo, en fin, para cualquier otra cosa que no sea software, entonces necesitamos otro tipo de agentes de cambio, de facilitadores o habilitadores ágiles, de Scrum Masters, de personas que hagan el trabajo a “lo ágil”.

Quizás eso es lo que quieren decir esos números. Ya abordaremos el tema de si, cuando se trata de desarrollo de software, los Scrum Masters deben saber de software o no, yo pienso que sí. Pero eso es algo muy distinto a lo que estamos hablando aquí.

Debemos entender de una vez por todas y para siempre que la agilidad y Scrum y Kanban y todas las demás prácticas que usamos hoy, no las usamos solo para hacer software. ¿Tú que piensas? Por favor, déjamelo saber en el foro.

¡Aunque sea cuales fueren tus pensamientos, espero verte en #Agiles2021 en Panamá!


Coletilla:

Hace algunos días se publicó la nueva versión de la guía de Scrum, asunto que generó mucho interés entre la comunidad de practicantes ágiles en todo el mundo. Sobre el tema que abordé en este artículo, tengo que referirme a la declaración inicial que hacen los autores de la guía y cocreadores de Scrum, Sutherland y Schwaber. Explícitamente dicen al inicio:

Nos sentimos honrados de ver que Scrum está siendo adoptado en muchos dominios que tienen un trabajo esencialmente complejo, más allá del desarrollo de productos de software donde Scrum tiene sus raíces”.

Es definitivo, hace mucho dejamos de usar Scrum solo para desarrollo de software y las áreas de la empresa fuera de Tecnología son muchas más. Quizás a ello se deba el interés creciente en otros temas ágiles.


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.