lunes, 21 de septiembre de 2020

¿Qué significa equipos remotos, distribuidos, dispersos y virtuales?

Equipos remotos ¿virtuales, distribuidos o dispersos? - cortesía de Pixabay
Con COVID-19, y el consecuente asentamiento del teletrabajo como nueva normalidad, éstos términos referidos a equipos han tomado relevancia. Los hemos incorporado en nuestro lenguaje del día a día pero a veces los empleamos de forma inadecuada o confusa. Con este post quiero tratar de exponer el significado y diferencias entre éstos.

Las nuevas configuraciones de equipos tienen en común que están compuestas por miembros de equipo que comparten una misión y que desempeñan su trabajo desde una combinación de entornos fijos, móviles y/o remotos. Distinguimos entre dos tipos de equipos, los equipos remotos y los equipos virtuales.
  • Un equipo remoto trabaja directamente con una única pila de producto gestionada por su Propietario del Producto, y sus miembros no están colocalizados geográficamente.
  • Un equipo virtual es un equipo temporal donde miembros de diferentes áreas de especialización realizan tareas específicas o resuelven problemas específicos. Un equipo virtual suele estar formado por personas que habitualmente trabajan en otros equipos. Un equipo virtual puede estar colocalizado, pero el término generalmente se refiere a equipos geográficamente deslozalicados. Estos equipos virtuales que se han formado con un propósito específico "se dispersan" una vez que su tarea se ha completado.
En función de la localización de los equipos y sus miembros distinguimos entre:
  • Equipos distribuidos son aquellos donde los miembros de los equipos están colocalizados y los equipos están deslocalizados en diferentes localizaciones geográficas con respecto los equipos con los que colaboran (ART, tribu,...), como por ejemplo una tribu con el equipo de desarrollo en España y el equipo de arquitectura en la India.
  • Equipos dispersos son aquellos donde todos o algunos de los miembros de los equipos están dispersos en diferentes localizaciones, como por ejemplo fue la situación de confinamiento COVID-19 donde todos los miembros de cada equipo teletrabajaron desde su casa.
Equipos distribuidos y dispersos presentan retos diferentes:
  • Para los equipos distribuidos podemos utilizar técnicas de coaching para desarrollar a los equipos individuales a través de las etapas de formación de equipos y la identidad de tribu. Serán capaces de desarrollar sus propios mecanismos de sincronización si les proveemos de las herramientas de comunicación y trabajo distribuido necesarias.
  • En los equipos dispersos es más difícil crear identidad y por tanto es necesario desarrollar una cultura virtual completa, lo que implica invertir en reforzar la autonomía y la toma de decisiones descentralizada con formación y entrenamiento especializados.

jueves, 17 de septiembre de 2020

¿Qué cultura hay detrás de la Casa de Lean?

A semejanza del Manifiesto Ágil en Agilidad tenemos la Casa de Lean (House of Lean) en Lean. House of Lean es un contenedor en forma de diagrama de casa para los principios y prácticas de la mentalidad Lean. Éstos se forjaron con el sistema de producción de Toyota y la manufactura Lean y han evolucionado y se han extendido de manera que actualmente se aplican al desarrollo de software, de productos y de sistemas.

La evolución de la Casa de Lean ha incluido conceptos y técnicas familiares para los coaches ágiles, ha ayudado a reducir mudas y muris, y también ha resultado en una herramienta para ayudar a focalizar en el valor y reducir los gastos, especialmente al escalar utilizando marcos como SAFe.

Hay muchas variantes de la Casa de Lean, aunque todas ellas tienen como objetivo la entrega de valor en su techo y el liderazgo alineado con Lean y Agile en su base.

Veamos la propuesta de Scrum Manager:
La Casa de Lean según Scrum Manager
Objetivo

Lograr el menor tiempo de entrega sostenible con:
  • La mejor calidad y valor para las personas y la sociedad
  • Costes bajos
  • Alta moral, seguridad y deleite del cliente
