Trabaja cada Sprint como si fuese el último

Hace unas semanas un ex-alumno me preguntó mi opinión sobre el modelo o método Montecarlo porque en su empresa estaban hablando sobre implantar este tema y me pareció interesante poder compartirlo. El modelo Montecarlo no es más que una de tantas técnicas de estimación que existen que, como todo en esta vida que sea buena o mala técnica no depende tanto de la técnica en sí sino del buen o mal uso que se haga de ella. Por defecto no estoy en contra de este modelo. Depende del contexto. Este modelo se usa mucho en meteorología. Se exponen un montón de variables y condiciones y se mira qué puede pasar basado siempre en condiciones previas o cosas que ya han pasado. A partir de ahí se coge un umbral y se seleccionan todas aquellas que superen una probabilidad mayor al umbral elegido, puesto que esas serán las opciones "probables". Cuando ves en las páginas del tiempo que pone "Probabilidad de lluvia 15%" es justo eso, que en el 15% de los modelos ejecutados dan lluvia con las condiciones actuales y que en el 85% restante no hay lluvia. Para entornos complejos no me disgusta la idea de usarlo siempre que se haga con sentido común. Al final es una forma de intentar saber qué va a pasar, es decir, predecir el futuro. En entornos complicados o complejos es muy difícil predecir el futuro. Sólo sabes lo que ha pasado pero difícilmente sabes qué va a pasar. Es cierto, al igual que dice este modelo, que mientras más "pasado" sepas, más probable es que aciertes el futuro. Pero no hay un 100% de garantía de acierto. El problema del método Montecarlo (y de cualquier otra forma de averiguar el futuro) es quien recibe los datos, porque es demasiado común que la probabilidad se tome como certeza y, que interprete que como en el 50% de los modelos un trabajo concreto se finaliza en dos semanas, entonces si se termina en tres semanas tienen que rodar cabezas. Recuerda que aunque las predicciones del tiempo pongan 0% de probabilidad de lluvia, puede que llueva; y aunque ponga 100% puede no llover. Y aún así, cuando ponen 60% de lluvia y luego no llueve siempre hay alguien que sale diciendo "es que estos del tiempo nunca aciertan, dijeron que iba a llover y fíjate el sol que hace", cuando realmente no dijeron que iba a llover, sino que un porcentaje alto de los modelos daban ese resultado, pero no existe la certeza absoluta y menos en entornos complicados o complejos. Como casi todo, cualquier herramienta es útil siempre que se use bien. Este modelo puede ser muy útil si se usa y se entiende bien, pero a la vez muy peligroso porque es muy tentador retorcer sus resultados e interpretaciones y por tanto que sirva para justificar o exigir una serie de resultados que realmente eran difícilmente alcanzables. Imagen de la entrada diseñada por Freepik