Respeto por la gente
  • Tu cliente es quien consume tu trabajo, no le creas problemas
  • Tus empleados hacen todo el trabajo, prioriza su desarrollo: "desarrolla personas y después construye productos"
  • No hagas que la gente trabaje en cosas sin valor, es desperdicio
  • Crea un ambiente de mejora para equipos e individuos, haz que ellos indentifiquen mejoras y evolucionen sus propias prácticas
  • Construye asociaciones estables a largo plazo con tus proveedores que estén basadas en la confianza
  • Desarrolla equipos, dales los recursos que necesiten para que puedan desarrollar un trabajo excelente
Prácticas
14 Principios
Mejora continua
Base

Cultura de Gerencia (Liderazgo al Servicio):
  • Aplicar y enseñar Lean Thinking en la toma de decisiones
  • Predicar con el ejemplo
  • Adoptar una mentalidad de crecimiento
  • Ejemplificar los valores y principios de Lean
  • Desarrollar personas
  • Liderar el cambio
  • Fomentar la seguridad psicológica
Veamos la Casa de Lean que propone LeSS
The LeSS Lean Thinking House - imagen del tema Lean Thinking de LeSS
La evolución más significativa es la sustitución del pilar de prácticas por el desarrollo de producto.

Desarrollo de producto
Y finalmente la Casa de Lean de SAFe©
The SAFe House of Lean - imagen del tema Lean-Agile Mindset cortesía de © Scaled Agile, Inc.
SAFe ha evolucionado principalmente los 4 pilares de la Casa de Lean para maximizar la coherencia con su marco de escalado.

Respeto por la gente
  • Crear una cultura generativa donde los lideres ponen énfasis en el logro de metas y misiones de la organización a tiempo
  • Tus empleados hacen todo el trabajo, prioriza su desarrollo: "desarrolla personas y después construye productos"
  • Tu cliente es quien consume tu trabajo, no le creas problemas
  • Construir asociaciones estables a largo plazo con tus proveedores que estén basadas en la confianza
  • Entender que para cambiar la cultura primero hay que cambiar la organización, y que la organización se puede cambiar implementando marcos ágiles como Scrum y SAFe
Flujo
  • Optimizar la entrega sostenible de valor de forma continua
  • Construir con calidad donde la calidad no sea una variable
  • Entender, explotar y gestionar la variablidad, la variabilidad nos da la oportunidad de descubrir la mejor solución y maximizar el valor entregado
  • Cambiar de mentalidad de proyecto a producto
  • Fomentar personas innovadoras en todos los niveles
  • Dotar de espacios y tiempo para la innovación, con comunidades de práctica por ejemplo
  • Go and see (Gemba): Los responsables visitan y conocen el lugar de trabajo
  • Fomentar la experimentación y el feedback rápido para mejores decisiones y la mejora continua
  • Pivotar sin piedad ni sentimiento de culpa, si algo ya no tiene sentido tíralo, no podemos cambiar el pasado, pero si el futuro
  • Fomentar oleadas de innovación desde cualquier área y cruzando áreas
  • Constante sensación de tensión, entender por ejemplo que hoy nuestro cliente está, pero quizá puede que mañana no si no nos centramos en sus necesidades
  • Optimizado el todo aplicando System Thinking
  • Fomentando una cultura de resolución de problemas
  • Reflexionar sobre los hitos clave para identificar y abordar abiertamente las deficiencias del proceso en todos los niveles
  • Basar la mejoras en hechos
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

domingo, 13 de septiembre de 2020

¿Por qué Recursos Humanos son tan importantes en Agilidad?

La fuerza impulsora detrás de las organizaciones con mentalidad ágil son los trabajadores del conocimiento, personas que saben más de su trabajo que sus jefes y lideres, por tanto necesitamos personas proactivas, apasionadas y comprometidas a las que empoderar para que puedan tomar decisiones con la información que manejan a su nivel. Todo ello en un entorno donde se da valor y se potencia la colaboración y el alineamiento. En definitiva queremos personas que quieran pensar, personas que quieran aprender continuamente, personas que quieran ser dueñas de sus planes y sentir verdadero compromiso hacia sus planes para construir las mejores soluciones a las necesidades de los clientes de la compañía.

La mentalidad ágil desafía al área de Recursos Humanos tradicional a realinear su enfoque de personas para esta nueva forma de trabajar que trae la Agilidad:
Buen pensamiento, buenos productos - lema interno en las instalaciones de Toyota
Si cuidas de tus empleados ellos cuidarán de tus clientes

Existe el Manifiesto Ágil para el Desarrollo de RRHH que nos aporta los valores y principios necesarios. En este post quiero mostrar los puntos que me parecen críticos para la forma de pensar y de actuar de Recursos Humanos ágiles:
  • Selección y contratación: Queremos gente que piense, que se integre y que colabore con los demás, por tanto las claves están en el talento de las personas y su actitud en vez de en sus aptitudes. Los equipos ágiles prosperan cuando Recursos Humanos contrata candidatos con la actitud y la cultura adecuadas, ya que el éxito depende de las habilidades colectivas y colaborativas del equipo. Deben evitarse tipos "O", candidatos con tendencia al heroísmo y la especialización excesiva.
  • Desarrollo y crecimiento: Cuanto mejor piensen esas personas y cuantas mejores aptitudes (herramientas) les demos, mejores decisiones tomarán, mejor trabajo harán y más competitiva harán a la compañía. Por eso Recursos Humanos deberá fomentar el crecimiento, aprendizaje continuo y la toma de decisiones descentralizada (autoorganización) de los empleados de la compañía basándose en la motivación intrínseca y proveer de vías y espacios de aprendizaje. La Agilidad no distingue entre el trabajo y el aprendizaje.
  • Fomentar la colaboración: Recursos Humanos deberán ser system thinkers, entender la compañía desde el punto de vista del todo e impulsar a las personas en una misma dirección. Esto se consigue fomentando la colaboración, haciendo entender que desde el punto de vista del trabajo, por ejemplo una tribu, esta tiene prioridad sobre el equipo, y este lo tiene sobre el individuo. De esta manera, si está explicitado que las dependencias dentro de la tribu tienen prioridad sobre las prioridades de los equipos, será del interés de cada individuo colaborar con los demás equipos, y se crearán planes que tendrán en cuenta las necesidad de otros y se eliminarán demoras y bloqueos que suelen retrasar el desarrollo en meses.
  • Cuidado de la salud emocional: El trabajo lo realizan personas y las personas tenemos una naturaleza que nos define: somos seres emocionales. Si estamos cansados, estresados, desilusionados, preocupados, enfadados... no realizaremos un buen trabajo. Recursos Humanos debería de cuidar el lado emocional de los empleados de la compañía, a veces simplemente escuchando y otras con habilidades adquiridas de coaching sistémico y personal. Incluso es recomendable que hubiera un psicólogo en el equipo de RRHH.
  • RRHH velando por los empleados - Photo by Dylan Gillis on Unsplash
  • Desempeño: En lugar de calificaciones de desempeño de empleados periódicas, usualmente anuales, Recursos Humanos ágiles da forma a una cultura de respeto mutuo facilitando diálogos sinceros de feedback continuo entre líderes, empleados y compañeros que fomenten la mejora continua a todos los niveles. La métricas de desempeño deben de ocurrir a nivel de sistema, por ejemplo a nivel de tribu, en la que se ha establecido un objetivo común y las métricas a nivel sistémico van a fomentar que todos los individuos colaboren para maximizar el desempeño del todo, el de la tribu.
Conociendo un poco más como son Recursos Humanos en una organización ágil te invito a reflexionar y te pregunto: ¿qué está en tus manos para hacer que esto se haga realidad en tu compañía?

lunes, 7 de septiembre de 2020

¿Cómo evitar los proyectos sandía?