Esto es algo que suelo comentar en mis formaciones: Scrum es la mejor opción para la mayoría de los casos y sin embargo hay mucha gente a la que no sólo no les gusta, sino que lo llegan a detestar, siendo la mayoría de ellos Desarrolladores. ¿Cómo es posible que esto pase? Muy fácil: porque se hace mal. Por desgracia, la mayoría de los Desarrolladores sólo han visto usar Scrum en uno de sus múltiples tipos de aberraciones, provocado por la falta de conocimiento real en las organizaciones y, en los que muchos llaman ser, los Scrum Master. En un entorno ideal, un Desarrollador amaría Scrum: Está muy empoderado; tiene un peso importante en la toma de decisiones; se trabaja en equipo de verdad, no es un grupo que hace cosas sino que somos un conjunto unido que nos apoyamos y ayudamos en todo momento; ve cómo crece a todos los niveles (personal, equipo, organización, producto, etc.); está valorado personal y profesionalmente; la motivación aumenta día a día, etc. Todo esto provoca una importante reducción de rotación de personal, puesto que el talento no quiere irse de este tipo de entornos. Sin embargo, lo que la mayoría encuentra en entornos absurdos (he intentado buscar otra palabra, pero ninguna describe mejor esos entornos que "absurdo") es que se usa Scrum como una forma de controlar el progreso, midiendo velocidad por Sprint (por ejemplo) para que toda la planificación anual encaje con la previsión dada, sin evaluar si lo que se hace tiene sentido, ni si da valor, ni si los usuarios lo usan... Básicamente mantienen esos desarrollos en cascada (waterfall) del siglo pasado, pero lo hacen en iteraciones. Además, los Desarrolladores no tienen margen de decisión, ni de proponer mejoras... y peor aún, ni siquiera de opinar en las estimaciones que vienen dadas por otros departamentos. Para colmo a esos Desarrolladores se les asigna un perfil en su contratación y de ahí no se pueden salir pase lo que pase, provocando cuellos de botella internos. Un disparate lo mires por donde lo mires. ¿Qué pasa aquí? Pues cualquier Desarrollador que se vea en un entorno "absurdo" acabará por desmotivarse y lo normal es que busque alternativas para continuar creciendo personal y profesionalmente, por lo que la rotación de personal es alta y cuesta mantener los flujos de trabajo. ¿Qué provoca esto? Pues como casi todo en la vida: El desconocimiento. Muchas organizaciones oyen hablar de Scrum y quieren copiarlo en sus organización. Aquí se abren dos opciones: O contratan al "Scrum Master" más barato que encuentran para que se encargue de hacer el cambio en toda la organización, al que lo contratan porque tiene cuatro años de experiencia usando Jira y gestionando el backlog (bandera roja clarísima de alguien a quien no hay que contratar); o bien contratan una formación (tan absurda como el entorno que se les queda) donde les dicen que tienen que hacer Dailys, Retros y usar la herramienta X para la gestión del Backlog, con la que se llevan comisión, y sin hablar de la mentalidad que debe acompañar a esta forma de trabajar. Con esta información el equipo empieza a hacer las reuniones que les han dicho que se haga, con la máxima garantía (99,99%) de que lo van a hacer mal, puesto que van a mezclar lo que hacían con los eventos de Scrum y la mezcla será peor que lo que ya tenían. ¿Sabes qué me da pena/rabia? Que cuesta lo mismo hacerlo bien que mal. Si me dijeras que haciéndolo mal ahorras tiempo en algo, o que mejoras el rendimiento en algún punto, pues podríamos evaluarlo. Pero es que no es el caso. Muchas veces basado en el auto-engaño de "Es que en nuestra organización nuestra casuística es muy especial y Scrum no se puede aplicar tal cual", pero esa es la excusa para seguir manteniendo aquello que se estaba haciendo, con los mismos malos resultados que estabas teniendo y sin conseguir que el personal tenga esa motivación, ambición y empoderamiento que provoque unos resultados óptimos. ¿Sabes algunas "red flags" que anuncian entornos muy alejados de la excelencia? Cuando en la oferta de trabajo ponen: "Tu función, como Scrum Master, será la de mantener actualizado Jira y exportar métricas del equipo a Management para su evaluación" (uffff, es que no hay ni una palabra correcta). Si te preguntan en una entrevista cómo ayudas al equipo y tu primera respuesta es "Les actualizo el backlog y tomo nota en las dailys". Si te contratan, es que esa organización está lejísimos de trabajar bien. Espóiler: Si yo te hago la entrevista y me respondes eso, no necesito hacer más preguntas para descartarte. Next! Puede que seas un gran secretario, pero Scrum Master no. ¿Cómo solucionar este problema? Si eres (o quieres ser) Scrum Master, pero de verdad, tienes que formarte bien, entender bien para qué se hace cada punto que nos propone el marco de Scrum, cuestionarte todo lo que se hace en tu empresa y proponer cambios y mejoras continuamente (a todos los niveles). Si tienes una organización y has visto publicar alguna oferta de trabajo que se parezca a la del ejemplo, igual tienes que hacer una revisión de cómo estáis trabajando para salir de la cultura de la complacencia para poner el foco en la cultura de la excelencia. Sea cual sea el motivo, la solución la tienes con mi curso de Scrum Master con certificación oficial más las sesiones de consultoría Agile . Ahora sí entenderás por qué Scrum funciona, obtendrás las ventajas de usar Scrum, te costará lo mismo que cuando lo hacías mal y verás con el tiempo cómo los Desarrolladores pasan de odiar la forma en la que trabajáis a empezar a decir "así es como deberíamos haber trabajado antes", consiguiendo también que mejore su actitud y aptitud en el trabajo diario. Esto es algo parecido a lo que pasa con el modelo Spotify, que en el 99% de los casos no funciona porque lo único que se hace es llamar a los equipos "squads" y "tribus". ¿También haces eso? Entonces deberías contactar conmigo con bastante urgencia, porque hay mucho que corregir en tu empresa. Imagen de la entrada de Duncan Maddox