Proyectos sandía - Sandía cortesía de Pixabay
Estamos a un mes de la fecha de entrega, todo va muy bien y el proyecto está en verde. De repente, como un bandido que nos asalta desde detrás de un árbol, todo parece ir mal y el proyecto se pone en rojo; desviado, con sobrecostes... un verdadero desastre. Eso es lo que se llama un proyecto sandía, verde por fuera y rojo por dentro. Los proyectos sandía suelen ocurrir por falta de transparencia, uno de los valores fundamentales que promueven Scrum y la Agilidad, uno de los valores que debería de estar en cualquier proyecto.

También existen los proyectos cangrejo, que siempre están en rojo, se complican cada vez más y hacen sufrir a todos en todo momento... pero esos son otra historia y no son objeto de este post.

Veamos qué cosas podemos hacer para que nuestros proyectos ágiles no se conviertan en proyectos sandía:
  • La DoD (Definición de Hecho): introduciendo una definición de hecho para las tareas del proyecto. La DoD alineará el entendimiento de lo que significa "hecho" para todas las personas involucradas en el proyecto; "hecho" significará lo mismo para negocio, los interesados, el jefe de proyecto y los desarrolladores. Conseguiremos dos beneficios; reduciremos el retrabajo, ya que lo que esté hecho verdaderamente lo estará, y no habrá sorpresas ni malentendidos. Por otro lado ganaremos visibilidad sobre el progreso real del proyecto, ya que lo finalizado realmente estará finalizado.
  • Focalizar en valor de negocio: priorizando las tareas en función del valor entregado al cliente. Así empezaremos el proyecto construyendo aquellas funcionalidades que sean más críticas o resuelvan las mayores necesidades de nuestro cliente. Las funcionalidades que queden para el final del proyecto no desatarán ninguna crisis si se desvían o no se hacen.
  • Acabar antes de empezar: introduciendo una regla que marque que solo se puede continuar con la siguiente tarea del proyecto cuando la tarea anterior esté totalmente finalizada. A parte de focalizar al equipo, y por tanto acelerar el flujo, esta regla va a evitar que haya muchas tareas abiertas que oculten el verdadero progreso del proyecto.
  • Nunca aceptar tareas que no cumplan con la definición de hecho: una tarea hecha al 90%, por ejemplo, no está hecha. Si la aceptamos como hecha, sea como equipo, jefe de proyecto o interesado, introduciremos incertidumbre en el proyecto que cuando explote generará un retrabajo que será muy costoso.
  • Dividir en tareas pequeñas: tareas pequeñas focalizan por ser pequeñas, si empezamos una tarea pequeña es muy probable que no nos interrumpan mientras trabajemos en ella. Por otro lado tareas pequeñas son más fáciles de comprobar y de testear, por tanto será más fácil aplicar la definición de hecho. Tareas pequeñas dan sensación continua de avance y de cerrar cosas, con lo que habrá menos ruido en la cabeza de los desarrolladores y por ende una mayor motivación.
  • Dar visibilidad frecuente a lideres e interesados: involucrándolos en revisiones y demos frecuentes de lo que estamos construyendo. Muchas veces la falta de visibilidad sobre la realidad del proyecto provoca que interesados, clientes y managers tomen decisiones equivocadas e influyan de forma negativa en el proyecto. Así por ejemplo es muy positivo que éstos conozcan las problemáticas por las que pasa el proyecto o el equipo, ya que éstos pueden aportar soluciones desde fuera que desde dentro del equipo no hayamos pensado.
Quiero finalizar el post resaltando que las prácticas y artefactos que he mencionado son algunos de los que promueve la Agilidad...

martes, 25 de agosto de 2020

¿Cómo lidiar con un interesado dominante?

Una de las responsabilidades de un Propietario del Producto es la gestión de los interesados; es quien está en primera línea ante los conflictos de prioridades y necesidades de éstos. Aunque la Agilidad nos provee de una priorización que maximiza las decisiones de un Propietario del Producto desde el punto de económico, este rol requiere habilidades sociales para balancear las necesidades de los diferentes interesados y moverse exitosamente en el panorama político de la compañía.