La guía de Scrum nos dice: "Scrum es simple". Sin embargo a muchos equipos les resulta muy difícil hacerlo bien y las organizaciones dicen que no está a la altura de las expectativas. ¿Si Scrum es tan simple, por qué a menudo parece tan complejo? ¿Qué significa "simple"? Según la RAE, simple es "sencillo, sin complicaciones ni dificultades" ¿Sin complicaciones? Las Guía de Scrum no está escrita de forma compleja. No es un libro enorme, apenas tiene 13 páginas. Define: pilares y valores, tres responsabilidades, cinco eventos y tres artefactos. Parece bastante fácil de entender. ¿Y dificultades? "Hacer" Scrum es muy sencillo: asignar roles, programar eventos, crear y mantener artefactos. Configurarlo es sencillo. Con todo esto, debería ser muy fácil ser ser efectivo con Scrum. Sin embargo, la verdad es que no. Y aquí está la clave: Scrum no se trata de "hacer" Scrum. Se trata de lograr resultados de negocio. No basta con seguir la mecánica de Scrum. Los equipos deben adoptar los principios fundamentales que hacen que Scrum funcione: Empirismo (y sus pilares) Pensamiento Lean Valores de Scrum ¿Más allá de "hacer" Scrum, qué hace falta para que funcione? ¿Los miembros del equipo e interesados colaboran activamente? No solo intercambiar actualizaciones, sino trabajar realmente juntos, resolviendo problemas al mismo tiempo, en lugar de participar en un ping-pong de información de ida y vuelta. ¿Tiene el equipo todas las habilidades necesarias para resolver el desafío en cuestión? ¿Si no es así, cómo están desarrollando esas habilidades? ¿O el equipo depende de otros, lo que provoca retrasos, cuellos de botella y desperdicios? ¿Existe una cultura de seguridad psicológica? ¿Pueden los miembros del equipo compartir abiertamente los desafíos y los obstáculos sin temor a ser culpados? ¿Se fomenta el aprendizaje? ¿Son los Eventos de Scrum sesiones de trabajo reales? ¿La planificación de Sprints, las revisiones y las retrospectivas se centran en las mejoras y acciones del producto? ¿O se han convertido en reuniones de estado para Management? "Simple" no significa "fácil" Se necesita disciplina para aprender y mejorar continuamente. Se requiere coraje para experimentar, fallar y adaptarse. El enfoque es fundamental: un enfoque nítido en el próximo objetivo del equipo y del producto. Scrum es simple por diseño, para que los equipos puedan trabajar en entornos complejos de manera efectiva. ¿Pero dominarlo? Eso requiere esfuerzo. Pero tú lo tienes más fácil aún. Si quieres dominar Scrum de verdad, tan sólo tienes que echar un vistazo a mis formaciones de Scrum con certificación oficial , disponible en todos los formatos. Esta entrada está basada en el artículo " Scrum Is Simple… So Why Is It So Hard? " de Steven Deneir

En mi experiencia, me he encontrado con muchos casos donde gente muy diversa reniega de Scrum afirmando, con excusas y ejemplos muy diversos que Scrum no funciona. Y esto lo hacen a todos los niveles, desde alta dirección, management, desarrolladores e incluso, algunos "Scrum Master". "Scrum está bien en la teoría, pero en la práctica no funciona", "es que nuestro caso es especial y Scrum no encaja en lo que hacemos", "Scrum tiene demasiadas reuniones que nos hacen perder el tiempo", "Scrum no sirve porque no se mira la calidad", "que sí, que en nuestra empresa hay un Scrum Master certificado y lo hemos probado en un proyecto tal cual viene en la guía y no hemos terminado en tiempo todos los requisitos que se nos pedían"... Casualmente, todos tienen algo en común: Interpretaciones o implementaciones incorrectas. Esto hace que el marco de trabajo Agile más común a nivel mundial, no sólo no dé ninguna ventaja, sino que acaba resultando contraproducente. ¿Quieres que veamos algunos de estos casos? Proyectos cerrados : Excusa : "Es que yo quiero xxxx para dentro de 30 meses y con un presupuesto cerrado de $$$ y con Scrum no puedo tenerlo" Explicación : Este punto parte de una base errónea que además es muy popular: "En Scrum está prohibido tener proyectos cerrados". No. En ningún sitio pone que esté prohibido tener proyectos cerrados y se puede trabajar perfectamente con Scrum un proyecto cerrado. ¿Pero, si la ventaja de Scrum es la adaptabilidad, para qué serviría en un caso como este? Pues justo para eso, para la adaptabilidad. La gran ventaja de Agile en general y Scrum en particular es que nos va a mostrar los problemas con muchísima antelación para que nosotros seamos capaces de adaptarnos, de forma que si vemos que no llegamos podemos aumentar el equipo (o reducirlo), adquirir nuevas herramientas que faciliten el desarrollo o cualquier punto que veamos que puede reconducir el problema. Si nos resultase imposible haciendo cambios de forma interna, tendremos que renegociar algo (alcance, coste y/o tiempo). Renegociar con mucha antelación da opción a que las condiciones puedan cambiar, mientras que si retrasamos dicha negociación hará que se complique o que las nuevas condiciones sean problemáticas para todas las partes. Si es imposible renegociar, posiblemente sea mejor cancelar un proyecto en el mes cinco que en el mes 29, que es lo que pasaría en caso de usar Waterfall (tendríamos muchos más gastos para llegar al mismo punto: No se puede hacer) Problema : Aquí el problema no es Scrum. Es el hecho de aceptar proyectos completamente cerrados en entornos complicados o complejos. Auto-engaño : "Es que mis clientes así lo exigen". MENTIRA (salvo que trabajes con la Administración Pública). ¿De verdad crees que RENFE exigió tener la mayor vergüenza de la ingeniería de software de la historia de España, en forma de una web donde los usuarios que querían hacer una compra sólo conseguían insatisfacción máxima? ¿No crees que si le hubieran dicho "Ey, renegociamos algo porque esto no tiene toda la calidad esperada" no hubieran preferido entregar con calidad un mes después o haber invertido un 5% más pero que los usuarios finales estuvieran contentos? Y si nos vamos al ejemplo inicial: ¿De verdad crees que, en un mundo como el actual donde cada poco tiempo sale algo totalmente novedoso, tu cliente quiere dentro de 30 meses algo que era útil hace 30 meses pero que en el momento de la entrega está obsoleto? ¿Y si durante ese tiempo sus necesidades han cambiado qué hacemos? ¿Le damos algo que ni quiere ni necesita sólo porque el proyecto era cerrado? ¿De verdad crees que ese cliente va a repetir con nosotros? Solución : Es tan sencillo como hablar con tus clientes y mostrarles, pero de verdad, que tu objetivo es su satisfacción y que para facilitar adaptarnos a sus necesidades y evitar casos "web de Renfe" debemos conocer qué podemos negociar en caso de ser necesario (aunque reflejemos qué, cuándo y con qué coste de forma inicial). Silos : Excusa : "Eso del Agile es sólo para los de IT" Explicación : Aunque hoy en día ya hablamos de Agile (y de Scrum) como algo aplicable a nivel multidisciplinar, es cierto que cuando ambas nacieron lo hicieron para dar solución a los problemas que la gestión clásica de proyectos provoca en el mundo del desarrollo software, así que puede llegar a entenderse que algunos puedan llegar a pensarlo. Ese pensamiento, sin embargo, también es una muestra muy obvia de que quien se encarga de promover Agile en la empresa: Está muy obsoleto. No tiene los conocimientos y experiencia necesarios para ese rol porque han puesto en esa labor a alguien con experiencia en gestión clásica. No está haciendo nada para lo que se supone que está contratado lo que facilitará el crecimiento de la cultura de la complaciencia en la organización. Puede que esta figura ni siquiera exista. Problema : La falta de alineación dentro de una organización provocará la creación de silos internos, retrasos en la puesta de valor del producto, burocracia, pérdida de creatividad en los equipos, falta de responsabilidad, etc. Todo ello hará que, en nuestra búsqueda de la satisfacción de nuestros clientes (o usuarios), no encontremos ventajas significantes y al final puede que se acabe volviendo a la gestión tradicional de proyectos. Auto-engaño : "Es que lo que yo necesito es poder cambiarle los requisitos a los informáticos, pero en el resto de departamentos eso no pasa". Error. Primero por lo de "cambiar los requisitos a los informáticos", porque eso muestra una cadena de "ordeno y se obedece", haciendo que los desarrolladores estén como veletas, lo que provocará que los equipos pierdan motivación, concentración y eficiencia. Segundo, por lo de que el resto de departamentos no necesitan adaptarse, puesto que la falta de ajuste en los planes de una parte de la empresa afectará al conjunto de la misma. Cuando trabajamos en Agile, lo que buscamos de forma constante es satisfacción de usuario, mejorar eficiencia de procesos, mejorar calidad de nuestro producto (o servicio), crecimiento constante de los equipos que desarrollan nuestro producto (o servicio) no sólo técnicamente sino también en cuanto a su motivación. Es muy difícil entender que esa mentalidad no vaya de la mano en toda la organización, sin excepciones. Solución : Agile es una mentalidad que pone el foco en la cultura de la excelencia, con los puntos vistos anteriormente (calidad, crecimiento, satisfacción...), y esta mentalidad tiene que estar en toda la compañía. Probablemente haya que eliminar la organización departamental para hacerla por producto. ¿Quieres que veamos más ejemplos? Sigue atento a esta página donde actualizaremos con más detalles o únete a la Newsletter donde las próximas entregas irán dedicadas a desmitificar bulos sobre Scrum y Agile.