Imaginemos un interesado dominante que no está conforme con la priorización de sus deseos en nuestra pila de producto, por ejemplo un manager que siempre ha hecho que las cosas ocurran e insiste en que demos prioridad a lo suyo, ¿cómo podemos lidiar con él?
Modelo de comportamiento DISC
En 1928 William Moulton Marston, psicólogo fisiológico de Harvard, introdujo el modelo de comportamiento DISC que permite categorizar a todos las personas (mentalmente sanas) en cuatro perfiles básicos de personalidad. Resulta que, aunque todos seamos diferentes y únicos, nuestras tendencias de comportamiento, las reacciones y las emociones, son comunes y predecibles. Por tanto, si como Propietario del Producto somos capaces de situar a los interesados en DISC, esta herramienta puede ayudarnos a entender mejor sus reacciones y comportamiento y por ende a mejorar la relación y comunicación con estos. A la luz de DISC podemos conocerlos mejor y saber lo que les gusta, lo que les motiva, cuales son sus prioridades, sus fortalezas, sus áreas de crecimiento, sus miedos y dolores, lo que les irrita y estresa, en qué ámbitos sienten seguridad...
  • Dominancia: persona que pone énfasis en lograr resultados, en el resultado final y en la confianza. Sus tendencias de comportamiento incluyen: ver el panorama general, ser muy franco, aceptar desafíos y ir directo al grano.
  • Influencia: persona que pone énfasis en influir o persuadir a los demás, en la apertura y en las relaciones. Sus tendencias de comportamiento incluyen: mostrar entusiasmo, ser optimista, le gusta colaborar y no le gusta ser ignorado.
  • Serenidad: persona que pone énfasis en la cooperación, la sinceridad y la confiabilidad. Sus tendencias de comportamiento incluyen: no le gusta que lo apresuren, ser calmado, sus enfoques son calmados y sus acciones son de apoyo.
  • Cumplimiento: persona que pone énfasis en la calidad y la precisión, la experiencia y la competencia. Sus tendencias de comportamiento incluyen: disfrutar de su independencia, razonar de forma objetiva, necesitar de detalles y temer a equivocarse.
Para identificar el estilo de personalidad de un interesado podemos aplicar la técnica que sigue y que he extraído del artículo "La Teoría del DISC" de DISC for All que recomiendo fervientemente leer:

1. ¿Es de ritmo rápido o lento?
¿Cómo se mueve? ¿Tiene prisa o por el contrario espera pacientemente su turno?

2. ¿Está orientados a personas o a tareas?
¿Parece interesado en socializar con el resto, te cuenta que ha hecho el fin de semana o por el contrario prefiere simplemente realizar sus tareas y cuenta poco de su vida? .

¿Es este individuo de ritmo rápido orientado a tareas? Puede ser un perfil D
¿Es de ritmo rápido y orientado a las personas? Puede ser un perfil I
¿Ritmo lento y orientado a las personas? Puede ser un perfil S
¿Ritmo lento y orientado a tareas? Puede ser un perfil C

Una vez identificado el perfil entendamos su personalidad e imaginémonos ante el interesado y dejemos que nuestra inteligencia emocional nos muestre sus posibles reacciones.

Volvamos pues a nuestro manager dominante: sin duda es un perfil D, decidido y ejecutivo, al que contentaremos ofreciendo soluciones y proveyendo opciones. Si por el contrario le proveyéramos de muchos detalles, como necesita el perfil C, o le realizáramos muchas preguntas, como necesita el perfil I, se pondría nervioso e intentaría coger las riendas.

Para cerrar quiero compartir el siguiente cuadrante de DMIT Training 360° que nos ayudará a qué acciones podemos intentar y qué reacciones cabe esperar de los distintos perfiles.
Perfil D - Dominancia

Intentar:
  • Hacer ser breve e ir al grano
  • Respetar su necesidad de autonomía
  • Ser claro acerca de reglas y expectativas
  • Dejarles iniciar
  • Mostrar tu competencia
  • Ceñirse al tema
  • Mostrar independencia
  • Eliminar pérdidas de tiempo
Estar preparado para:
  • Enfoques directos y exigentes
  • Carencia de empatía
  • Carencia de sensibilidad
  • Poca interacción social
Perfil I - Influencia

Intentar:
  • Acercamiento de manera informal
  • Estar relajado y ser sociable
  • Dejarles verbalizar pensamientos y sentimientos
  • Mantener las conversaciones ligeras
  • Proveerles de detalles escritos
  • Darles reconocimiento público por logros individuales
  • Usar el humor
Estar preparado para:
  • Intentos de persuadir/influenciar en otros
  • Necesidad de ser el centro de atención
  • Sobreestima de si mismo y otros
  • Respuestas emocionales
Perfil S - Serenidad

Intentar:
  • Ser lógico y sistemático
  • Valorar altos estándares
  • Ser preciso y focalizado
  • Proveer de hechos e información de fondo
  • Ser discreto y reservado emocionalmente
  • Mostrar confiabilidad
  • Dar tiempo de preparación
Estar preparado para:
  • Preguntas
  • Resistencia a preguntas vagas y generales
  • Deseo de volver a comprobar
  • Poca necesidad de afiliarse con otras personas
Perfil C - Cumplimiento

Intentar:
  • Ser cálido y solidario
  • Dar expectativas y plazos claros
  • Permitir que el precedente sea una guía
  • Proveer de un entorno consistente y seguro
  • Dejarles saber como se harán las cosas
  • Usar la apreciación sincera
  • Mostrar su importancia para el bien organizacional
Estar preparado para:
  • Un enfoque amistoso y cálido
  • Ser lento en el cambio
  • Dificultades para priorizar
  • Dificultades con plazos de entrega
Thanks to Disc for All and DMIT Training 360° for the shared information on the intenet :-)

miércoles, 12 de agosto de 2020

¿Cuál debería de ser la experiencia que debiera tener alguien para ser coach ágil?

La lista de Jem "Jelly"
Jem "Jelly", que lleva desde 2005 trabajando con más de 100 equipos ágiles, ha creado una lista con "10 things to *PRACTISE* before calling yourself an Agile Coach" que quiero presentar en este post y con la estoy totalmente en sintonía.

Es cierto que ha habido gran proliferación de coaches ágiles, especialmente al estilo tradicional como cargo o título en vez de como un rol que lleva implícito un agente de cambio empoderado, cuyo objetivo es fomentar el cambio e ir a contracorriente de la inercia de la compañía.

Por ello es tan importante entender bien el rol y así poder desempeñar las responsabilidades que conlleva. Podemos adquirir el conocimiento asistiendo a cursos especializados, pero el entendimiento solo lo lograremos con la experiencia y aprendiendo de nuestros errores.

La lista resume de forma excelente 10 cosas que cualquier coach ágil debería de entender profundamente.
  1. Scrum Master, facilitador Kanban o equivalente de un equipo al menos durante 2-3 años.
  2. Haber ayudado a los equipos a visualizar su trabajo, ayudándoles a obtener sus propios acuerdos de trabajo, definición de hecho (DoD), etc.
  3. Haber creado un flujo de valor, ayudando al equipo y equipos a colaborar en el panorama general, capaces de detectar desperdicios y haber explorado varias maneras para que los equipos colaboren en términos de la mecánica de gestionar y/o eliminar dependencias.
  4. Entender y haber ayudado a los equipos a establecer un equilibrio entre: (1.) construir la cosa de forma correcta (2.) construir la cosa correcta (3.) construir la cosa con velocidad.
  5. Haber aplicado técnicas de desglose de trabajo para validar aprendizajes más rápidamente y mitigar riesgos (MPVs, Impact Mapping, división de historias de usuario, User Story Mapping, etc.).
  6. Haber ayudado a los equipos usando enfoques "Termina de empezar y en lugar de ello empieza a terminar trabajo" (pensamiento en enjambre, límites WIP, conceptos "empuje" versus "arrastre").
  7. Saber articular COMO poner en práctica los valores y principios ágiles en un equipo.
  8. Haber aplicado/introducido pensamiento empírico en ambos procesos de equipo y negocio (al menos haberlo intentado con "negocio", por ejemplo habiendo ayudado al Propietario del Producto a usar el cono de la incertidumbre y a crear una pila de producto).
  9. Saber demostrar de forma confiada cuando y porqué no utilizar un marco ágil.
  10. Haber influenciado a equipo y managers para catalizar el cambio a través de datos empírico subjetivos y objetivos.