Hace unas semanas una chica me preguntó por la certificación de Agile Coach que ofrece el PMI (Project Management Institue). Mi respuesta no podía ser otra que, aunque el saber no ocupa lugar y mientras más te formes mejor, yo no me centraría en esa certificación y el motivo que le di era muy sencillo: Si a mí me pide una empresa que les ayude a contratar a un Agile Coach y hay varios candidatos que me demuestran similares conocimientos y experiencia, yo no sólo no valoro como algo positivo tener certificaciones del PMI, sino que incluso prefiero a alguien que no tenga ninguna al que sólo tenga de esta institución. ¿Por qué? La mayor empresa en el mundo en las certificaciones de Project Management lleva desde 1969 defendiendo un punto de vista predictivo y una forma de trabajo en cascada que no encaja con la filosofía Agile. No está mal en entornos muy simples, pero en cuanto el entorno se complica un poco esta forma de trabajo en cascada ha demostrado una y otra vez su ineficacia, de ahí que naciera hace más de 20 años Agile y su manifesto, para hacer las cosas de una forma distinta. Cuando vieron que perdían el monopolio de las certificaciones en gestión de proyectos por una forma más óptima de trabajar se unieron al carro haciendo su propia certificación en Agile, defendiendo que Agile era perfectamente encajable en la gestión de proyectos tradicionales haciendo algo así como la imagen de este post (imagen de monolit-it.pl/2018/02/Water-Scrum-Fall ). Es decir, que cogen una gestión de proyectos en cascada y, dentro de la fase de desarrollo, es donde se hace un trabajo en iteraciones como si trabajar así ya te hiciera Agile. Algo similar (con otra imagen) es algo que publicó por X (twitter) la cuenta @PMIMadridSpain (si lo quieres, tengo el enlace aunque acabaron borrando el contenido por la burrada tan gorda que defendían, prometo que era mucho peor que lo de la imagen). Aunque podría llegar a entender que trabajes así si es tu primer día en una transformación Agile (y no estás siguiendo mis consejos), debes saber que haciendo esa mezcla, vas a tener las desventajas de los dos mundos (cascada y Agile) y sin ninguna ventaja reseñable ni a corto ni a largo plazo. Así que es muy difícil tomarse en serio a quien claramente demuestra su incompetencia (por desconocimiento, por mantener el status quo...) y nos enseña como caso ideal lo que claramente es una crónica de una muerte anunciada y motivo por el que Agile nunca funcionará en tu organización. Y de repente, para empezar el año, noticia bomba: El Project Management Institute y la Agile Alliance han anunciado el día 3 que se asocian: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ Esta noticia ha dejado perplejo a todo el mundo dentro de la Agilidad. ¿Cómo es posible que dos formas tan antagónicas de entender la gestión de proyectos se unan? De una parte una organización sin ánimo de lucro que busca promover y compartir la filosofía Agile y por otra una gran empresa que busca mantener su hegemonía como único referente en la gestión de proyectos. Pues para entenderlo basta con leer la letra pequeña: "As part of this process, Teresa Foster, Managing Director of Agile Alliance, and her team will transfer to PMI" Esto es como cuando una gran empresa energética recibe una ayuda del gobierno que nadie entiende y que perjudica al resto de ciudadanos, y luego vemos que los ministros que la aprobaron, casualmente pasan a la empresa como asesores... pues algo parecido. Por un lado, la Agile Alliance será subvencionada por la mayor empresa en el mundo de certificaciones de Project Management, y el PMI, que ya vendía certificaciones Agile, ahora dirá que su contenido es bueno porque viene avalado por la Agile Alliance por lo que venderá más; y todo ello mezclado con esas "puertas giratorias" donde los que aprueban la colaboración se llevarán "su comisión". Así que, al final, es el dinero el que nos ha llevado a esto. ¿Mi opinión? Yo me mantengo receloso de esta colaboración. El cambio que tendría que dar el PMI para moverse en la mentalidad Agile tendría que ser tan grande que, casi casi habría que refundarlo. También creo que sus certificaciones de Project Manager van a seguir defendiendo esa forma de trabajo predictivo que funciona, sí, pero sólo en entornos muy simples. Hoy en día, hay muchas empresas certificadoras sobre Agile en general (y Scrum en particular) que, con mayor o menor prestigio hacen una defensa de esta forma de trabajar mucho más óptima (y coherente), por lo que yo no me iría a obtener una validación profesional justo a las antípodas de esta forma de trabajar. Si quieres validar tu carrera como Project Manager tradicional, ve al PMI. Si lo que quieres es validar tu evolución en Agile (y Scrum), que es lo que ahora más demanda el mercado, mi primera opción sería el PSM I de scrum.org (que puedes conseguir con mis cursos de Scrum ), siendo igual de válidas para la mayoría de las ofertas de trabajo hacerlo con EuropeanScrum o CertJoin (ambas también se pueden conseguir con mis formaciones ) o incluso Scrum Manager, Scrum Alliance y otras certificadoras. ¿Quién sabe? Igual, como he visto bromear en algún foro sobre este tema, dentro de poco nos encontramos con que el PMI ha abierto la certificación de "Agile Project Manager" o alguna aberración similar. Habrá que estar atento. ¿Y tú qué opinas sobre esto?

Diferencias entre el Agile Coach y el Scrum Master

Encontrarás la solución pasito a pasito

10 similitudes entre Scrum y un cuchillo

¡Celebra los fallos!