Thanks Jem "Jelly" to encourage to share your list :-)

viernes, 7 de agosto de 2020

¿Scrum ha muerto?

Me ha llamado la atención el artículo "Scrum Is Dead. All Hail Kanban, the New King" de Emanuel Marques, eso me ha llevado a observar paralelismos en la realidad que yo vivo y a reflexionar sobre todo ello.

El artículo resume que Scrum no es suficientemente ágil ya que las personas ponemos demasiado énfasis en el proceso. Resalta que la métrica más utilizada para evaluar el éxito suele ser el compromiso frente al hecho, cuando comparamos las historias de usuario comprometidas en la planificación del sprint con las historias que el equipo entrega en la revisión del sprint. Pero...
  • ¿Entregar una historia de usuario el primer día de sprint siguiente realmente está mal?
  • ¿Cuando haya sido necesario hacer un trabajo inesperado (cambios por información fresca, bugs, problemas de producción, etc.) significa incumplir el compromiso de la planificación de sprint?
Scrum no es un marco de trabajo,
es talento en equipos autogestionados
cortesía de Scrum Manager en Pinterest
Uno de los aprendizajes más difíciles para las empresas es permitir que sus equipos maduren (a performing) y encuentren el ritmo adecuado para empezar y acabar historias de usuario en cada uno de sus sprints. Es difícil porque implica balancear la producción con la capacidad real de los equipos y la cultura tradicional suele estar impregnada de sobrecarga constante de trabajo hacia esos equipos.

Por ello Scrum es un excelente punto de partida para encontrar ese ritmo y adentrar a la compañía en Agilidad; sin olvidar que el nivel de Agilidad va a depender en primera instancia de los Scrum Masters y coaches ágiles que lideren la transformación, y en segunda de la cultura y resistencia de la empresa.

Como nos quiere mostrar Emanuel Marques, muchas veces nos olvidamos que el objetivo de una implantación de Scrum no es Scrum en sí, sino encontrar a través de la mejora continua nuestra manera singular de trabajar alineados con los valores ágiles y así maximizar la entrega de valor a través de personas motivadas.

Y eso significa que deberíamos de romper las reglas de Scrum en algún momento, ya que la mejora continua nos llevará a métodos y prácticas mejores.

Llevemos ese pensamiento al extremo...

25 años después de la presentación de Scrum en la OPSLA'95 la realidad del software ha cambiado mucho. Las empresas que saben hacer software de calidad se basan en ciclos de construcción y feedback cortisimos, Amazon por ejemplo completa el ciclo del radar DevOps, desde hipótesis de funcionalidad a aprendizaje sobre su uso, en 24 horas, además de realizar una media de 168 despliegues en producción al día. El su libro de "Project to Product" Mik Kersten concluye que "aquellos que dominen la entrega de software a gran escala definirán el panorama económico del siglo XXI".

Miremos pues en esa dirección, a empresas como Facebook, Apple, Amazon, Netflix y Google, y preguntémonos desde su perspectiva si Scrum ha muerto.

¿No sería más contemporáneo a nuestra realidad partir de donde nos encontremos con Kanban? ¿Fomentar el flujo continuo de entrega de valor invirtiendo fuertemente en cultura, prácticas y herramientas DevOps? ¿Desarrollar equipos con continuidad basados en el talento de personas motivadas?

Pienso que Scrum no ha muerto, hay muchas empresas que todavía pueden transicionar de pensamiento de proyecto al de producto, y muchas que pueden aprender a terminar cosas antes de empezar nuevas. También pienso que Scrum como proceso está ya en plena fase de commodity; tiene valor de utilidad pero un nivel de diferenciación muy escaso.