Antonio Jesús Ruiz

El Scrum Team trabaja colectivamente

Tue, 18 Nov 2025 11:21:15 GMT

El equipo multidisciplinar

Reconozco que muchas veces me cuesta pensar un tema sobre el que escribir. ¿Qué queda sobre lo que ya no se haya escrito?

Esta vez no ha sido el caso: Hace unos días hice una formación presencial donde surgió el debate de cómo deberían ser los equipos, donde un asistente preguntaba cómo encajar a los equipos especialistas (y aquí puedes poner desde QA, base de datos, integración, arquitectura, legal, asesores expertos en un tema... elige el que quieras). Esta mañana, abro mi email y veo un correo de Steven Deneir de un artículo en el que desmitificaba que "colectivamente" tenga algo que ver con "todo el mundo sabe hacer de todo". Así que ahí vi la luz y me puse a escribir.

¿Qué nos dice la Guía de Scrum sobre esto?

La Guía nos dice:

Scrum involucra a grupos de personas que, colectivamente, poseen todas las habilidades y la experiencia necesarias para realizar el trabajo y compartir o adquirir dichas habilidades según sea necesario.
Los equipos Scrum son multidisciplinares, lo que significa que sus miembros poseen todas las habilidades necesarias para crear valor en cada Sprint.

Esto implica que no existen equipos especializados, sino que tendremos equipos multifuncionales. Por ejemplo, yo no trabajaré en el departamento de QA, sino que seré el QA en el equipo A para el producto X.

Por si lo estás pensando, la respuesta es sí, puedes estar en más de un equipo a la vez, aunque el rendimiento empeorará. Valora bien todas las opciones antes de optar por esa solución.

Esto no significa, que personas con perfiles similares, no puedan reunirse cíclicamente para compartir herramientas, experiencias, descubrimientos, etc. con el objetivo de mejorar globalmente en la organización. No sólo no está prohibido, sino que sería una práctica altamente recomendable en una organización que fomente la cultura de la excelencia.

¿Qué significa multidisciplinar?

La multidisciplinariedad significa que cada equipo tiene todo el conocimiento necesario para realizar cierta tarea. No significa que todos los miembros sepan hacer de todo, sino que el equipo, en su conjunto, con su variedad de perfiles que lo compone, sabe hacer de todo.

Esto implica que:

Si para entregar valor se necesita una habilidad o conocimiento en concreto, al menos alguien en el equipo debe tenerlo.
Si sólo una persona lo tiene, el equipo es frágil y sensible a posibles imprevistos. El trabajo del equipo se verá reducido cada vez que dicha persona no esté disponible por el motivo que sea. Además es una puerta abierta a cuellos de botella.
Si varias personas lo tienen aumentará la resiliencia. El trabajo en parejas, la mentoría y la curiosidad ayudarán a difundir el conocimiento a lo largo del tiempo.

Si trabajas como Scrum Master, una de tus funciones es la de fomentar el crecimiento individual y colectivo del equipo, por lo que deberías animar a que los compañeros del equipo sigan creciendo en aquello que controlan, pero que también se interesen en perfiles en los que puedan ser útiles al resto del equipo. Con ello no se pretende que todo el mundo sepa de todo, ni que podamos sustituir a un especialista, pero sí que conseguiremos evitar bloqueos del equipo. Eso sí, es imprescindible no forzar ni obligar a los compañeros a aprender aquello que no quieren hacer, sino convencer de la importancia del crecimiento continuo para que sean ellos los que elijan aquello que más les llame la atención.

Algunas de las preguntas que puedes hacer en el equipo, probablemente en la Retro, son:

¿Qué habilidades son absolutamente esenciales para aportar valor en cada Sprint?
¿En qué casos dependemos demasiado de una sola persona?
¿Quién quiere desarrollar una nueva habilidad? ¿Quién quiere ser mentor?
¿Cómo hacemos que el aprendizaje sea visible y llegue a todos los interesados?

La multidisciplinariedad es un proceso continuo e infinito en el equipo. Comienza con una persona que tiene un perfil o habilidad concreta y va creciendo a medida que otros aprenden, comparten y adquieren dicha habilidad.

El rápido auge y evolución de la tecnología, mercados y necesidades de los usuarios nos obliga a esta evolución constante.

Así que ya sabes, la próxima vez que alguien te pregunte por "¿Y el equipo de pruebas dónde encaja?", ya sabes que la respuesta es "ese perfil ya existe dentro del Scrum Team, y de no haberlo, alguien de pruebas se incorporará al Scrum Team.

Trabaja cada Sprint como si fuese el último

Tue, 14 Oct 2025 09:14:46 GMT

"Si este fuera nuestro último Sprint, ¿en qué nos centraríamos?"

Esta pregunta es perfecta para equipos que parecen atrapados en la rutina o que simplemente se dejan llevar por el trabajo diario. Ayuda a enfocar las cosas. Con demasiada frecuencia, asumimos que el próximo Sprint estará allí para limpiar las cosas, refinar el backlog, corregir algún error o probar alguna propuesta de mejora. Pero la verdad es que el próximo Sprint no está garantizado. Las startups lo saben muy bien.

Cuando un equipo cae en el ritmo de los Sprints sin propósito, todo comienza a parecer mecánico. En el Sprint Planning se intenta encajar trabajo en lugar de centrarse en objetivos de valor. El Daily Scrum se parece más a una actualización de estado que una oportunidad para inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el plan. Los Sprint Review se convierten en demostraciones sin feedback . Las retrospectivas son repetitivas y/o inútiles.

Los equipos así, aunque pueden estar siguiendo Scrum correctamente en cuanto a su literalidad, no lo hacen en su esencia. Y cuanto más se estancan en la comodidad, la entrega de valor se produce casi más por accidente que por intención.

Trabajar cada Sprint como si fuese el último no significa hacer las cosas rápido y sin sentido, sino aportar urgencia, intencionalidad y claridad al trabajo. Esto es:

Tomar decisiones basadas en lo que ofrece el mayor valor ahora y no en aquello que nos resulta más cómodo o fácil de hacer.
Tratar el Objetivo del Sprint como un compromiso que vale la pena proteger.
Decir no a las distracciones que amenazan la concentración.
Pedir feedback de los interesados.
Tomarse en serio las propuestas de mejoras en las retrospectivas y llevarlas a cabo.
Aprovechar el DoD para garantizar la calidad.

Cuando un equipo cree que ésta podría ser su única oportunidad de ofrecer algo significativo, aporta un nivel diferente de energía y de involucración, se mejora la priorización, las conversaciones son más profundas y se centran en lo importante, y la colaboración pasa de ser algo opcional a ser esencial.

Sin un sentido de urgencia, los equipos caen en un bucle de retraso y dejadez:

"Ya lo haremos en el siguiente Sprint ".
"Ya veremos ese punto en alguna futura retrospectiva".
"No estamos seguros de por qué estamos desarrollando esto, pero hagámoslo igualmente".
Los interesados no están involucrados porque dejan de ver un progreso significativo y valioso.
Los equipos pierden de vista la visión y el objetivo del producto, centrándose solamente en las tareas a realizar.

Con el tiempo, esto conduce a una moral más baja dentro del equipo, menos confianza de los interesados y un valor inferior con respecto al que podríamos haber dado.

Si posteriormente algo cambia, como puede ser un cambio en la reorganización de un equipo, la pérdida de prioridad de un producto o el cambio de prioridades de una organización (nuevos mercados, distinta visión/misión, etc.), esas oportunidades perdidas ya no se pueden recuperar.

De ahí que es una buena idea plantearnos al principio de cada Sprint :

"¿Si este fuera nuestro último Sprint, qué ofreceríamos? ¿Qué mejoraríamos? ¿Qué dejaríamos ir?"

Esta pregunta nos exige que seamos muy claros, pone el valor a aportar como lo más importante que vamos a desarrollar (candidato, por tanto, a ser Sprint Goal) y alinea al equipo, no solo en torno a lo que están haciendo, sino también en por qué lo están haciendo.

Como comento en las formaciones, el foco del equipo debe estar siempre en finalizar cosas, con esa influencia del PO para maximizar el valor del producto. Si el equipo no está trabajando como si fuese el último Sprint puede ser por alguno de estos motivos:

El equipo no está empoderado. Aquí el equipo no tiene poder de decisión sobre qué vamos a trabajar y perderemos parte de la fuerza que Scrum nos da.
El equipo no conoce, ni vive, los pilares y valores de Scrum. No basta con hacer Scrum, hay que vivir la filosofía Agile que acompaña al marco para que realmente se aproveche al máximo.

Independientemente de si es un motivo u otro, la base del problema es común: La experiencia y/o formación del Scrum Master es deficiente y hay que mejorarla. Un Scrum Master con experiencia y conocimientos trabajará para que uno de los focos del equipo sea la maximización de la eficiencia.

Entrada basada en el artículo " Run Every Sprint as If It Were Your Last " de Chris Belknap

Haciendo estimaciones: El modelo Montecarlo

Tue, 10 Jun 2025 11:11:21 GMT

Prediciendo el futuro

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

¿Por qué los Desarrolladores odian Scrum?

Mon, 12 May 2025 16:21:06 GMT

No llames Scrum a lo que no es Scrum

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

Scrum es muy simple

Mon, 14 Apr 2025 11:22:44 GMT

¿Entonces por qué la mayoría de las organizaciones lo sigue haciendo mal?

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

Scrum no funciona

Tue, 11 Feb 2025 13:00:10 GMT

Desmitificamos bulos sobre Agile&Scrum

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.

¡PMI y Agile Alliance se unen!

Fri, 10 Jan 2025 10:19:30 GMT

Puede parecer una broma, pero ha pasado.

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?

¿Qué hace un Agile Coach?

Thu, 14 Nov 2024 15:03:13 GMT

Diferencias entre el Agile Coach y el Scrum Master

En muchas formaciones de Scrum Master me preguntan por el curso de Agile Coach y qué diferencia hay entre ambos roles. ¿Lo vemos?

¿Qué hace un Agile Coach?

Un Agile Coach es una figura cuya función es la de acompañar, aconsejar, formar, orientar, recomendar y guiar a una organización (equipos y/o individuos) en su camino a la Agilidad.

¿Qué características tiene un Agile Coach?

Un buen Agile Coach tiene que destacar por:

Sus " soft-skills ", o lo que es lo mismo, por su empatía, su escucha activa, su capacidad para lanzar preguntas poderosas, por cuestionarse el status quo , por no ser protagonista sino dejar que lo sea a quien estemos acompañando, etc.
Gran conocedor del mundo Agile: Basado en la observación y su experiencia, el Agile Coach podrá recomendar la contratación de un experto en un marco de trabajo en concreto. Para poder hacerlo con garantías necesita conocer distintos marcos. Aunque no los conozca en detalle (es imposible conocer absolutamente todo en detalle), al menos sí debe saber qué ofrece cada uno y en qué caso usar uno u otro.
Es Agile. Sí, porque Agile no se hace, Agile se es. Esa mentalidad o filosofía que tenemos con Agile la lleva consigo siempre, incluso en su vida personal. Los marcos de trabajo, sin la mentalidad correcta, no sirven para nada.
Es un líder. Pero un líder con el ejemplo. No sólo hacemos lo que dice, sino que sobre todo hacemos lo que hace.
Tiene experiencia en procesos de transformación y cambio a nivel de toda la organización.

¿Qué diferencia hay entre un Agile Coach y un Scrum Master?

Entre un buen Agile Coach y un buen Scrum Master hay muy poquitas diferencias. Un buen Scrum Master tiene los "soft-skills" igual que el Agile Coach. Es "Agile" igual. Es un líder igual. Y también es un gran conocedor del mundo Agile, al fin y al cabo, el marco Scrum te permite (y es altamente recomendado) usar técnicas de otros marcos de trabajo.

Quizás en este último es donde tengamos el mayor matiz: Mientras que un Scrum Master usa siempre Scrum y le añade técnicas de otros marcos para complementar el desarrollo del producto con el que trabajemos, un Agile Coach puede recomendar un marco distinto de Scrum según sea el caso o la necesidad de nuestro cliente. Esto no quiere decir que el Scrum Master haga mal su trabajo, puesto que el marco Scrum se puede aplicar en casi todas las casuísticas, aunque no en el 100% de ellas.

En cuanto a la experiencia en transformación, no es obligatorio que la tenga un Scrum Master, aunque le da un plus de valía tenerla.

Además de esos puntos también hay diferencia en el trabajo que hace. Un Scrum Master trabaja bajo el marco de Scrum en uno o varios equipos (y también con la organización) en su adopción y entendimiento, de ahí que sea un rol que debe estar siempre en la empresa.

Un Agile Coach no trabaja dentro de Scrum sino de Agile en general acompañando a toda la organización en su camino hacia la agilidad, lo que lo hace un rol temporal. Una vez la organización ha llegado al nivel que esperaba tener el Agile Coach deja de ser necesario.

¿Cuándo debo tener un Agile Coach en mi empresa?

Cuando se dé una (o más) de estas casuísticas:

La satisfacción de mis clientes/usuarios está bajando (o es baja).
La calidad de mis productos está bajando (o es baja).
La satisfacción de las personas que trabajan en mi organización está bajando (o es baja).
Hay mucha rotación de personal.
Mis equipos no son capaces de entregar valor a mis clientes/usuarios con la suficiente frecuencia (un mes o menos).
Al ambiente laboral no es bueno y/o no se trabaja de forma colaborativa.

En cuanto tenemos alguno de los problemas enumerados anteriormente tenemos que plantearnos trabajar de forma más Ágil. Agile no es el objetivo cuando hacemos una transformación. Agile es el camino que va a resolver algunos problemas y ése sí es el verdadero objetivo: Mejorar, crecer, optimizar, perfeccionar...

¿Qué NO es un Agile Coach? Mitos y verdades sobre este rol

Hay algunos mitos sobre el Agile Coach que son falsos:

"Un Agile Coach es un Scrum Master con experiencia": Falso
Un Scrum Master con experiencia es un Scrum Master con experiencia. Es demasiado habitual encontrarse en LinkedIn con gente con 3 meses de experiencia como Scrum Master autodenominarse como Agile Coach. Para ejercer como Agile Coach, tu experiencia debe ser como Agile Coach. Es cierto que un (muy buen) Scrum Master puede ejercer de Agile Coach en otra empresa, pero por defecto no es suficiente la experiencia como Scrum Master.
"El Agile Coach trabaja con Management y el Scrum Master con los equipos": Falso
Un Agile Coach no trabaja exclusivamente con Management sino que también trabaja con los equipos y los distintos individuos.
Un Scrum Master no sólo trabaja con los equipos sino también con la organización y la guía de Scrum lo deja bien claro:
" Scrum Masters are true leaders who serve the Scrum Team and the larger organization .
The Scrum Master serves the organization in several ways, including:
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
Removing barriers between stakeholders and Scrum Teams. "
"El Agile Coach es el jefe del Scrum Master (o el Scrum Master reporta al Agile Coach)": Falso
Cada uno tiene sus responsabilidades, pero ninguno es el jefe del otro. El objetivo de toda la organización es el mismo (satisfacción de cliente/usuario) y aquí no se buscan jefes, sino distintos perfiles que todos sumen para conseguir el objetivo. Ambos roles se compenetran y coordinan buscando lo mejor para la organización y los equipos. Un Agile Coach no es más (ni menos) que un Scrum Master.
"Tener un Agile Coach te asegurará hacer Agile": Falso
Para empezar, Agile no se hace. Agile se es.
Y luego tener un Agile Coach no es garantía de nada. Primero porque en el Agile Coach hay que confiar. Si tienes un Agile Coach en el que no confías o si ignoras sus recomendaciones no vas a tener resultado. Luego también está la experiencia y conocimientos de ese Agile Coach. Por último, aunque un buen Agile Coach te va a ayudar a alcanzar tus metas, la última palabra sobre las decisiones las tomas tú, por lo que puedes perder potencial de mejora si sólo avanzas de forma parcial.
"Como tengo a un Agile Coach, entonces soy Agile. Ya hago Retrospectivas y uso Jira como me ha dicho": Falso
No todo el mundo que asegura ser Agile Coach lo es de verdad. Hay mucho "Agile Cosmético" que te dice que hagas alguna reunión y uses la herramienta X de la que además se lleva comisión por cada licencia vendida. Generalmente esto pasa cuando el Agile Coach viene de una consultora.
Un Agile Coach que no se replantee el "status quo" y no se plantee mover los cimientos de la organización para moverla al completo hacia la Agilidad no es un buen Agile Coach y tendrás un gasto (seguramente grande si va de una consultora) y no vas a tener ninguna ventaja. Al contrario. Al final acabarás diciendo "Hemos probado eso de Agile y con nosotros no funciona" y te estarás auto-engañando, porque "probar eso de Agile" pero haciéndolo mal a todos los niveles es normal que no te haya funcionado, de ahí la importancia de que el Agile Coach tenga experiencia y sea conocido y reconocido.
"Los informáticos ya hacen Scrum, por lo que no necesito un Agile Coach": ¿Falso? ¿Verdadero? Depende...
Que ya tengas a un grupo en tu organización haciendo Scrum es bueno, pero no sé si es suficiente. Si el Scrum Master que tienen está moviendo esta cultura por toda la organización y estáis dando pasos (pequeñitos pero firmes) hacia la Agilidad, no necesitas a un Agile Coach.
Sin embargo, si el Scrum Master se dedica sólo a reservar salas, a tomar notas y moverse exclusivamente dentro de los equipos (que es su zona de confort) sin promover cambios más allá, entonces "Houston, tenéis un problema": Sí necesitáis a un Agile Coach.

¿Y qué hago en caso de necesitar a un Agile Coach en mi organización?

Mi recomendación sería hacer una Consultoría Ágil en la que personalmente puedo ejercer como Agile Coach o bien te recomendaré a alguien de mi completa confianza para que te asegures que quien te acompañe tenga esa experiencia y conocimientos que hagan que tu organización avance, crezca y se optimice al ritmo que esperas.

¿Y si quiero hacerme Agile Coach?

¡Enhorabuena! Así se empieza, con un objetivo. El primer paso sería formarte como Agile Coach y a partir de ahí ir dando pasitos donde ir aumentando tu experiencia. Dependiendo de tu perfil y experiencia puede que al principio tengas que ir acompañado por alguien con más experiencia para poco a poco poder ir haciendo cosas de forma más autónoma.

¿Y tú? ¿Te animas a convertirte en Agile Coach?

¿Entorno complicado? Piensa como un niño

Thu, 10 Oct 2024 10:47:00 GMT

Encontrarás la solución pasito a pasito

Hace unos años leí un artículo donde explicaban un caso hipotético que mostraba un ejemplo de lo que sería un entorno complicado/complejo. He intentado localizarlo para indicar aquí la fuente, pero no lo he encontrado. Decía algo así como: "Imagina que estás en una habitación donde hay una silla. Tu objetivo es sentarte en ella, pero cada vez que te mueves por la habitación la luz se apaga y todo se queda a oscuras. Si te paras, la luz se vuelve a encender, pero la silla puede estar en el mismo lugar o haber cambiado de sitio. ¿Qué harías?"

Ese ejemplo muestra claramente un entorno complejo: Aunque avances donde tú crees que está tu objetivo, realmente no hay absolutamente ninguna certeza de que estés avanzando hacia lo que tus clientes necesitan hoy. Lo más que puedes decir es que avanzas hacia el problema que tenían.

Ese mismo artículo comentaba que si se exponía ese problema a un niño pequeño, daba la siguiente solución: "Daría un paso pequeño y me pararía. Vería si la silla sigue estando en su sitio o se ha movido, y luego daría otro paso pequeño. Así tantas veces como necesite hasta llegar a la silla"

Con Scrum en particular y Agile en general, lo que hacemos para intentar llegar a nuestro objetivo en entornos muy complejos es algo similar: Damos pasos pequeños hacia donde creemos que puede estar la solución, pero en lugar de seguir avanzando con el riesgo que conlleva avanzar para nada, validamos que las necesidades de nuestro clientes, usuarios, mercado, etc... siguen siendo las mismas que tenían antes. ¿Lo son y el paso que dimos antes nos acerca a ellas? Pues damos otro paso más en la misma dirección y volvemos a validar. ¿Las necesidades han cambiado y/o el paso no iba en la dirección correcta? Pues cambiamos la dirección para intentar acercanos lo más posible y volvemos a validar.

Con esto: evitamos reprocesados, reducimos riesgos, mejoramos resultados y nos aseguramos de buscar la satisfacción de nuestros clientes/usuarios en todo momento.

Demasiadas veces se intentan dar soluciones macro complejas cuando la solución a este tipo de casos es poner el foco en la simplicidad (procesos, propuestas, soluciones), e incluso comenzar a pensar como lo haría un niño: Reduce (y si puedes elimina) aquello que no sume, aquello que te retrase, aquello que provoque riesgos innecesarios y pueda causar insatisfacción de nuestros clientes/usuarios.

¿Y tú cuándo fue la última vez que pensaste como un niño para optimizar tu forma de trabajar?

Scrum es un cuchillo

Thu, 05 Sep 2024 08:49:15 GMT

10 similitudes entre Scrum y un cuchillo

Estaba dándole vueltas a cómo podría explicar qué es Scrum de una forma distinta a como lo he hecho siempre y de repente se me vino a la mente la sección "Si fuera..." del programa de "Hola Rafaella" (Si no lo conoces, era una sección donde se intentaba adivinar un personaje con pistas asociadas a preguntar "Si fuera xxx". Si ya lo conocías, entonces has sido de los primeros en vacunarte del Covid, ¿verdad? :-P)

Y ahí empecé a jugar con Scrum y el "Si fuera..." con un cuchillo y he podido encontrar 10 similitudes entre ambos. ¿Las vemos juntos y me dices si encuentras más analogías?

Ya sabes que si quieres convertirte en un experto en " cuchillos " y dar el salto profesional que llevas tiempo esperando para ofrecer a tu organización el nivel competitivo que requieren los tiempos actuales, te espero en cualquiera de mis formaciones .

Si lo que necesitas es " afilar tus cuchillos " de nuevo, mejor hacemos una Consultoría Agile .

Si el equipo nunca falla, tienes un problema.

Sun, 05 May 2024 17:35:00 GMT

¡Celebra los fallos!

Vamos a empezar por lo más básico de todo: Scrum es un marco de trabajo que, para que funcione bien de verdad, necesita ir acompañado de la filosofía Agile reflejada en el Agile Manifesto. Esta filosofía lo que nos dice, entre otras cosas, es que los individuos son más importantes que los procesos o las herramientas y que tenemos que fomentar y favorecer su auto-organización, motivación y crecimiento.

Para el crecimiento del equipo, el propio Manifesto ya prevé 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" y para cubrir ese punto en Scrum tenemos un evento llamado Sprint Retrospective, donde evaluamos cómo podemos mejorar como grupo.

A la hora de ver cómo seguir mejorando podemos centrarnos en ver qué hemos hecho bien para asegurarnos de que se mantiene o incluso se mejora; y qué no hemos hecho bien para corregirlo o eliminarlo según sea el caso.

Eso sí, al ver en qué hemos fallado, podríamos caer en la tentación de buscar culpables para luego poner su foto en un "muro de la vergüenza" u otra forma similar de que la persona quede marcada y el fallo reflejado. Con eso muy probablemente los miembros del equipo quieran evitar ver su nombre asociado con cualquier tipo de represalia, señalamiento y/o castigo y por tanto dejen de fallar.

¡Enhorabuena! Ya has conseguido que el equipo no falle. Ahora deberías presentar tu dimisión por incompetente porque acabas de fastidiar a todo el equipo.

Si un equipo nota que el fallo se castiga, el equipo dejará de fallar, pero eso implicará que los miembros del equipo se mantendrán siempre en su zona de confort haciendo sólo aquello que saben hacer. Por tanto, dejarán de probar cosas nuevas, dejarán de investigar, dejarán de aprender y se atascarán tanto personal como profesionalmente, lo cual repercutirá también en la calidad del producto y por ende en la satisfacción de nuestros usuarios.

Nunca castigues un error. Al contrario. ¡Los fallos se celebran! Porque reflejan que el equipo se esfuerza por hacer cosas difíciles y que salen de su zona de confort buscando qué es lo mejor para nuestros usuarios. De los fallos se aprende y siempre podemos sacar conclusiones que ayuden al equipo en su crecimiento, tanto individual como colectivo.

Los niños aprenden equivocándose y, los profesionales del desarrollo de un producto complejo también. Tienen que ir aprendiendo continuamente sobre el entorno (producto, herramientas, características, usuarios finales, etc.) equivocándose y aprovechando lo aprendido para que el equipo lo aproveche.

Además, recuerda que los valores de Scrum promueven que el error ocurra sin que se pueda ver como un drama:
Por un lado el Respeto impide cualquier tipo de represalia y por otro el Coraje invita a los miembros del equipo a salir de su zona de confort y probar aquello que pueda ser bueno para nuestro producto/cliente/usuario.

El problema de los "deadlines"

Sun, 03 Mar 2024 19:46:23 GMT

La absurda necesidad de vender certeza en la incertidumbre

¿De verdad hace falta que vuelva a poner la web de Renfe como ejemplo de lo que las fechas límites o "deadlines" acaban provocando?

Las fechas topes en un proyecto no es que no motiven, es que destruyen la motivación.

Sin embargo es fácil encontrar a mánagers imponiendo dichas fechas en un desesperado y absurdo intento de vender certeza en medio de la incertidumbre.

En mi última formación comentábamos un ejemplo muy sencillo: "Si me dedico a hacer cucharillas, siempre las hago exactamente iguales, no hay cambios ni en la forma de hacerlo ni en la forma de la cucharilla y en mis 25 años de experiencia sé que siempre hago mil cucharillas al día, si me preguntan cuándo podré entregar cinco mil cucharillas puedo decir con una altísima probabilidad de acierto que lo entregaré en cinco días". ¿Por qué? Porque es un ejemplo de un entorno muy simple y por lo tanto predecible (lo que no significa que no pueda pasar nada en esos cinco días que provoque un retraso, como una enfermedad, por ejemplo).

Sin embargo, en un entorno complicado o complejo donde tenemos que ir ajustando nuestro producto a las necesidades del cliente, donde no hay dos productos iguales, donde la tecnología y/o herramientas a usar van cambiando cada poco tiempo, no tiene sentido tener un "deadline", porque no es posible hacer predicciones sin una evidencia previa.

¿Qué ocurre cuando ponemos una fecha límite a nuestro proyecto en un entorno complejo?

El miedo a no cumplir el plazo reduce la transparencia.
No queda espacio para el aprendizaje, lo que paraliza la necesaria evolución del producto.
El estrés de entregar a tiempo conduce a tomar atajos, eliminando el foco en la calidad.
Evitar sentirse culpable y señalado por los plazos incumplidos reduce el trabajo en equipo.
La ansiedad por empezar aumenta el trabajo en progreso y los pasos en falso, y es por tanto el inicio de los retrasos.

¿Y qué pasa cuando lo importante no es la fecha límite?

Simple: Sin estrés por los plazos, los equipos tendrán espacio para llegar al producto correcto, de la manera correcta y en el momento correcto.

¿Entonces por qué al inicio de un proyecto aparece un gerente que nos impone un "deadline"?

Porque todos los demás lo hacen así.
No conoce toda la verdad.
Por miedo a la pereza del equipo.
La excepción se ha convertido en regla.
Porque su jefe/cliente/stakeholder se lo requiere.

Veamos por qué ocurre y cómo ponerle remedio:

1 - Porque todos los demás lo hacen así.

La presión de grupo por homogeneizar puede logar mantener vivo un mal hábito.

Cuando todos los demás establecen plazos, es fácil alinearse. Y es extremadamente difícil ser quien no se deja llevar por la corriente.

El miedo a ser culpado y señalado por romper con el hábito de los plazos es habitual para todos.

El remedio: Ten el coraje de romper el patrón.

Ésta es la parte difícil.

Cada movimiento exitoso fuera del comportamiento de fecha límite ha requerido un acto de puro coraje. Alguien tenía que tomar una posición.

Es posible que la espera por la seguridad nunca suceda en un entorno basado en plazos.

Decir “no” a los plazos puede resultar convincente viniendo de un ejecutivo. Aquí el movimiento sería contagioso y duradero.

Pero no hay que descartar el poder del coraje en ningún nivel del organigrama. Forma una tribu de promotores, une fuerzas con tu equipo u obtén el apoyo de tu líder.

Todo lo que se necesita es un éxito sin fecha límite para generar impulso hacia un futuro sin fecha límite.

2 - No conoce toda la verdad.

Los gerentes a menudo descubren que están a oscuras, sin ser conscientes de los problemas (debido a los propios perversos ciclos de plazos).

Se fijan plazos (" deadlines ") para impulsar la urgencia y combatir la incertidumbre.
El incumplimiento de dichos plazos genera culpa.
La culpa lleva al miedo.
El miedo lleva a ocultar el problema.
Ocultar el problema conduce a más plazos y hace que el ciclo de culpa se retroalimente.

Los plazos acaban formando una olla a presión en los esfuerzos de productos inciertos, provocando que la transparencia caiga en picado.

El remedio: Acepta la verdad cuando la obtengas.

Rompe el patrón al no culpar.

Cuando la verdad no es lo que quieres escuchar, abraza y celebra el problema. Entonces generarás confianza y le darás a tu equipo valor para plantear problemas de manera oportuna.

Además, y posiblemente más importante, no establezcas plazos falsos sólo por motivar.

3 - Por miedo a la pereza del equipo.

"Pero si no tienen una fecha límite, se equivocarán".

Para algunos gerentes, no tener fecha límite es el camino más rápido para que el equipo se tome el día libre para jugar videojuegos. Para ellos, la ausencia de plazos conduce a un esfuerzo mínimo. Sin embargo, utilizar plazos para motivar es elegir el palo en lugar de la zanahoria.

El remedio: Confía en los profesionales que contrató e inspírales.

¿Estás rodeado de profesionales? Entonces, trátalos como tales. Trabaja con ellos para crear un propósito inspirador y objetivos de producto significativos. Y apóyalos cuando necesiten tu ayuda para superar obstáculos que no pueden eliminar.

Un equipo inspirado y autoorganizado hacia una meta significativa, eclipsa a cualquier equipo que se esfuerza por cumplir con una fecha límite sólo por tenerla.

4 - La excepción se ha convertido en regla.

“Pero existen plazos reales. Piensa en el Black Friday, el día de los impuestos, etc."

Por supuesto que pueden existir limitaciones de fechas legítimas. Pero ese no es el problema. El problema es cuando todo tiene un plazo, independientemente de la necesidad.

Las limitaciones de fechas reales existen, pero son la excepción, no la regla.

El remedio: dejar que los plazos sigan siendo excepciones y evitar que se pongan en riesgo.

Cuando existan limitaciones de fechas reales, implementa contramedidas de reducción de riesgos.

Inclínate más por la acción que por el plan.
Experimenta, aprende temprano y con frecuencia.
Utiliza la evidencia para trazar el mejor y más corto camino hacia su objetivo.
Encuentra la solución más simple para satisfacer las necesidades de tu usuario y di "No" a lo no sea esencial.
Concéntrate en terminar una cosa a la vez, no en empezar todo de una vez.

No permitas que la excepción se convierta en la regla, pero sé inteligente cuando sí lo necesites realmente.

5 - Porque su jefe/cliente/stakeholder se lo requiere.

“¿Cuándo estará hecho?”

Dios mío, la temida pregunta. A todos nos han preguntado esto alguna vez. La presión para complacer a nuestros clientes (o jefes) es intensa. Este es tu momento de la verdad como gerente. Y normalmente llega al principio: el momento de mayor incertidumbre.

El camino desafortunado suele ser el de hacer una promesa y fijar un plazo para el equipo. Y a partir de ahí ya todo irá de mal en peor.

El remedio: Invita a quienes soliciten una fecha a unirse al viaje.

No actúes como si tuvieras una bola de cristal.

Sé humilde. Di que no lo sabes con seguridad. En lugar de ofrecer una cita para parecer confiado, invítalos a unirse al equipo a lo largo del viaje.

Tus comentarios proporcionarán el aprendizaje que necesitan para ofrecer lo correcto en el menor tiempo posible.

Scrum como solución.

Como gerente, todos estos puntos los puedes paliar con un buen Scrum Team, con un Product Owner experto y muy empoderado y un gran Scrum Master que os guíe a la organización sobre qué puntos son necesarios y en cuáles se puede mejorar.

Recuerda que nuestro primer objetivo no puede ser nunca entregar en fecha, sino satisfacer al cliente con un producto usable y de valor que responda a sus necesidades actuales. ¿O acaso Renfe consiguió satisfacción cuando publicó su web en fecha?

En el curso de Scrum Master , vemos cómo optimizar tu flujo de trabajo y cómo afrontando los problemas con mucha antelación se facilita conseguir los hitos a corto, medio y largo plazo que nos vayamos proponiendo (los cuales revisaremos y moveremos en cada una de las iteraciones junto con los interesados en nuestro producto).

Esta entrada está basada en el artículo " The Inescapable Deadline: 5 Reasons Managers of Product Teams Keep Setting Them " de Todd Lankford

Estado de Agile en 2023

Fri, 02 Feb 2024 17:46:13 GMT

Evaluamos la progresión de Agile

Generalmente a finales de año, los compañeros de State Agile publican un conjunto de encuestas sobre el estado de la Agilidad a nivel general. Esta vez se han retrasado un poco y lo han hecho en enero, pero ya tienen su 17º State of Agile sobre 2023.

Personalmente hay muchos puntos que me preocupan y lo peor es que estoy convencido que los que lo están haciendo así están seguros que lo están haciendo correctamente porque tienen un "Agile Mánager" que así lo ha indicado (como si lo estuviera viendo). ¿Quieres que veamos juntos algunos de los detalles de esta encuesta que me chirrían?

Lo primero que llama la atención es que las pequeñas empresas siguen indicando que Agile tiene unas ventajas muy obvias para ellos como pueden ser la colaboración, la mejora de calidad del producto/servicio que realicen, alineación con negocio, etc... Sin embargo las medianas y grandes compañías no están tan satisfechas.
Para mí, un indicio claro de esa cultura obsoleta que sigue imperando en las grandes empresas donde los cambios son mínimos porque las cosas "siempre se han hecho así". Si no cambia la cultura, poca ventaja vas a obtener con cualquier marco Agile (sea el que sea).
A la hora de priorizar el desarrollo de un producto, y aunque es la opción más votada, no deja de sorprenderme que más de la mitad de los encuestados no hayan marcado la opción de la satisfacción del cliente final, cuando esa opción tendría que estar en el 100% de los casos.
Cuando se evalúa cómo conocer el éxito de un desarrollo, la mayoría de los encuestados afirman que se hace mediante métricas individuales del equipo, principalmente la velocidad.
El problema de esto es que, como comento en las formaciones, "lo que mides obtienes" y si centramos al equipo en la velocidad, tendremos velocidad, pero de la mano vienen los errores. Todo lo que no esté centrado en la calidad es una "red flag" que hay que estudiar.
"Agile es para los informáticos" es algo que también se refleja en la encuesta, cuando para que una compañía sea Agile de verdad lo tiene que ser a todos los niveles, sin excepción.
Y los problemas se conocen. Los encuestados indican por qué Agile no está dando todas las ventajas que deberían. ¿Entonces quién o qué está impidiendo que esa info se mueva en la compañía y provoque la adaptación necesaria? Muchas veces es el miedo a hablar dentro de la empresa o que algún superior corta de raíz cualquier comentario para que no llegue más arriba y así parezca que "todo va bien"
Cuando se habla del escalado, aparece SAFe como primera opción, lo cual explica muchísimas cosas sobre por qué Agile no les funciona a algunos, sobre todos a grandes empresas. La METODOLOGÍA de SAFe siempre es impuesta, nunca es propuesta y personalmente no conozco ningún Agile Coach al que considere como alguien a admirar que la recomiende, puesto que SAFe se pasa por el forro todos y cada uno de los principios y valores del Agile Manifesto.
También me sorprende ver cómo LeSS que sería la que probablemente yo usaría como primera opción o Nexus, que sería mi segunda candidata están tan abajo.
Y luego están los que han creado su propio marco... habría que verlo, porque sé de alguna gran empresa que tiene su "propio marco" y es igualito que SAFe.

Hay mucho contenido en la encuesta que es interesante, como qué tipo de herramientas se usa, cómo encaja DevOps, qué tipo de formación se ofrece, etc... que merece una lectura. Podrás encontrar la encuesta para descargar debajo..

Lo que sí me deja claro es que aún hay mucho, pero mucho margen de mejora. Si te ves reflejado en uno de estos 6 puntos igual es hora de que hagamos una consultoría en tu organización y saquemos el máximo rendimiento que ahora mismo se está perdiendo.

5 cosas que deberías dejar de hacer como Scrum Master

Sun, 07 Jan 2024 16:15:15 GMT

Deja de ser un buen Scrum Master para ser un gran Scrum Master

Un Scrum Master debe poner el foco en maximizar la eficiencia del equipo, pero no puede olvidar que él (o ella) es también parte de ese equipo y por tanto también tiene que buscar cómo ser más eficiente en su trabajo. Hay algunos puntos que, si bien no están mal por defecto, son cosas que con el tiempo debería dejar de hacer. Aquí tenemos algunos de esos puntos:

Centrarte únicamente en los eventos Scrum
Es cierto que el Scrum Master es responsable de la facilitación dentro del equipo. Citando la Guía Scrum 2020, el Scrum Master es responsable de:
"Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox."
Pero eso no significa que tengas que estar presente en cada Daily Scrum que haga el equipo, ni siquiera en todas las sesiones de refinamiento...Cuanto más aumenten las habilidades de facilitación de los Desarrolladores y del Product Owner, mejor será la autogestión del equipo.Como Scrum Master, debes poner el foco en tener un mayor impacto en el aumeno del nivel de madurez de tu equipo y dedicar más tiempo a provocar cambios que mejoren tu organización.
No involucrarte lo suficiente con los líderes de tu organización.
Ser Scrum Master debería ser uno de los primeros pasos hacia el liderazgo. Ser un verdadero líder también significa guiar, capacitar y asesorar a la organización, ayudando a tus compañeros y clientes a entender la importancia del enfoque empírico para entornos complejos e, incluso a veces, también es ser el líder que te gustaría tener.
Después de todo, la Guía Scrum 2020 establece que el Scrum Master es responsable de establecer Scrum mediante
"Helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."
Ser Scrum Master es el primer paso hacia el liderazgo en otros niveles de la organización. Tu equipo, tus compañeros, tu organización y tus clientes (y usuarios) se beneficiarán si llevas tu mentalidad empírica y tu liderazgo al servicio de los niveles más altos de la organización.
Quitar todos los impedimentos sin involucrar al equipo
Enseña, no resuelvas. Es cierto que el Scrum Master es responsable, según la Guía Scrum 2020 de
"Causing the removal of impediments to the Scrum Team’s progress."
Deja de pensar que el Scrum Master debería usar la capa de superhéroe y sea quien elimine todos los impedimentos porque no es así.
Un buen Scrum Scrum Master debería facilitar la eliminación de impedimentos y la mejor manera de eliminar los impedimentos es incorporando las habilidades y el conocimiento al equipo, de modo que los Desarrolladores puedan eliminar rápidamente cualquier obstáculo. También se pueden resolver las causas fundamentales de los impedimentos repetidos siendo un agente del cambio en la organización.
No acompañar ni formar al Product Owner sobre las interacciones con los interesados.
Sin una visión y unos objetivos del producto claros, cualquier equipo está destinado al fracaso. Un gran Scrum Master sabe cuándo su Product Owner necesita ayuda en esto. Estás ahí para ayudar a establecer una planificación empírica de productos en entornos complejos, facilitar la colaboración con los interesados o, incluso mejor aún, acompañar y formar a tu Product Owner para que pueda hacerlo por sí mismo, y trabajar con el equipo para que todos comprendan la necesidad de Elementos claros y concisos en el Product Backlog.
Quedarte dentro de la Guía Scrum
Scrum está genial, pero hay muchas otras cosas que pueden ayudar a tu equipo. La Guía de Scrum no cubre, intencionalmente, lo suficiente como para hacer un trabajo completo. Puntos como dinámica de equipo, pronósticos y estimaciones, desglose del trabajo, gestión de interesados, medición del valor, etc... los deja al criterio de los distintos equipos.
No tengas miedo en explorar otros marcos o prácticas y lleva su esencia a tus equipos. Prueba, experimenta y sigue probando para hacer mejores a tus equipos de Scrum.

El camino de ser un buen Scrum Master a uno excelente es desafiante y requiere mucho coraje. El primer paso es sacar a tu equipo y a tu organización del estancamiento (y el status quo) tomando las decisiones correctas, avanzando y convirtiéndote así en un mejor líder.

¿Quieres profundizar más? Echa un vistazo al curso de Scrum con certificación oficial aquí .

Esta entrada está basada en el artículo "What Are 5 Things Scrum Masters Should Stop Doing in 2024?" de Ciprian Banica

¿Y cuál es la función del Project Manager en Scrum?

Sun, 03 Dec 2023 14:04:45 GMT

Necesitamos menos "managers" y potenciar el "self-managment"

En mi última formación presencial, durante una pausa una chica me preguntó: "¿ Cuál es tu opinión sobre los Project Managers ?". Así que he pensado dedicar esta entrada a este tema tan tabú en muchas organizaciones.

La respuesta corta a "¿tiene sentido la figura del Project Manager en Scrum?" es un rotundo NO. Cada vez que veo que un equipo que asegura trabajar en Scrum, con sus Developers, su Scrum Master y su Product Owner tiene " encima " a un Project Manager lo que me dice con una probabilidad de acierto del 99,99% es: "Éstos aún no saben de qué va esto de Scrum".

Scrum, como marco de trabajo Agile que es, tiene muchísimas ventajas como la reducción del riesgo, la adaptabilidad, trabajo en equipo, gestión del conocimiento, mejora tanto de la calidad del producto (o servicio) como de la satisfacción de clientes (y usuarios) y del propio staff, etc... Pero para ello se requiere que se haga bien.

Uno de los puntos fundamentales para que Scrum sea un éxito, además de sus pilares y valores por supuesto, es el empoderamiento de todo el equipo y especialmente el del rol del Producto Owner donde todas sus decisiones buscando maximizar el valor del producto y la satisfacción del cliente deben ser respetadas. La guía de Scrum dice explícitamente lo siguiente: " For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review. "

Si las decisiones las toma el Product Owner y toda la organización debe respetarlas... ¿Qué sentido tiene tener un Project Manager? No hay nada que haga un Project Manager que no pueda hacer un Scrum Team auto-gestionado.

Son muchos los que me preguntan a veces: " ¿Pero si no tenemos Project Manager entonces quién nos da los requisitos? " Una pregunta que huele a naftalina y a mentalidad de fábrica del siglo XX (por no decir del XIX).
Para empezar no necesitamos "Requisitos" o "Requerimientos" porque entonces el equipo hará lo que se le "requiere" y perderemos la creatividad y la responsabilidad del equipo cuando lo que realmente tenemos que llevar en un entorno complejo son "Necesidades". Además, esas necesidades las llevará el propio Product Owner al equipo mediante el Product Backlog.

A algunos también les he oído decir eso de " Un Project Manager es un Product Owner con experiencia " (que son los mismos que también dicen una burrada similar como la de que " Un Agile Coach es un Scrum Master con experiencia ") y no pueden estar más alejados de la realidad: Un Project Manager es un gestor de proyectos que trabaja según las directrices que da la metodología del PMP (la cual puede ser útil en entornos muy simples), mientras que un Product Owner es un rol de Scrum. Cada uno en su mundo tiene sentido, pero no tiene ningún sentido mezclarlos (salvo que tengas muuuucho dinero y no sepas cómo gastarlo, entonces sí, contrata a mucha gente, dale puestos absurdos y asegúrate de dificultar el desarrollo poniendo trabas a los que se van a encargar de darle valor a tu producto/servicio... Nótese la ironía)

¿Significa esto entonces que no pueden existir mánagers si trabajamos realmente en Agile? Veamos qué dice Allen Holub, gurú del desarrollo software y uno de los firmantes del Agile Manifesto (aunque no en su creación):

Puedes hacer clic en la imagen para ir a la publicación en X

Me sumo a su comentario: La única respuesta correcta es "Nunca". Un equipo Scrum nunca debería tener la necesidad de hablar con ningún Manager, puesto que todo lo que necesita lo tiene en el propio equipo Scrum.

No obstante, eso no significa que el número de "mid-managment" en una empresa sea en todo caso de cero personas. Alguien tiene que encargarse de aquellas cosas que surgen fuera del propio equipo. Por ejemplo el equipo no se va a encargar de pagar las nóminas, pagar los impuestos de la organización o incluso el buscar a un Product Owner para expresarle una necesidad de negocio y pedirle que lidere la solución a esa necesidad.
La función de esos mánagers será la de apoyar, confiar y facilitar al equipo el trabajo para que el desarrollo se efectúe de la forma más óptima posible, basado siempre en las necesidades y solicitudes del propio equipo. O lo que es lo mismo: Management trabaja para el equipo y no el equipo trabaja para management.

Fomentando la auto-gestión conseguiremos en todo caso equipos más motivados y procesos más óptimos. Tendremos " más management con menos mánagers " y fomentaremos la idea de " Yo no trabajo para ti, yo trabajo contigo ".

Si en este punto te planteas " Vale, entiendo que el Project Manager no tiene sentido en Scrum, pero... ¿Y el Line Manager? ¿Y el Delivery Manager? ¿Y el [pon aquí lo que quieras] Manager? " Lo podemos ver más en detalle en futuro si lo necesitas, pero la respuesta rápida vuelve a ser: NO.
Que existan personas que quiten responsabilidad/es al equipo o haga cosas que un Scrum Team por sí solo (si realmente es auto-gestionado) debería poder hacer nos alejará de la excelencia y la optimización.

¿Quieres las ventajas de Scrum? Asegúrate de usarlo correctamente.
¿No sabes o lo intentas pero no lo consigues? Entonces contacta conmigo para que corrijamos esos detalles mediante una formación y/o una consultoría para buscar esa máxima eficiencia.

Diez consejos para el Scrum Master novato

Sun, 05 Nov 2023 12:57:41 GMT

Consejos para facilitarte tus primeros pasos como Scrum Master

Iniciar el trabajo como Scrum Master cuando no tienes experiencia en el rol puede llegar a ser frustrante al intentar abarcar muchos temas y buscar lo mejor para el equipo "pero sin el equipo". Todos los que hemos comenzado en el rol hemos cometido errores, pero lo importante es evaluar continuamente si cada acción que haces es la mejor o puede tener algún riesgo. Una vez evaluada toca adaptarse para mejorarla o cambiarla, dependiendo del resultado que se espere, y así una y otra vez.

En esta ocasión, os traigo diez consejos muy útiles para ese Scrum Master que comienza a trabajar en este rol:

¡No te apresures! Aprende a reducir la velocidad. Necesitarás tiempo. Convertir el conocimiento teórico en práctica no es fácil. Pueden pasar meses hasta que sientas que funciona y es beneficioso. No entres en pánico y no te sientas mal contigo mismo. No dejes de aprender y practicar.
Sé un buen observador, un oyente activo. Identifica la situación actual y las necesidades que puedan existir.
Mantente abierto al aprendizaje continuo. El proceso de aprendizaje nunca termina. En el momento en que digas: "Ahora soy un experto", surgirá nueva información, artículos y aplicaciones relacionadas con ese tema para desafiar lo que sabes.
Recuerda que Scrum es solo un marco; No olvides que hay tonos de gris. No podrás decir: "Esta es la forma correcta" para ningún enfoque o forma de trabjar. Navega por las áreas grises y encuentra el tono que mejor se adapte a tu equipo.
Trabajarás con personas que no conocen o malinterpretan tu trabajo. No te sorprendas. Recuerda, todo el mundo tiene derecho a no saber ciertas cosas. Tú también tienes derecho a explicarte. Cuando te encuentres con una persona así, ponte el sombrero de educador y enséñale en qué consiste es tu trabajo y en qué no.
No tienes que ser un experto en software. Si estás ansioso por aprender lo que hace tu equipo, este trabajo es para ti. Ponte el sombrero de entrenador y guía a tu equipo con preguntas poderosas.
No te avergüences de lo que no conoces. No se puede saber todo sobre Agile. Al fin y al cabo, siempre habrá algo nuevo. Decir "no sé" es una señal de respeto para aquellos que sí lo saben.
Recuerda, la base de Agile es la experimentación. Inténtalo, fracasa, inténtalo de otra manera.
No se pueden solucionar todos los problemas a la vez. Prioriza y concéntrate de uno en uno.
No te dejes atrapar demasiado por la certificación. No es lo más importante. No eres Scrum Master por "el papelito". Lo eres por la experiencia que eres capaz de llevar al equipo.

Esta entrada está basada en el artículo "SCRUM MASTERY: 10 TIPS YOU SHOULD KNOW AT THE BEGINNING" de Burcu Akın Şengün

¿Cómo te conviertes en Product Owner?

Fri, 06 Oct 2023 13:47:41 GMT

Charla de Octubre-23' del Agile-Coffee

Tras llevar un tiempo haciendo tareas como Desarrollador te ofrecen la oportunidad de trabajar como Product Owner. ¿Es esto posible? Sobre este tema hablamos en la última sesión que hicimos del "Agile-Coffee".

En esta ocasión contamos con algunos ex-alumnos que han compartido su experiencia con nosotros. Durante la sesión nos cuentan varios puntos en los que coinciden:

Todos comentaron la importancia de haber hecho la formación correspondiente, lo que les ha ayudado a conocer qué cosas hacían bien, dónde tenían que mejorar y algunas técnicas que le han facilitado su forma de trabajar.
También fue común el origen a la hora conseguir esa primera oportunidad. No pensar exclusivamente en el desarrollo, sino centrarse en conseguir la máxima satisfacción del cliente, más plantearse en todo momento que nuestro producto siempre puede ser mejorable es un plus fundamental.

Cuando la oportunidad la recibes de la propia empresa donde estás trabajando, parece muy obvio que plantearte mejorar siempre es una actitud muy valorada. ¿Pero qué hacemos si nos estamos postulando para ser Product Owner en otra empresa?
Este punto también lo tratamos, ya que uno de los asistentes tenía experiencia en procesos de selección y nos dio varias recomendaciones.

Lo primero en lo que nos insistió es en la importancia de conocer bien el tema del que hablamos y eso lo demostraremos usando el lenguaje correcto cuando hablamos de los distintos artefactos, eventos y/o responsabilidades que usamos cuando trabajamos en Scrum. Eso hará que se marque la diferencia entre "Se nota mucho la experiencia y conocimientos profundos de esta persona" o "A esta persona le suenan cosas pero no sé si confiar en alguien que afirma 'haber hecho eso del Jira y las tarjetas' "
El tener la certificación oficial hará también que tu candidatura tenga un peso para ir pasando fases en el proceso de selección.
El no conformarte y seguir creciendo en tu experiencia, certificaciones, formaciones, etc. asociados principalmente a la gestión de producto.
Si tienes lo anterior, sólo falta añadir la confianza en uno mismo (porque tienes lo necesario) y remarcar a tu interlocutor lo que para él/ella es importante para el puesto de trabajo que te ofrece y cómo encaja con eso con tu perfil.

Aquí te dejo un vídeo con la charla completa:

Agile en proyectos que no son de programación

Sat, 02 Sep 2023 09:34:26 GMT

Charla de Mayo-23' del Agile-Coffee

"Agile es sólo para IT" ¿Cuántas veces habremos oído esa frase? Pues en el último Agile-Coffe que hicimos antes del verano estuvimos evaluando el uso de "Agile fuera de la programación".

¿Y cómo se puede usar Agile fuera de IT? Pues para ello lo primero que tenemos que saber qué es Agile, y Agile no es más que una filosofía/mentalidad definida por 4 principios y 10 valores, lo que implica que Agile no es algo que se haga o se deje de hacer, sino que Agile es algo que se es o no se es.

Esta filosofía la resumo en las formaciones como "la búsqueda constante de la satisfacción del cliente/usuario, mediante un producto/servicio de calidad, realizado por un equipo motivado".

Imaginemos un restaurante, una empresa farmacéutica, una constructora... ¿En cuál de ellas no estarían de acuerdo con que buscan la satisfacción del cliente mediante un producto de calidad con un equipo motivado?

El problema es que Agile implica un cambio grande de mentalidad en las empresas. Requiere que mi objetivo deje de ser "ganar más dinero" para ser "satisfacer a mis usuarios" (ganar más dinero será la consecuencia, no el objetivo). Requiere que me centre en que mi producto sea lo más óptimo posible y no entregar algo de cualquier manera. Requiere respetar y fomentar el crecimiento del equipo y abandonar el "ordeno y mando".

Si alguien no abraza la filosofía Agile es exclusivamente por egoísmo y por pensar que su organización es más importante que el usuario final. Hay muchas empresas que, en pleno siglo XXI siguen pensando que el "ordeno y mando" es la opción más óptima porque "así es como siempre lo hemos hecho y nos va bien", pero se sorprenderían del cambio a mejor que podrían obtener en caso de poner el foco en lo que realmente es importante: El cliente, el usuario.

Sí, te puedo dar un sector donde Agile no encaja: La Administración Pública. ¿Motivo? Pues que cada vez que hacen un proyecto/producto no ponen el foco en el usuario final. Lo que buscan es la justificación del gasto: "Dijimos que íbamos a hacer esto y lo hemos hecho..." Lo que no dijeron es que iba a ser útil, intuitivo, fácil... ni siquiera que funcione. Es una pena, pero a día de hoy la Administración está muy lejos de esa mentalidad y no por sus miembros, porque he tenido personas que trabajan en la Administración que han participado en mis formaciones motu proprio, pero los responsables finales no tienen esa mentalidad que permita a los equipos ese crecimiento, auto-gestión y foco en la persona que finalmente va a usar el producto/herramienta.
Pero esto es como todo: Pasito a pasito se conseguirá ir metiendo esta filosofía, primero en las empresas y posteriormente en la Administración. No será fácil ni rápido, pero acabará llegando.

¿Y cómo se aplica todo este movimiento Ágil en sectores no informáticos? Sencillo: Lo que se hace es adaptar el producto a las necesidades actuales de los usuarios, reducir burocracia, reducir tiempos de entrega, empoderar equipos... Por ejemplo:

La radio pública estadounidense NPR (National Public Radio) tenía un proceso para llevar programas a las radios locales: Los productores llegaban con ciertas ideas a los ejecutivos. Con aquellas que pasaban se contrataba el personal, se hacía la programación completa para un gran lanzamiento y al mismo tiempo los representantes iban a radios locales a vender dicho programa. Era algo lento y costoso, así que intentaron encajarlo en una mentalidad "Agile". ¿Qué hicieron? Pues en lugar de llevar un programa completo, llevaban sólo pequeños pilotos con el personal mínimo necesario a las cadenas locales. Al ser menos costoso podían llevarlo incluso gratis el piloto. Luego pedían feedback por redes sociales e iban adaptando el programa a las necesidades y gustos de la audiencia: Rápido, eficiente, menos costoso y, sobre todo, menos riesgo. Llegaron a reducir los costes a un tercio con esta forma de trabajar.
Barclays Bank : Simplificaron procesos, mejoraron productividad, rediseñaron espacios para ser menos individualistas y más colaborativos
Lonely Planet (Equipo legal) : Crearon Kanban, mejoraron transparencia, comunicación, trabajo en equipo... Consecuencia: Tras 100 días mejoraron la productividad un 25%
Museo Nacional de Arte de Países Bajos : Trabajo en equipo para mejorar las exposiciones. Consecuencia: 10% de incremento de asistencia anual.
Mission Bell Winery : En esta bodega crearon pequeños grupos para mantener la producción y crear nuevos sabores. El proceso se mejoró un 90%

De forma análoga, podemos encontrar fácilmente empresas farmacéuticas, de recruiting, aeroespaciales, legales, de diseño, de marketing, etc. que han visto cómo cambiando la forma de trabajar rígida con una metodología estricta de trabajo hacia un foco donde deja de primar el proceso para poner el foco en los usuarios finales, estas organizaciones han mejorado su imagen de marca, ventas, beneficios y, sobre todo, la fidelización de los usuarios/clientes.

Puedes encontrar más info sobre Agile fuera de IT en estos enlaces (en inglés):

¡Nos vemos en el siguiente Agile-Coffee !

El futuro del Scrum Master

Wed, 03 May 2023 09:21:52 GMT

Agile Coffee III

¿Sacamos la bola de cristal para conocer el futuro?
En la última edición del Agile Coffee hicimos justo eso: Preguntarnos cómo será el futuro del Scrum Master. ¿Por qué? Porque así lo habéis decidido entre los asistentes a este evento gratuito donde tratamos cualquier punto, comentario, ayuda que necesitéis.

A la hora de hablar del futuro de este rol, o de cualquier cosa en la vida, es imposible tener una certeza plena de qué va a ocurrir. Justo este tipo de roles nacieron porque las empresas se empeñaban en conocer el futuro en entornos altamente complejos, lo cual es prácticamente imposible.

Así que, igual que cuando se usa Scrum, nosotros empezamos por el empirismo, lo que conocemos: Y lo que conocemos hoy es que el rol del Scrum Master en este momento está en su punto álgido y que ninguna empresa con vistas a seguir creciendo y evolucionando debería contar con un buen profesional de este tipo (o el análogo en el marco que se use).

Perfecto. A corto y medio plazo no esperamos ningún cambio, pero... ¿y a largo plazo? ¿Puede surgir un nuevo marco de trabajo que haga que Scrum se vuelva obsoleto y, por tanto, el rol deje de tener su utilidad?

Nada es imposible. Cada año vemos como en el atletismo y en la natación se baten récords imbatibles que unos meses/años después se vuelven a batir... Reconozco que en este momento se me hace difícil pensar que surja algo que deje Scrum a un lado completamente vestigial y sin valor, pero quién sabe lo que el futuro nos depara, por lo que si llegara un nuevo marco que se convirtiera en la referencia mundial por su absoluta eficiencia y eficacia, pues los Scrum Masters haremos lo que mejor se nos da: la adaptación. Aunque, sinceramente, no veo probable que esto vaya a suceder pronto.

Bien, una vez evaluado qué pensamos que puede pasar con el Scrum Master nos preguntamos: ¿Por qué alguien propuso este tema? ¿Qué es lo que esperaba conocer o profundizar? Así que me fui a la persona y le pregunté directamente. La respuesta: "He oído a gente hablar de que roles como el de Scrum Master en Scrum o el Project Manager en Waterfall acabarán desapareciendo y quería conocer vuestra opinión".

Esto plantea otro punto de vista distinto. Al añadir al "Project Manager" no es que se plantee si Scrum seguirá vigente o no, sino de si los Desarrolladores confían o no en este tipo de roles.

Yo entiendo perfectamente que haya Desarrolladores que no crean en su Scrum Master y a los que no les gusta Scrum, y el motivo que me encuentro siempre es el mismo: Esos Desarrolladores sólo han vivido Scrum desde un Scrum Master que no sabe hacer bien su trabajo y en un entorno donde no se hace bien Scrum. Así es normal que ronde por la cabeza que esos roles no sirven para nada, porque es verdad, así no sirven para nada. (Spoiler: Solución al problema es hacer la mejor formación en Scrum , conmigo claro)

Hablamos también del concepto del shu-ha-ri . Este concepto, que viene del haikido, nos expresa tres niveles por los que se va pasando en la búsqueda de la maestría.

En la primera fase, la del shu , lo que hacemos es seguir las normas y valernos de las experiencias y pasos de otros para intentar hacer algo lo más perfecto posible. En la fase del ha , lo que hacemos es romper esas normas y sencillamente ver qué pasa para nuestro caso, evaluando si es mejor con la norma o sin ella. Por último el ri nos planteamos innovar y crear nuestras propias normas que aplican mejor a nuestra casuística.

¿Problema? Que hay muuuuuchas personas en muuuuuchas empresas pensando estar en la fase ri "adaptando Scrum a sus necesidades". Cuando yo escucho a una empresa "Nosotros hacemos nuestro propio Scrum" lo que oigo es "Nuestro Waterfall en iteraciones no se toca". Y es que lo normal sería que ni tú ni yo alcancemos jamás el estado ri , y si lo hacemos será dentro de muchíiisimos años. Da igual lo que hagas, da igual a lo que te dediques, al aikido, al piano, al desarrollo de software... que en el 99% de los casos la fase de shu dura varias décadas, igual que pasa con el resto de fases.

Es cierto que si llegamos a una fase máxima de innovación, podemos encontrarnos con un marco que sea ideal para nosotros y que no tenga Scrum Master, no es imposible que eso fase, pero es como si te toca la lotería dos veces seguidas, muy muy muy difícil. Algo así fue lo que le pasó a Spotify, que hizo su propio marco de escalado después de mucha prueba y error y que encajaba perfectamente con sus necesidades. Luego las empresas copian el modelo Spotify y no les funciona. El motivo es sencillo: Este modelo está ideado por y para las condiciones de Spotify y no basta con un "qué hago o cómo nombro a los equipos" sino que hay que llevar su forma de trabajar y mentalidad, de ahí que, en el 95% de las veces (por no decir 99,999%) el modelo Spotify sea fracaso anunciado en tu empresa... os empeñáis en creer que estáis en ri cuando os quedan décadas de shu por andar. (Spiler 2: Solución al problema es contratar una consultoría en Agile&Scrum especializada, conmigo también claro).

Si te perdiste la sesión, aquí te dejo un vídeo con toda la charla (45 min).

Si quieres asistir a la próxima que hagamos, contacta conmigo y coméntamelo.

Comenzar a trabajar como Scrum Master

Fri, 31 Mar 2023 13:16:24 GMT

Agile Coffee II

Después de hacer el primer evento de Agile Coffee, que puedes ver en este enlace , donde hablamos de cómo obtener ese primer trabajo como Scrum Master (entre otras cosas), que es el más difícil de conseguir sin duda alguna, el feedback de esa sesión se centró mucho en ese bloque, por lo que hemos decidido profundizar más en este hueco.

De ahí, que en esta segunda edición lo hayamos orientado a profundizar más en esa labor de conseguir trabajar como Scrum Master en dos fases:

- Una primera centrada en la fase de selección.

- Una segunda de cómo es el inicio de trabajo del Scrum Master una vez conseguido el empleo.

En la primera fase abrimos un foro, donde los participantes han comentado sus experiencias en distintos procesos de selección, poniendo en común algunas preguntas habituales que se suelen encontrar. Algunas de ellas son las típicas preguntas teóricas sobre el marco, y otras más orientadas a valorar esos soft-skills del candidato junto a su experiencia, como "¿qué es para ti un buen Scrum Master?" o "¿qué tipo de herramientas has usado"?

La conversación que se generó entorno a este tema fue de lo más interesante con distintas personas aportando su punto de vista y experiencia.

Para la segunda parte, contamos con Manuel Sandino que nos compartió su punto de vista sobre el inicio de trabajo como Scrum Master. Manolo, actual PSM II (y futuro PSM III en breve) trabaja como Scrum Master en su organización y lidera todo lo relacionado con el tema Agile.

Entre otras cosas, nos contó la importancia de ayudar al equipo en su crecimiento y su autogestión donde un Scrum Master tenga una gran capacidad de liderazgo pero una capacidad mayor aún de servidumbre ya que es un rol que tiene que estar siempre que el equipo lo necesite.

Si te perdiste la sesión, aquí te dejo un vídeo con toda la charla (75 min.):

Agile Coffee I

Tue, 14 Mar 2023 12:15:19 GMT

¿Primer trabajo como Scrum Master? ¿Qué hacemos con tareas burocráticas? Hablemos de ello.

Después de mucho tiempo con intención de hacer algún tipo de evento donde podamos tratar temas que antiguos alumnos puedan necesitar consultar y debatir, por fin hemos conseguido cuadrar una sesión que intentaremos hacer de forma periódica.

Le hemos llamado "Agile-Coffee", por la similitud a "tengamos una charla informal en el tiempo que nos tomamos un café juntos".

En esta primera edición hemos hablado de dos temas principalmente:

" Cómo empezar a trabajar de Scrum Master después de conseguir la certificación "
" Cómo lidiar con tareas burocráticas que no generan valor a lo largo del Sprint "

En el primer punto estuvimos hablando de que efectivamente la experiencia es muy importante, como en cualquier trabajo, pero a la hora de conseguir esa primera oportunidad (como en cualquier otro trabajo) tenemos que buscar cubrir esa falta de experiencia con otros elementos. Entre otros, hablamos de compartir conversaciones con otros Scrum Master para conocer qué hacen, qué harían o qué dejarían de hacer en distintos casos; aprovechar las preguntas que te hagan durante una entrevista para moverlas en foros de confianza donde te puedan dar respuesta a qué hace un buen profesional en esos casos y llevarte así parte de esa experiencia; participar en foros, debates, entrevistas, etc. para seguir evolucionando e incluso intentar hacerlo de forma activa; e incluso la posibilidad de buscar algún lugar conocido donde ofrecerte para hacer unas prácticas o un acompañamiento al Scrum Master de forma gratuita.

Al principio, cuando la experiencia es un déficit en nuestro CV todo aquellos pasitos pequeños que podamos añadir hará que vayamos mejorando poco a poco y toda entrevista es una experiencia más que nos ayudará a conseguir ese primer trabajo.

Sobre el segundo punto, vimos que si una tarea burocrática o repetitiva, pero que no da valor al producto/servicio, no debería estar en el Sprint Backlog ni en el Product Backlog.

Incidimos en evaluar bien por qué se hacen tareas que no dan valor al producto, ya que por defecto estaríamos hablando de un "desperdicio" (algo que nos cuesta tiempo/esfuerzo/dinero y que no hace que nuestro producto/servicio sea mejor. Parte de nuestro trabajo es evaluar esos desperdicios para tratar de reducirlos al máximo e incluso eliminarlos.

Si no fuera posible eliminarlos, hablamos de la posibilidad de crear un Backlog específico para ello. Scrum nos prescribe tres artefactos, pero no impide tener más, por lo que si fuese necesario podríamos contar con otro listado de "cosas por hacer". Serían "cosas" que no nos van a ayudar a conseguir el objetivo del Sprint, de ahí que no estén en el Sprint Backlog.

Hubo un comentario interesante sobre la posibilidad de añadir esos puntos al DoD. Es algo factible, todo depende del caso y de a qué nos refiramos con ese tipo de "tareas burocráticas". Si es algo que tiene que hacerse sí o sí antes de que un PBI se dé por terminado, es perfectamente válido (de hecho tiene que ser así).

Además, hablamos de los "Spikes", que son tiempos dedicados a profundizar sobre algún tema que requiere más investigación o conocimiento antes de iniciar un PBI, como si fueran PoC (Pruebas de Concepto). Esos "Spikes" tampoco deberían estar en el Sprint Backlog, puesto que no es algo que nos vaya a ayudar a conseguir el objetivo del Sprint, puesto que generalmente son tareas que salen de los Refinamientos necesarias para aclarar algo (el uso de una herramienta, tecnología, etc.). Normalmente un Spike va a ayudar a que un PBI que aún está en el Product Backlog sea candidato a entrar en la siguiente iteración, por lo que no deberíamos hacer Spikes de PBI que ya estén en el Sprint Backlog. Sin embargo, y eso sería ideal, sí que podríamos hacer el PBI y el Spike asociado en el mismo Sprint si el PBI se añade a posteriori del Sprint Planning porque hayamos finalizado lo planificado antes de tiempo y podemos abordarlo antes de que finalice el Sprint.

Del feedback solicitado de esta charla, gustó mucho que hubiera participación de los asistentes, compartiendo sus experiencias; y el tema del trabajo, del cual hubo varias propuestas, por lo que en la próxima charla profundizaremos más en estos puntos.

Si te perdiste la sesión, aquí te dejo un vídeo con toda la charla (1h):

¡¡Scrum cumple 25 años!!

Fri, 20 Nov 2020 13:05:24 GMT

Con una nueva versión de la guía...

El 18 de Noviembre de 2020, en un evento retransmitido en directo por internet, los creadores de Scrum (Jeff Sutherland y Ken Schwaber) dieron a conocer la nueva versión de la guía. Una guía más corta que la anterior.

El 30 de agosto, el propio Ken escribió en su blog que la nueva versión iba a tener tan solo 13 páginas (por las 19 de la previa). Yo estaba asombrado de cómo era posible recortar tanto de un marco de trabajo del que apenas había donde recortar. Me habían provocado una impaciencia e incertidumbre por ver el resultado.
Aquí podéis ver el anuncio del que os hablo: https://kenschwaber.wordpress.com/2020/08/30/scrum-guide-2020/

Una vez que la he tenido en mi mano y he podido ver los cambios, me he sorprendido gratamente por el cambio. Han mejorado algo que era muy difícil mejorar.
Vamos a ver juntos los principales cambios y los vamos a ir valorando uno a uno:

Se ha vuelto menos prescriptiva : Ya lo comento en las formaciones. Scrum es un marco de trabajo y dentro del marco podemos hacer lo que nos dé la gana (mientras mantengamos el espíritu del marco y la mentalidad Agile). Lo que han hecho ahora es poner el marco más fino para que tengamos más margen de maniobra. ¿Cómo? Pues suavizando las palabras prescriptivas reduciendo pasos como en el Daily Scrum o en la cancelación de Sprint lo cual nos permite tener más poder de decisión (entre otros).
Mi opinión : Me gusta que intente alejarse del concepto de metodología. Dependiendo del nivel de madurez del equipo, el SM será el que tenga que proponer distintas pautas o formas de actuar para corregir los distintos problemas que puedan darse, pero ahora con aún más manga ancha.
Un equipo, un producto : Desaparece el concepto de Equipo de Desarrollo y los roles. Ahora sólo hay un equipo, el equipo Scrum, con distintas responsabilidades. Ahora el ST lo forman un SM, un PO y Desarrolladores.
Mi opinión : No terminaba de ver qué se ganaba con el cambio hasta que oí a Jeff Sutherland explicarlo en directo. Yo partía de la base de que el objetivo de todos es el mismo y ahora eso mismo lo remarcan con mayor claridad. Según Jeff anteriormente se podía llegar a producir un "nosotros vs ellos" y aunque estamos todos en el mismo equipo, realmente había un sub-equipo, un grupo separado, una especie de "gueto" en el cual podía llegar a relajarse la responsabilidad de toma de decisiones a tan sólo una persona (el PO). Ahora sigue habiendo distintas responsabilidades pero remarcando que el objetivo de enfocarnos en lo mejor para el producto sigue siendo algo de todos. Es un matiz importante que evita malinterpretaciones y simplifica. ¡Bravo!
Product Goal : Aparece el concepto de Objetivo del Producto o Product Goal asociado al Product Backlog. Con esto el equipo podrá siempre poner el foco hacia un objetivo de mayor valor. Cada Sprint el producto irá acercándose a más al Product Goal .
Mi opinión : Básicamente lo que han hecho es exportar la idea del trabajo del Sprint al producto. En el Sprint, evaluamos día a día si nuestro trabajo se acerca al objetivo del Sprint y hacemos un plan diario para favorecer que nos acerquemos. Ahora hacemos lo mismo pero también a un nivel mayor de tiempo. Sin poner ese objetivo (igual que cuando no se pone objetivo en el Sprint) se dificulta la toma de decisiones y se pierde el foco. Buen añadido.
Un lugar para el Sprint Goal, Definition of Done y Product Goal : En las versiones anteriores, aparecía el concepto de Objetivo del Sprint o Sprint Goal y Definición de Hecho o Definition of Done , pero no se les daba identidad. Ahora, los dos que ya existían, más el nuevo aparecen asociados con un artefacto cada uno, de forma que cada artefacto tiene un compromiso: El Product Backlog con el Product Goal, el Sprint Backlog con el Sprint Goal y el Incremento con el Definition of Done.
Mi opinión : Aquí se está clarificando y simplificando algo que la versión anterior ya tenía. Es verdad que con el Definition of Done muchos alumnos se preguntan si es o no un artefacto y si no lo es, ¿por qué no? si es algo que el equipo realmente usa durante el desarrollo. Ahora aclara que cada artefacto tiene un compromiso de transparencia hacia algo y le pone nombre. Además reafirma lo que comento en las formaciones: El DoD va a nivel del PBI que es lo que finalmente va a ser el incremento.
Auto-gestión en lugar de auto-organización : En la versión anterior, el equipo de desarrollo se auto organiza decidiendo de forma interna quién y cómo se realiza el trabajo. Dado que el equipo de desarrollo ya no existe, ahora el equipo (el Scrum Team, el único equipo que hay) se auto gestiona, es decir, que ya no sólo decidimos quién y cómo, sino también qué trabajos se van a realizar.
Mi opinión : Me pasó algo parecido al cambio explicado en el punto 2. No veía la importancia del cambio. Con la auto-gestión deja claro la desaparición del sub-equipo y que todos vamos hacia el mismo objetivo, así que añade a ese nivel de organización el poder de decisión del qué vamos a hacer incluyendo por supuesto a los desarrolladores.
Tres temas en el Sprint Planning : En la versión anterior, el Sprint Planning se dividía en dos: Qué vamos a hacer y cómo lo vamos a hacer. Ahora se añade un punto previo para que el equipo hable del por qué (o para qué) vamos a trabajar en el Sprint que comienza.
Mi opinión : Esto es algo que ya hacían muchísimos equipos. Es muy difícil preparar un buen "qué vamos a hacer" si no sabemos el por qué (o para qué) vamos a hacerlo. Sin embargo aún hay equipos que no lo hacen (principalmente porque están ocultando un Kanban dentro de Scrum o cosas peores que no quiero nombrar). Dejar claro la necesidad de que el equipo conozca el por qué de todo es algo muy positivo y los que me conocéis sabéis de sobra que los "por qué" de todo es fundamental para poder escoger siempre una opción que se acerque más a las necesidades reales de la situación, el producto o el mercado.
Simplificación del lenguaje para una mayor audiencia : Se elimina contenido complejo o redundante y cualquier referencia al mundo del software, dejando claro su apuesta multi-sectorial. Con todo ello se ha reducido el contenido hasta las 13 páginas.
Mi opinión : Vámonos un momento al mundo Lean. Uno de los conceptos de Lean es "eliminar desperdicio". Uno de los puntos del desperdicio es la "documentación superflua". Eliminando contenido complejo y redundante se han acercado más aún, no sólo esos principios de Lean a los que hago referencia, sino también al principio de "Simplicidad" del Agile Manifesto. No por tener más contenido se es mejor. Lo habitual es que sea al contrario y lo han conseguido. Además, ya han abandonado completamente el mundo del software (ejemplo claro de entornos complicados y complejos) para dar cabida a cualquier sector. Me pregunto si cuando actualicen la guía de Nexus (versión actual de 2018) eliminarán todas las referencias al software que ahí sí están usando.
Cambios menores : Hay algunos cambios pequeños que también son curiosos:

Los pilares de Scrum no son útiles si no se usan los tres bien. Esto que explico durante las formaciones, ahora se menciona explícitamente en la guía. No hay Adaptación sin Inspección. No hay Inspección sin Transparencia.
Al desaparecer el Equipo de Desarrollo, también lo hace el número de integrantes (de 3 a 9). Ahora aparece el tamaño del equipo (el único equipo que hay, el Scrum Team) y el número es de " típicamente 10 o menos ". Ya no se especifica un mínimo y el número de personas que pueden trabajar en tareas del Sprint Backlog suben de 9 a 10 (la guía vuelve a dejar claro en el Daily que tanto el SM como el PO pueden hacer tareas de desarrollo, como ya lo hacía en la versión anterior cuando decía que en el máximo de 9 se contaban al SM y al PO si éstos hacían tareas de desarrollo).
El SM pasa de ser un "líder-sirviente" como aparecía en la versión anterior, a un "verdadero líder que sirve al equipo y a la organización". En palabras de Jeff Sutherland, se quiere evitar que el SM sea un mero secretario del equipo para dejar claro su importancia real en él. Personalmente me gustaba el concepto de líder-sirviente, pero creo que ahora deja más claro lo que realmente se espera de este un SM. Por ejemplo, en la guía ahora aparece que el SM es el que causa que los impedimentos desaparezcan mientras que en la versión anterior venía que el SM eliminaba los impedimentos. Todo esto refuerza la labor del SM en su empeño en que el equipo crezca a nivel grupal e individual.
En la versión anterior, se mencionaba que el Daily Scrum se hace en el mismo sitio y misma hora para reducir la complejidad. Ahora se menciona explícitamente que TODOS los eventos se hacen en el mismo sitio y misma hora para reducir la complejidad.
En la versión de 2016 de la guía había que hacer tres preguntas durante el Daily. En la de 2017 esas preguntas son un ejemplo que se puede hacer. En esta nueva versión desaparecen las preguntas para que cada daily se pueda hacer como mejor se considere dentro de la auto-gestión, siempre que se enfoque en el progreso hacia el objetivo del Sprint y provoquen un plan para su actuación.
El Sprint Review es uno de los que más recortes tienen a nivel prescriptivo. Deja claro el para qué se hace, pero elimina pasos que había que hacer durante el mismo.

Me daba pánico pensar en los cambios que iban a hacer y que provocara una reducción en el contenido. Una vez evaluado y comprendido, me ha parecido todo un acierto, consiguiendo reduciendo el tamaño de la misma hacerlo más enfocado al objetivo de entregar valor de forma continua. La base es la misma. Scrum sigue siendo Scrum. Pero creo que han mejorado.

He ojeado también la traducción al español. No la he evaluado al completo, pero tiene mejor pinta que la anterior. Han corregido el error de traducción que había en la versión 2017, donde " desapareció " el respecto dentro la lista de valores de Scrum. Sin embargo, en una simple ojeada, he visto un error (grave, a mi parecer) porque cuando indican los cambios principales han indicado el "Development Team" como parte del Scrum Team cuando justo es una de las cosas que han desaparecido...

No os preocupéis demasiado por estos cambios. La base es la misma, la idea es la misma. Si sabéis scrum, vais a seguir sabiendo. Pero si os da miedo qué puede pasar en los exámenes, tranquilos: Hasta el 09/01/2021 todos los exámenes de scrum.org van a seguir estando basados en la guía de 2017. A partir de esa fecha la nueva guía será el foco de las preguntas.

Si queréis ver cómo fue el evento de presentación de la nueva guía, lo tenéis disponible aquí: https://www.scruminc.com/updated-scrum-guide-release/

¿Has visto ya la nueva versión? ¿Qué te ha parecido?

-------------------------------------------------------------------------------------------------------
Edito y me corrijo: Ya he leído la guía en español. Pensaba que tenía mejor pinta, pero tras verla sólo puedo seguir recomendando la original (en inglés). La traducción de la versión 2017 ya era bastante mala, pero la nueva no mejora mucho. Varios ejemplos:

Cuando se habla del PO y de la gestión del PB, uno de los puntos menciona " Ordering Product Backlog items ", que traducido sería "Ordenar los elementos del PB". Bueno, pues la traducción viene algo tan original (e imposible de entender) como: " Pedido de artículos de trabajo pendiente del producto ". Parece que Google Translator ha tenido bastante peso aquí.
El SM ayuda al PO entre otras cosas " Helping find techniques for effective Product Goal definition and Product Backlog management ", que traducido sería como "Ayudando a encontrar técnicas para una definición efectiva del Product Goal y la gestión del PB". Su traducción ha sido: " Ayudar a encontrar técnicas para una definición eficaz de los objetivos del producto y la gestiónde los retrasos en el producto ". ¿Retrasos? ¿De dónde sale eso?
Los nombres de los eventos y roles son nombres propios (vienen en mayúscula siempre) y su traducción podría ser la misma, es decir, podemos hablar en español de Product Owner, Sprint Review o Sprint Backlog sin necesidad de traducirlo. Eso sí, si se traduce debería hacerse medio bien. Cada vez que se traduce el Product Backlog lo hacen como " el trabajo pendiente del producto ". La nueva versión de la guía es más ligera en la versión original, no parece que la española lo haya tenido en cuenta. Mejor no traducirlo y si lo haces deja algo tan sencillo como "pila del producto".
El peor de todos: El ya comentado " Development Team " en la nueva versión donde ya no existe dicho grupo.

Los "ScrumButs" II

Wed, 09 Oct 2019 16:58:24 GMT

No lo llames Scrum, porque eso que haces no es Scrum.

Después de oír entre risas, porque es mejor reír que llorar, cómo uno de los asistentes a uno de mis cursos me contaba las ideas de su jefe para implantar Scrum, supe que mi siguiente entrada en el blog tenía que ser una continuación de los Scrumbuts.
Al jefe de esta persona, le había llegado algo de "Scrum" a los oídos y le dijo al equipo lo que se espera de un buen entorno Agile: "Los sprints los haremos unos de 3 días, otros de una semana, según nos vaya conveniendo", "las estimaciones en horas, por supuesto", "¿el scrum master? cualquiera" "tampoco hay que ser tan puristas con Scrum"... Esta persona es un ejemplo obvio de Scrumbut.

Los Scrumbuts son los motivos por los que los equipos no pueden obtener todas las ventajas de Scrum para resolver sus problemas y conseguir todos los beneficios del desarrollo de producto al usar Scrum.

En la última entrada del blog vimos cien ejemplos de Scrumbuts. Aquí veremos algunos repetidos. ¿Aún no lo has visto? Te dejo el enlace https://www.antoniojesusruiz.es/los-scrumbuts

Veamos ahora más frases que nos van a dar las primeras señales de alarma de estar ante un Scrumbut. Las vamos a separar en categorías:

Scrum General:
- " Scrum es sólo para los desarrolladores, no para los miembros de Management ".
- " Agile nos dice que es 'Individuos e interacciones sobre procesos y herramientas', pero Scrum es un proceso, ¿no? ".
Prácticas Waterfall:
- " El cliente necesita un gran diseño completo de antemano ".
- " Vamos a hacer primero una maqueta que sólo involucrará a los diseñadores ".
- " Las stories deberían tener diseños técnicos y funcionales ".
- " Ya hemos planeado los próximos 6 sprints ".
- " Nuestro backlog es un documento de requerimientos ".
- " ¿Story Points? ¿Sprints? ¿Backlog? Nuestros clientes no lo entenderán. Nosotros sólo hacemos contratos con alcance/ horas/t iempo fijo ".
- " Yo soy [Product Owner/Project Manager/Agile Coach/Scrum Master/Business Developer/Account Manager/Portfolio Manager/Team Manager] " (selecciona todos lo que apliquen).
- " Hagamos un [Design Sprint, Sprint 0, Architecture Runaway, Pre-Sprint, Discovery Sprint, Planning Sprint] ".
No multi-disciplinar:
- " El equipo de desarrollo lo componen sólo desarrolladores software ".
- " Nuestro equipo de [QA/Diseño/UX/Arquitectura/IT]... " (o el departamento que quieras añadir).
- " Yo soy un [diseñador/desarrollador] por lo tanto, yo sólo [diseño/desarrollo] ".
- " [Luis] trabajará sólo en la Story [X], porque él sólo se basta" .
- " ¿Dos desarrolladores en la misma tarea/story? Eso es muy ineficiente ".
Nuestro mánager no... (falta de auto-organización):
- " Aún no podemos confiar en el equipo para que se auto-organicen ".
- " No involucramos al equipo al hacer la oferta inicial a nuestros clientes ".
- " Ya le hemos dicho al cliente que... ".
- " El Product Manager es el Product Owner... también lo es el cliente... y cualquiera de sus interesados... Realmente, cualquiera que contacte con Management tendrá prioridad ".
- " Cuando el Product Owner rechazó [X], el cliente le dijo a Management que le dijera al Product Owner que... ".
- " [María] es la Product Owner, pero necesita la aprobación de los mánager antes de poder... ".
- " [Management y/o Product Owner] ponemos peticiones urgentes en el Sprint Backlog ".
- " El equipo de desarrollo no debería interactuar con el [cliente/usuario/interesado], sólo el Scrum Master o el Product Owner ".
- " Le pediremos al equipo que haga... ".
- " Management le pide al equipo B que haga cualquier cosa que funcione para el equipo A ".
- " Priorizamos nuestro trabajo según los interesados que contactan a Management estén más enfadados/molestos/frustados ".
- " Estimar con el equipo es ineficiente ".
La rutina:
- " Sólo hacemos Daily Scrum ".
- " Los eventos de Scrum se hacen demasiado largos... ".
- " El Sprint no puede comenzar porque la Story [X] no está clara del todo ".
- " Este Sprint durará algo más, porque [Y] no se ha finalizado ".
- " Nuestros Sprints son de 6 semanas ".
- " El Sprint no puede comenzar porque aún quedan elementos del Sprint anterior por terminar ".
- " El equipo no ha entregado lo que se comprometió, así que tendrá que echar horas extras ".
- " El Sprint Review no puede comenzar, porque el equipo aún no ha finalizado ".
- " Las sesiones de coaching/training deberían hacerse durante los eventos de Scrum... o bien haciendo 'pizza sessions' después del trabajo ".
- " Usa el tiempo de las retrospectivas para finalizar tareas ".
- " ¡La estimación es demasiado alta! Ya habíais hecho algo similar, ¿no?. Va a ser sólo un copy-paste ".
- " Necesito [más información] antes de [empezar] ".
- " Como [una persona] no ha llegado, no tiene sentido que tengamos [cualquiera de los eventos de Scrum] ".
- " Deberíamos tener una reunión sobre... ".
Las métricas:
- " La velocidad del equipo no está aumentando, por tanto el equipo no está mejorando ".
- " Añadiremos más capacidad al equipo para aumentar la velocidad y así cumplir con la demanda del cliente ".
- " No podemos esperar a las estimaciones del equipo, porque el cliente quiere las estimaciones hoy ".
- " Las estimaciones son las fechas límite de entrega ".
- " Las estimaciones las hace sólo el [Solutions Architect/Business Anaylist/Senior Developer] ".
- " No tenemos tiempo para hacer estimaciones ".
- " Nuestro burn-down chart se parece más a un burn-up chart ".
- " Nuestro burn-down sólo baja los viernes ".
- " Usamos 'compromisos' en lugar de 'pronósticos' ".
- " Un Story Point es una hora, ¿verdad? ".
- " ¿Cuántas horas son un Story Point? "
Resistencia al cambio:
- " Siempre hemos hecho [X] así... ".
- " No deberíamos intentar cambiar [nuestra forma de trabajar] por ahora "
- " Sólo haré [tareas] que hayan sido definidas en [la herramienta X] y cumplan con [formato Y] ".
- " Yo soy [senior], así que no voy a hacer [tareas mundanas] ".
- " No podemos empezar (a trabajar en una story / un sprint) porque no tenemos todos los detalles ".
Herramientas:
- " No necesitamos un Scrum Board físico porque usamos Jira ".
- " Usamos Jira, por lo tanto somos Agile ".
- " Todos los equipos tienen la obligación de usar Jira ".
- " Jira " (Sí, merece su propio ScrumBut).
- " Podemos usar Skype así que no hay necesidad de estar juntos ".
- " El cliente crea una petición en la herramienta [A], con enlaces a la herramienta [B] que incluye adjuntos de la herramienta [C] los cuales [copiamos/sincronizamos] a la herramienta [D] donde la refinamos antes de que lo muevan a la herramienta de los equipos Scrum [E] y los desarrolladores entonces crean las tareas en la herramienta [F] además de mantener el seguimiento de esas tareas en la pared de los post-it "
Prácticas:
- " Todos hablamos sobre las pruebas automatizadas pero nunca las aplicamos realmente. Tampoco hacemos pruebas manuales porque deberían estar automatizadas ".
- " ¿Cuál de los catorce Sprint Goals debemos hacer primero? ".
- " Esto son sólo 15 minutos de trabajo, no hace falta que tenga todo el DoD, ¿verdad? ".
- " ¿Cursos?¿Formación? Sólo en tu tiempo libre ".
- " No hacemos documentación porque así lo dice el Agile Manifesto ".
- " No tenemos tiempo para trabajar en la deuda técnica ".
Spikes, Stories y Definition of Done:
- " Una Story es lo mismo que un PBI, ¿no? ".
- " [Luis] añadió el criterio: 'Las ventas aumenten en un [añade un porcentaje aleatorio]' ".
- " [Carmen] añadió: 'etc.' ".
- " [Carlos] añadió: 'Ver el powerpoint adjunto' ".
- " [Ana] añadió el criterio: '¡Tiene que estar en producción hoy!' ".
- " [Juan] añadió como DoD: 'Que le guste al [Product Owner/usuario]' ".
- " [Laura] añadió como DoD: 'Que no haya bugs/defectos' ".
- " [Santi] creó una Story: 'Como Product Owner quiero un botón verde para comprar de forma que aumenten las ventas' ".
- " [Silvia] creó una Story: 'Como departamento de marketing queremos que el SEO aumente nuestra exposición' ".
- " [Alex] creó una Story: 'Como departamento de marketing necesitamos el envío masivo de correos esta tarde' ".
- " [Alicia] añadió un bug: 'El sistema no tiene [una característica nunca antes mencionada] que debería haber estado sin necesidad de haberlo dicho antes como parte parte de [X]. Por favor, ¡tenedlo listo para [mañana]!' ".
- " [Rafa] añadió una Story: 'Oh, sólo una cosa más...' ".

Échale un vistazo al siguiente vídeo que resume bastante bien la vida de un Scrum Master rodeado de ScrumButs:

Fuente: https://medium.com/serious-scrum/scrumbut-10335be4a5e4

Los "ScrumButs"

Mon, 02 Sep 2019 15:48:26 GMT

"Hacemos Scrum pero..."

En las formaciones vemos que Scrum es un marco de trabajo, y por lo tanto tiene flexibilidad. Dos equipos distintos podrían estar haciendo cosas diferentes y eso no impediría que ambos estuvieran haciendo Scrum de forma correcta.
Sin embargo, algunos tienden a malinterpretar esa flexibilidad para hacer cualquier cosa, yendo incluso en contra de los principios ágiles. Que el marco sea flexible, no significa que lo podamos romper y rehacer a nuestro antojo, y encima tengamos el morro de seguir llamándolo scrum.
Y esto me recuerda a lo que una vez me dijo una mánager: " Scrum es lo que yo diga ". (Con la de gente válida que hay en el paro, aún me pregunto como algunos siguen en su puesto...)

Por eso, en este post vamos a hablar de los " ScrumButs ", que son aquellos que aseguran que hacen Scrum pero en realidad no lo están haciendo bien y por tanto están perdiendo el potencial que Scrum puede darles (en inglés, "I do Scrum but..." de ahí el nombre).

Para arrancar, veamos estos 100 Scrumbuts :
Hacemos Scrum pero...

No me siento seguro.
Nuestro equipo no es cross-funcional.
¿Podemos extender la duración del Sprint?
A menudo nos saltamos la Retro.
Creo que sí porque, eso justo es lo que hace Jira, ¿no?
Sólo los Stakeholders internos asisten al Review.
Seguimos intentando seguir un RoadMap .
Nuestro equipo no está preparado para auto-organizarse.
Sólo nuestro PO habla con los Stakeholders.
Tenemos que hacer un parche (hotfix) ya.
El PO nos dice qué hacer en el Sprint Planning.
Hagamos un [Design Sprint, Sprint 0, Architecure Runway, Pre-Sprint, Discovery Sprint, Recovery Sprint, Planning Sprint].
No necesitamos hacer Daily Scrum.
¿Y cómo encaja aquí el Project Manager?
Management habla de Agile pero actúa como Waterfall.
Fallar no es una opción.
El mercado es demasiado dinámico como para planificar.
Saltémonos estos puntos del DoD (Definition of Done) por ahora.
Si el equipo no entrega lo que se comprometió tienen que echar horas extras.
Deberíamos planear una reunión para discutir...
¿Cuántas horas son un Story Point?
El PO se apropia del Sprint Backlog.
El Sprint Review no es más que una Demo.
No le digas al cliente...
Odiamos los eventos de Scrum.
Management no lo es.
Nuestro Daily dura a veces 40 minutos.
El contrato dice que...
Preferimos hacer el Daily cualquier otro día.
Nuestro Burn Down Chart sólo baja los viernes.
No tenemos una definición que todos conozcamos de lo que significa "Terminado".
¿Cursos? ¿Formación? Eso en tu tiempo libre.
No gastamos tiempo en refinar el Product Backlog.
Como X no ha llegado aún, no podemos hacer [pon aquí cualquier evento de Scrum].
El incremento... no me parece nada.
No hacemos visible nuestro trabajo.
Todos hablamos de las pruebas automáticas, pero nunca lo aplicamos realmente. Tampoco hacemos pruebas manuales porque deberían estar automatizadas.
Nuestro equipo trabaja en múltiples productos a la vez.
Que esté terminado para mañana.
¡Management quiere implantar SAFe!
Nuestro equipo está formado por 18 personas.
¿Más de un desarrollador en la misma historia? Eso es ineficiente.
Nuestro PO es un comité.
Hacemos grooming .
Yo soy Diseñador/Desarrollador/QA/etc...
¡Management nos dice que tenemos que aumentar nuestra velocidad!
Tenemos una " ReviewSpective "
Es que Jira se ha caído.
Empecemos con un Sprint 0.
Scrum no es Agile.
Nuestro Burn Down Chart se parece más a un Burn UP Chart.
Aún planeamos los próximos 6 Sprints.
¿No recibiste el memorando/ la circular/ las instrucciones?
Nuestro cliente demandó un gran diseño completo de antemano.
Tú dime qué hago.
Tenemos que usar Jira.
Nuestros Sprints parece marchas fúnebres.
Nuestras estimaciones son " Deadlines ".
¿Definition of Done? Si esto se hace sólo en 15 minutos...
No tenemos incremento de producto al final del Sprint.
Tenemos seis Sprint Goals para este Sprint.
El Daily es un reporte de estado al Scrum Master.
El equipo no está al tanto de las promesas que Management está haciendo a los Stakeholders.
Consideramos una maqueta como un Incremento.
Nuestros Stakeholders están demasiado ocupados para unirse a los Sprint Reviews.
Nuestro producto es "oscuro y está lleno de terrores".
Una User Story es un PBI (Product Backlog Item), ¿no?
Nuestro Scrum Master apesta.
Nuestro Sprint Backlog está fijo.
La mayoría de nosotros nunca se ha leído la guía de Scrum.
No tengo ni idea de en qué está trabajando mi compañero.
Todos los PBI tienen que estar terminados al final del Sprint.
Nuestro Sprint Goal es aumentar la velocidad.
Podemos posponer el próximo Sprint, ¿verdad?
Lo pronosticado es nuestro Sprint Goal.
Management prefieren un Agile Coach a un Scrum Master.
No tenemos tiempo para resolver deuda técnica ni refactorizar.
El Product Owner (o el Scrum Master) asigna todas las tareas.
¿Dónde y cuándo es el Daily esta vez?
Sólo el Product Owner puede acceder al Product Backlog.
No llevamos los planes de mejora de la última Retro al Sprint Planning.
Scrum tan sólo es una excusa para no llegar a las fechas límite.
La velocidad del equipo no está aumentando, por lo que no están mejorando.
Scrum está anticuado.
No tenemos el entorno ni el soporte que necesitamos.
No hemos integrado nada en años.
Nuestro Scrum Master es también el Product Owner.
Nuestra organización es demasiado grande para Scrum.
Nos llaman "cerdos".
Nos llaman "recursos".
Nuestro Product Owner está ausente todo el tiempo.
Nuestro Daily Scrum se ha convertido en un Weekly Scrum.
Parece que no podemos estar en desacuerdo y comprometernos.
No se confía en nuestro equipo para hacer el trabajo.
El Scrum Master sólo facilita los eventos.
Tengo quejas durante días.
QA lo hace un equipo separado en un edificio diferente.
Seguimos sin saber explicarlo a Management.
No estamos abrazando sus valores.
¿Por qué seguimos necesitando un Scrum Master?

Si te sientes identificado en alguno/s de los puntos y pensabas que eso era lo correcto... igual te vendría bien asistir a una de mis sesiones de formación ;-)

Pronto haremos una revisión de los principales Scrumbuts en los distintos niveles de la organización. Permanece atento porque será para reír, por no llorar, porque por desgracia los Scrumbuts están por todos lados.

¿Te has tenido que pelear con alguno de estos 100 Scrumbuts? ¿Cómo has hecho para solucionarlo? ¡Deja tu comentario!

Fuente: https://medium.com/serious-scrum/100-scrumbuts-value-down-the-drain-3e470d9e3623

Certificado por Agile Coach Alliance

Tue, 09 Jul 2019 09:40:01 GMT

Otro pasito más

La Agile Coach Alliance ha convalidado mis conocimientos como Agile Coach.
Es todo un honor ver cómo los esfuerzos y pasos que voy dando son reconocidos.

Ahora toca ser ambicioso y no conformarse. Seguir llevando mis conocimientos y experiencia a mis clientes, con el objetivo de obtener de ellos la mayor satisfacción posible por un trabajo bien hecho. En definitiva, seguir creciendo.

El Scrum Board... ¿físico o digital?

Wed, 24 Apr 2019 20:44:09 GMT

¿Y por qué no ambos?

En las sesiones de formación a veces me preguntan: " ¿qué es mejor, tener un scrum board físico o digital? ".
Para mí, es como cuando le preguntan a un niño " ¿A quién quieres más, a papá o a mamá? ". Vamos a intentar analizarlo en esta entrada.

Las dos opciones tienen sus ventajas:

Un dashboard físico es el gran exponente de la transparencia. No depende de que alguien tenga o no permisos para ver la evolución del sprint, sino que está ahí para cualquiera que pueda estar interesado.
Un dashboard digital es la mejor forma de compartir esa evolución cuando tenemos equipos en distintas ubicaciones.

Entonces, ¿cuál escoger? Pues depende:

Una opción válida es delegar la elección en el equipo. Deja que ellos elijan la opción con la que se sientan más habituados y más cómodos.
Otra opción igual de válida es probar ambos tipos. Recuerda: transparencia, inspección y adaptación. Prueba con uno un tiempo, luego prueba con el otro, y evalúa pros y contras.
Mi opción favorita, la que intento mover en los equipos en los que he estado, es tener las dos opciones de forma simultánea.

Si puedes tener un scrum board físico y otro digital, podrás hacer una suma de ventajas:

Máxima transparencia
Acceso a todo el equipo independientemente de su ubicación.

En este punto, el comentario que surge es: " Si tengo dos board distintos, tengo el doble de trabajo en mantenimiento y podemos tener incoherencias entre ellos ".
Eso es cierto. Es más, yo añadiría que es absurdo tener dos artefactos distintos con la misma información.

Sin embargo, si tenemos ambos, se usarían para fines distintos:

Con el digital, podemos tener el estado exacto del "ahora". Los miembros del equipo de desarrollo usan el digital para actualizar cada tarea en el mismo instante en que lo necesitan. Pueden ver quién está con cada tarea y cuál es la siguiente tarea libre para iniciar. Sería la opción a actualizar durante la jornada.
La opción física se convertiría en una foto de cómo estaba todo tras el último Daily Scrum. El equipo de desarrollo verá al inicio del Daily cómo se quedó todo ayer, durante el Daily irán cambiando el estado de cada tarea, y al terminar podrán ver cómo se queda todo. Esto resulta muy útil al equipo para valorar si la evolución que se espera va en el camino correcto o se necesita algún plan de contingencia. Para que la foto funcione, entre el final de un Daily y el inicio del siguiente, el board físico no se cambia.

La opción del doble formato, la he usado con varios equipos en los que sólo usaban el digital. La idea siempre es la misma: Se les explica cuál es el objetivo y las posibles ventajas, se prueba durante un tiempo y se evalúa tras ese tiempo. Mi experiencia, hasta ahora, es que el equipo siempre ha preferido mantener el doble formato después de evaluarlo.

¿Y vosotros? ¿Físico o digital? ¿Papá o mamá?

"Los QA no van al Sprint Planning"

Tue, 26 Mar 2019 19:21:40 GMT

... y más casos de falta de formación

Un día cualquiera en la oficina. Me encuentro con mi equipo trabajando y vemos a otro equipo que se sienta cerca, levantarse para hacer su Sprint Planning . Todo es normal hasta que se escucha la conversación:

Un miembro del equipo de desarrollo: " ¿Y xxx no viene al Sprint Planning? "
Su Scrum Master: " No, los QA no van a los Sprint Planning "

Levanto la vista, y veo a todo mi equipo riéndose mientras me miran. Obviamente, todos los miembros de mi equipo saben quién tiene que asistir y quién no a cada evento en scrum, es una de mis funciones como scrum master... Pero parece que no todos los scrum master lo tienen tan claro.

Otro día, en una reunión entre todos los scrum masters para poner ideas en común, uno de ellos dice "yo es que no uso scrum, porque scrum no se preocupa del desarrollo..."
Otro día, escucho a un mánager decir "las funciones de un scrum master son reservar salas y tomar notas de las reuniones".
Otro día, otro scrum master te dice "es que mi obligación es la de asegurarme que el código que se va a entregar es correcto".
Llega otro día y otro mánager me dice "en este equipo, voy a poner a la misma persona como scrum master y product owner". Cuando intento explicarle los errores de la decisión, su respuesta fue "¿Me vas a decir tú a mí qué es scrum y qué no es scrum? Llevo x años haciendo scrum. Scrum es lo que yo diga"
Otro día, un mánager te dice "me da igual lo que el equipo opine, que yo voy a hacer lo que quiera" o "no hagáis retro, total ¿para qué?"

Ante tantos " facepalms " uno tras otro, no tuve otra opción que recomendarle al jefe de la oficina que hicieran formación de scrum y agile, porque era obvio que más de un concepto no estaba claro.
El jefe, alguien sensato, vio mi propuesta aceptable, y preparó una formación. Para ello llamó a una empresa, validada por scrum.org. Tras el curso, intento obtener feedback de algunos asistentes y dos de las opiniones que recibí fueron dignas de mención:

Uno de ellos me dice que, dado que el instructor no hablaba español, había preguntas que no entendía y la respuesta era un bonito paseo por los cerros de Úbeda sin llegar a responder la duda inicial.
Otro me dice que en su equipo ha provocado una revolución, dado que se estaba rotando la forma de llevar las retrospectivas entre todos los miembros del equipo, y el instructor les había dicho "que llevar la retrospectiva era función del scrum master", por lo que ahora muchos se negaban a hacerlo porque, según le decían, "estamos haciendo tu trabajo".

Conclusiones:
A veces nos encontramos con organizaciones que creen ser ágiles por el simple hecho de realizar los eventos que pone la guía de scrum. Si esas organizaciones no tienen la mentalidad ágil que se espera, si ponen a los scrum master a dedo diciéndole "tus funciones son las que yo diga", si aunque hacen los eventos, lo hacen de forma errónea, hay que promover una formación a todos los niveles para cambiar todo eso.
Una buena formación para los que van a mover ese cambio "en las trincheras", de forma que vean sus verdaderas funciones, guiadas principalmente hacia lo que se conoce como " soft skills ", es esencial. Esa formación debe ser de calidad y realizada por gente con amplios conocimientos demostrables en la materia, pero que también tengan experiencia en el puesto.
Si los que van a mover el cambio no tienen el apoyo real de la capa de managment, no conseguirán nada, de ahí la importancia de las sesiones de coaching en todas las capas.

Si te encuentras en un caso parecido, no dudes en contactar conmigo . Veremos cómo solucionarlo con sesiones de coaching y formación oficial.

Tips:
- Al Sprint Planning asisten todos los miembros del Scrum Team.
- Cualquier framework ágil se preocupa del desarrollo, puesto que es uno de los principios del agile manifesto.
- Las obligaciones del scrum master vienen explicadas en la guía de scrum, y ninguna de ellas es ser secretario del equipo ni validador del trabajo hecho.
- El respeto es uno de los valores de scrum: Se respeta a todos, y se confía en la profesionalidad de todos. El despotismo no cabe en el mundo agile.
- Voy a pensar que lo del trainer fue un problema de traducción, y lo que los asistentes entendieron no fue lo que el instructor dijo. La guía de scrum define la función del scrum master en la retrospectiva, y no es la de dirigirla (esta afirmación tiene matices para equipos poco maduros en scrum, pero vale como norma general).

Sprint Retrospective

183:752009322 (Antonio Jesús Ruiz Córdoba) — Fri, 14 Dec 2018 12:20:35 GMT

Inspeccionamos al equipo.

El Sprint Retrospective, conocido también como retrospectiva o "retro", es el evento que pone fin al Sprint. Consiste en una reunión de un máximo de 3 horas para Sprints de un mes, en la que el equipo se inspecciona a sí mismo y crea un plan de mejoras para el próximo Sprint.
Según vemos en la guía de Scrum, el propósito de la retro se divide en tres puntos fundamentales:

Inspeccionar el último Sprint a nivel de personas, relaciones, procesos y herramientas.
Identificar y ordenar los elementos más importantes que fueron bien y las posibles mejoras.
Crear un plan para mejorar la forma en la que el equipo realiza su trabajo.

Este evento es ideal para buscar la forma de incrementar la calidad del producto mediante la mejora de los procesos y la adaptación del " Definition of Done ".
La salida de este evento será parte de la entrada al Sprint Planning.

Hay muchas técnicas distintas sobre cómo realizar la reunión. La guía de Scrum no menciona ninguna en concreto con lo que da total libertad a la hora de cómo hacerlo.
Lo que sí menciona es que la función del Scrum Master en este evento es la de asegurarse que el evento sea positivo y productivo, además de motivar al equipo para que mejore y participar en la reunión como uno más.

Sprint Review

183:752009322 (Antonio Jesús Ruiz Córdoba) — Sun, 25 Nov 2018 12:54:49 GMT

Inspeccionando el trabajo hecho en el Sprint

El Sprint Review es una reunión informal que se realiza al final de cada Sprint y a la que acuden tanto el Scrum Team como cualquier interesado en el producto (invitado por el Product Owner). La duración máxima de este evento es de una hora por semana del Sprint.
El objetivo de esta reunión es obtener feedback de los stakeholders (interesados) y fomentar la colaboración de éstos con el Scrum Team para determinar, según el estado del Product Backlog, los elementos que se podrían hacer para optimizar el valor.

Es habitual oír llamar a esta reunión "demo" erróneamente, puesto que la demostración del incremento es sólo una parte del evento. Además, invitar a un interesado a "una demo", le hace asistir de forma pasiva, en la que sólo va a ver qué se ha hecho. Es importante que el Scrum Master haga entender a todos los asistentes que se espera una actitud activa en la reunión para obtener un feedback que resulte útil para la evolución tanto del equipo como del producto.

Según la guía de Scrum, durante el Sprint Review:

El Product Owner explica qué elementos del Product Backlog se han finalizado y cuáles no.
El Development Team comenta qué cosas fueron bien, qué problemas hubo y cómo se solucionaron durante el Sprint. Posteriormente enseña el trabajo terminado y responde preguntas sobre el incremento.
El Product Owner comenta el estado actual del Product Backlog, proyecta objetivos probables y, si es necesario, posibles fechas de entrega según el progreso obtenido.
Todo el grupo colabora sobre cómo se debería continuar, de manera que la salida del Sprint Review se convierte en parte de la entrada para el siguiente Sprint Planning.
Se revisa cómo el mercado o el uso potencial del producto puede haber cambiado lo más valioso con lo que continuar. Además, también se revisa la cronología, presupuesto, capacidades potenciales y el mercado para definir futuras funcionalidades.

Daily Scrum

183:752009322 (Antonio Jesús Ruiz Córdoba) — Fri, 16 Nov 2018 15:46:04 GMT

La evolución diaria del Sprint

El Daily Scrum es una reunión que ocurre todos los días del Sprint, con una duración máxima de 15 minutos, la cual, para reducir complejidad, se realizará a la misma hora y en el mismo lugar. En esta reunión, el Development Team se reúne para inspeccionar la evolución del trabajo realizado desde el último Daily Scrum y adaptar el trabajo restante en caso de ser necesario.
La presencia del Product Owner no es necesaria, y en equipos maduros, ni siquiera la del Scrum Master. Es una reunión del Development Team para el Development Team. No una reunión de seguimiento, ni de status ni de justificación del trabajo realizado.
Generalmente, la reunión se enfoca en tres preguntas principales:

¿Qué hice ayer para ayudar al equipo a cumplir el objetivo del Sprint?
¿Qué haré hoy para ayudar al equipo a cumplir el objetivo del Sprint?
Impedimentos o bloqueos que puedan impedir al equipo cumplir el objetivo del Sprint.

Una vez terminado el Daily Scrum, es habitual que el equipo, o parte de éste, se reúna para solucionar los problemas que hayan salido a la luz durante la sesión.

Las ventajas que ofrece esta reunión son evidentes:

Optimiza la colaboración del equipo.
Mejora la comunicación, disminuyendo así la necesidad de hacer otras reuniones.
Se mejora el conocimiento del equipo.
Se identifican impedimentos.
Se promueve la toma rápida de decisiones.

No obstante, para obtener dichas ventajas, es imprescindible realizar el Daily Scrum con total transparencia .

Además, si el equipo tiene un " Scrum Dashboard " y/o un " Sprint Burndown Chart ", éste es el momento ideal para actualizarlos. El " Scrum Dashboard " durante la intervención de cada miembro del equipo. El " Sprint Burndown Chart ", al final de la sesión.

El Sprint Planning

183:752009322 (Antonio Jesús Ruiz Córdoba) — Wed, 14 Nov 2018 18:37:09 GMT

La planificación del Sprint

El Sprint Planning, como su propio nombre indica, es una reunión cuyo objetivo es definir la planificación del Sprint , y se realiza al inicio de éste. Todo el Scrum Team participa en él y tiene una duración máxima de dos horas por cada semana de duración del Sprint.
Esta reunión se divide en dos partes:

¿Qué se va a realizar?
¿Cómo se se va a hacer?

En la primera parte el Product Owner acuerda con el Development Team el objetivo del Sprint y los elementos del Product Backlog que lograrían dicho objetivo. Para ello, además del propio Product Backlog, se tendrá en cuenta tanto el último incremento del producto, el rendimiento del equipo en otros Sprints y la capacidad proyectada de éste. Con todo esto, el equipo de desarrollo decidirá el número de elementos del Product Backlog que es capaz de realizar.
Para finalizar este primer bloque, el equipo Scrum definirá el Sprint Goal, es decir, la meta a la que se llegaría con la implementación de los elementos seleccionados, que además sirve de guía al equipo del por qué se está desarrollando dicho incremento.
En la segunda parte, el Development Team decide cómo transformará los elementos seleccionados en la primera parte, en un incremento de trabajo terminado. El Product Owner podrá ausentarse durante esta parte, aunque deberá estar disponible tanto para resolver las dudas que surjan durante la reunión como para reajustar la cantidad de trabajo a realizar si durante este bloque el equipo detecta que la cantidad de trabajo es demasiada o insuficiente.

Por último, el Development Team debe ser capaz de explicar cómo va a crear el incremento esperado al Product Owner y al Scrum Master.

El Sprint

183:752009322 (Antonio Jesús Ruiz Córdoba) — Fri, 02 Nov 2018 11:53:07 GMT

El tiempo en Scrum

Para asegurar un feedback continuo, un proyecto Scrum se divide en muchos " subproyectos ". A esa división es a lo que se conoce como Sprint.
Un Sprint no es más que un periodo de tiempo, en el que un Scrum Team es capaz de entregar un incremento terminado de producto. La guía de Scrum limita dicho periodo de tiempo a un " time-box " de un mes máximo, pero con un matiz importante: Cada vez que la guía especifica un " time-box " en un evento, ese tiempo se puede reducir si se finaliza el objetivo a conseguir. Sin embargo el Sprint es el único que, una vez empezado no puede cambiar su duración.
Durante un Sprint, ocurren todos los eventos de Scrum: Se comienza con el Sprint Planning, se realizan los Daily Scrum y se acaba con el Sprint Review seguido del Sprint Retrospective. Una vez acaba un Sprint, se da comienzo al siguiente.

El objetivo del Sprint es asegurarse de que el trabajo no útil (por error, porque el resultado no es lo que espera el cliente, porque las prioridades han cambiado...) es el mínimo posible. Por ese motivo, la recomendación siempre es que la longitud del Sprint sea la menor posible, de forma que la cantidad de feedback recibido sea la mayor posible, y que en caso de tener que tirar trabajo, éste se reduzca al máximo. Es decir, disminuimos el riesgo y la complejidad .
¿Cuál debe ser la longitud de un Sprint? Pues depende del equipo y del proyecto. La longitud de un Sprint debería ser la menor posible en la que el equipo se sienta cómodo para realizar un incremento de producto al final del Sprint. Si el equipo no es capaz de realizar dicho incremento, la longitud es demasiado corta y el Sprint pierde su función. Si el Sprint es demasiado largo, la cantidad de feedback se reduce y potencialmente se podría tener que deshacer más trabajo del necesario.
No obstante, a la hora de elegir una duración para el Sprint, la recomendación es hacerla en semanas. ¿Significa esto que está prohibido hacer Sprints de 3 días? No. La duración del Sprint es libre, siempre que sea menor a un mes. Sin embargo, por logística para el equipo y sobre todo para los Stakeholders, es mejor hacerlo en semanas. Con ello conseguirás que todos tengan en su calendario algo como "cada dos lunes tengo una reunión con el equipo XXX para su Sprint Review". Si en lugar de eso tienes que una semana la reunión es el jueves, la siguiente es martes, la otra no hay... sólo conseguirás que el número de Stakeholders que asistan se reduzcan por problemas de agenda.

Otra recomendación es, que según avanza el proyecto y con el acuerdo del equipo e interesados, se juegue con la duración del Sprint.
Sé lo que estás pensando: " ¡Pero si los Sprints tienen todos la misma duración! ". Es cierto, los Sprints son de duración fija y no se cambian... una vez empezados . No vale incrementar el Sprint un par de días para que dé tiempo a terminar la última tarea. Si una tarea no se ha terminado, se verá en las reuniones dedicadas a la inspección (Review y Retrospective) qué ha pasado con ella, por qué no se ha terminado y qué acciones se pueden tomar a futuro para evitar que pase de nuevo. Si se amplía un Sprint una vez empezado, sólo consigues engañarte a ti mismo.
Explico la idea con un ejemplo: Llevamos 5-6 Sprints con una cadencia de 3 semanas y vemos que estamos entregando más trabajo de lo que podríamos considerar como "mínimo producto viable". Ahí podríamos ver con el equipo e interesados la opción de bajar la cadencia a 2 semanas, probar durante 2-3 Sprints y ver qué pasa. Para estos casos, tenemos siempre en cuenta los pilares de Scrum (transparencia, inspección y adaptación), así que básicamente probamos, si va bien lo mantenemos y si no funciona volvemos a como estábamos.

Durante un Sprint:

No se realizan cambios que puedan afectar al Sprint Goal (objetivo del Sprint).
Los objetivos de calidad no disminuyen
El alcance puede clarificarse y renegociarse entre el Product Owner y el Development Team según se aprende.

" Creo que lo entiendo. Mi objetivo del Sprint es hacer un formulario de color verde para una web y mi Sprint de un mes empezó hace 3 días. Me acabo de enterar que el cliente quiere cambiar los verdes por naranjas, pero como la duración del Sprint no se cambia una vez empezado y tampoco se admiten cambios que afecten al objetivo, pues dentro de 27 días, en el Sprint Review me dirán que en lugar de verde lo quieren naranja y ya "

Si se te ha pasado lo anterior por la cabeza, sigue leyendo: Scrum no va en contra del Agile Manifesto . Dos de los puntos del Agile Manifesto son "Respuesta ante el cambio" y "Colaboración con el cliente", y parece claro que la idea anterior no va por el mismo camino. El cliente no estará muy contento si le decimos que el plan era poner verde y hasta dentro de un mes no vamos a cambiar el plan.
Si sabemos que el objetivo del Sprint se ha vuelto obsoleto, Scrum permite realizar lo que se conoce como "Cancelación del Sprint".
La cancelación del Sprint la realiza el Product Owner (aunque pueden solicitárselo los Stakeholders, el Scrum Master o el Development Team) cuando el el objetivo del Sprint queda obsoleto. Esto puede pasar por un cambio de dirección de la compañía, de las condiciones del marcado o de la tecnología, entre otros. En general, cuando el Sprint deje de tener sentido dadas las circunstancias.
Cuando se cancela un Sprint, se realiza un Sprint Review para ver si los elementos terminados pueden ser entregables. Todos los no terminados pasarán al Product Backlog, donde el Product Owner los revisará. Si tienen sentido, se reestimarán y si no, desaparecerán del Product Backlog.
Dado que las cancelaciones de Sprint consumen recursos, suelen ser traumáticas para el Scrum Team y los Sprints son de corta duración, es algo muy infrecuente y rara vez tienen sentido. No obstante, y como otro punto más a favor de los Sprints cortos, mientras menor duración tenga éste, más improbable es que se produzca una cancelación.
Por último, una duda muy común que me hacen con la duración del siguiente Sprint tras una cancelación: ¿Duración normal o se disminuye el nuevo para que finalice cuando se esperaba que finalizara el cancelado? Pues como todo, depende. Lo ideal es que el nuevo Sprint tenga la cadencia normal que estaban teniendo los Sprints anteriores, sin embargo, por motivos logísticos lo más habitual es que el nuevo Sprint sea de una duración menor a la habitual para que el Sprint Review del nuevo coincida con el ya estaba planeado para el que se canceló, siempre que el equipo sea capaz de terminar algo entregable para esa fecha. Cualquiera de las opciones es igualmente válida.

Ya soy Agile Coach certificado

183:752009322 (Antonio Jesús Ruiz Córdoba) — Fri, 26 Oct 2018 14:52:45 GMT

Un gran paso para seguir creciendo

Ya puedo decir orgulloso que tengo el certificado de Agile Coach.
Tras una formación de varios días con David Martí (formador Agile de prestigio y traductor oficial de la guía de Scrum al castellano) y su equipo, he conseguido aumentar mis conocimientos en el mundo Agile.
La formación consta de 4 bloques, avanzando en todos ellos en amplitud:

Coaching
Metodologías/Frameworks Agile
Escalado
Management/Cultura 3.0

De estos cuatro bloques, el de escalado fue el que me pareció más interesante. En primer lugar por el propio contenido y por poder ampliar el foco desde "un equipo" con el que se centra Scrum al de "múltiples equipos", pero sobre todo porque pude conocer más sobre los distintos marcos de escalado: Nexus, SAFe, LeSS y Scrum@Scale.

Ahora toca la parte más compleja: Seguir investigando, leyendo e informándome para ir profundizando en cada uno de los distintos bloques, con el objetivo siempre de seguir creciendo, ganando experiencia y aumentando conocimientos.

El Development Team

183:752009322 (Antonio Jesús Ruiz Córdoba) — Sun, 21 Oct 2018 15:08:10 GMT

El equipo de desarrollo

El Development Team está compuesto por el conjunto de profesionales que realizan el trabajo para entregar un incremento del producto al final del sprint, el cual debe estar listo para poder ser puesto en producción en caso de ser requerido para ello.
Este equipo deberá ser lo suficientemente grande como para ser capaz de entregar un incremento de producto, pero no demasiado pues necesitaría mucha coordinación y aumentaría la complejidad para que el proceso empírico sea útil.
La recomendación es que el tamaño del equipo se encuentre entre los 3 y los 9 miembros. Una campana de Gauss donde los valores más óptimos están entre 3 y 9 es el resultado de varios estudios que demuestran cómo este tamaño mejora la interacción en el equipo, mientras que con tamaños menores, y sobre todo mayores se pierde eficacia. Esto es debido principalmente por los canales de comunicación que se crean por cada miembro del equipo. Estos canales crecen de forma exponencial con cada miembro, expresado en la forma matemática N(N-1)/2, donde N es el número de miembros.

Según la guía de Scrum, los Development Teams tienen las siguientes características:

Son auto-organizados. Nadie (ni siquiera el Scrum Master) indica al Development Team cómo convertir elementos del Product Backlog en Incrementos de funcionalidad potencialmente desplegables.
Los Development Teams son multifuncionales, con todas las habilidades necesarias para crear un Incremento de producto.
Scrum no reconoce títulos para los miembros de un Development Team, independientemente del trabajo que realice cada persona.
Scrum no reconoce sub-equipos en el Development Team, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas, arquitectura, operaciones, o análisis de negocio.
Los miembros individuales del Development Team pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Development Team como un todo.

De la guía podemos sacar varias conclusiones:

El Development team es auto-organizado y multifuncional (el equipo es multifuncional, no cada miembro de dicho equipo).
El equipo es un todo y por lo tanto gana o pierde junto. No hay un conjunto o un individuo que gane o pierda dentro del equipo, sino que el equipo al completo es el que recibe los elogios o las críticas y es el equipo al completo el que debe intentar mejorar continuamente.
Independientemente de los conocimientos, aptitudes o experiencia de cada miembro, todos en el equipo de desarrollo son desarrolladores. Con esta etiqueta, Scrum se asegura que nadie está por encima del resto y se fomenta el crecimiento como equipo.

El Product Owner

183:752009322 (Antonio Jesús Ruiz Córdoba) — Sun, 14 Oct 2018 17:35:52 GMT

El propietario del producto

El Product Owner es la persona del Scrum Team responsable de maximizar el valor del trabajo del equipo de desarrollo. Además, es el único responsable de la gestión del Product Backlog.

Según la guía de Scrum, las funciones del product backlog incluyen, entre otras:

Expresar claramente los elementos del Product Backlog.
Ordenar los elementos en el Product Backlog para alcanzar los objetivos y las misiones de la mejor manera posible.
Optimizar el valor del trabajo que realiza el Development Team.
Que el Product Backlog sea visible, transparente y claro para todos y que muestre lo que el equipo trabajará a continuación.
Asegurar que el Development Team entiende los elementos del Product Backlog a nivel necesario. El Product Owner podría hacer el trabajo anterior o delegarlo en el Development Team. Sin embargo, en ambos casos el Product Owner sigue siendo el responsable de dicho trabajo.
El Product Owner es una única persona, no un comité. El Product Owner podría representar los deseos de un comité en el Product Backlog, pero aquellos que quieran cambiar la prioridad de un elemento del Backlog deben hacerlo a través del Product Owner.

Para conseguir todo esto, es muy importante que el Development Team tenga acceso directo al Product Owner, de hecho, idealmente se sentarán juntos. También es clave que se respeten las decisiones del Product Owner, sobre todo a nivel de la organización, si bien éste no debe imponer su criterio sino consensuarlo. Por último, el equipo trabajará en tareas que el Product Owner conozca, de forma que nadie externo al equipo pueda solicitar que alguien trabaje en otra cosa.

El Scrum Master

183:752009322 (Antonio Jesús Ruiz Córdoba) — Thu, 11 Oct 2018 16:51:45 GMT

Un líder-sirviente para el equipo

El Scrum Master es un sirviente líder que está al servicio del, y para el Scrum Team. Se encarga de ayudar a entender la teoría de Scrum, prácticas, reglas y valores.

Según la guía de scrum, el Scrum Master sirve al Product Owner, al equipo de desarrollo y a la organización de la siguiente forma:

Al Product Owner le sirve de las siguientes formas (no exclusivas):
- Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el Scrum Team de la mejor manera posible.
- Encontrar técnicas para gestionar el Product Backlog de manera efectiva.
- Ayudar al Scrum Team a entender la necesidad de contar con elementos del Product Backlog claros y concisos.
- Entender la planificación del producto en un entorno empírico.
- Asegurar que el Product Owner conozca cómo ordenar el Product Backlog para maximizar el valor.
- Entender y practicar la agilidad.
- Facilitar los eventos de Scrum según se requiera o necesite.
Al Development Team le sirve de las siguientes formas (no exclusivas):
- Guiar al Development Team en ser auto-organizado y multifuncional.
- Ayudar al Development Team a crear productos de alto valor.
- Eliminar impedimentos para el progreso del Development Team.
- Facilitar los eventos de Scrum según se requiera o necesite.
- Guiar al Development Team en entornos organizacionales en los que Scrum aún no haya sido adoptado y entendido por completo.
A la organización le sirve de las siguientes formas (no exclusivas):
- Liderar y guiar a la organización en la adopción de Scrum.
- Planificar las implementaciones de Scrum en la organización.
- Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de producto.
- Motivar cambios que incrementen la productividad del Equipo Scrum.
- Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.

De todo esto se puede desprender que:

Un Scrum Master es un "empleado" del equipo. No lo es de ningún mánager ni de ningún representante de RRHH.
La principal función es ayudar al equipo a mejorar día a día, eliminando los impedimentos, bloqueos e interrupciones externas y mostrando cómo hacerlo.
No decidirá por el equipo, sino que será la voz de éste.
No impondrá nada al equipo. Ayudará a éste a entender la necesidad de tomar algunas directrices.
No es un secretario, ni para el equipo ni fuera de éste.

Pilares y valores de Scrum

183:752009322 (Antonio Jesús Ruiz Córdoba) — Fri, 21 Sep 2018 17:01:25 GMT

La meta del equipo Scrum

Como vimos en " ¿Qué es Scrum? ", el empirismo o experiencia es parte de la base para tomar decisiones dentro de Scrum. Para la implementación de este proceso empírico, se usan lo que se conoce como los pilares de Scrum:

Transparencia : Deja que se vea qué haces, cómo lo haces y en qué fallas. Es la única forma de mejorar.
Inspección : Se debe inspeccionar con frecuencia el producto, la metodología, las herramientas... Mientras antes se encuentre un pequeño problema, antes se evitará un gran problema.
Adaptación : El equipo irá minimizando los defectos dando pequeños cambios que ayuden a mejorar el trabajo diario, y por ende, el producto final.

Estos tres pilares, sólo funcionan si se hacen de forma conjunta. De nada nos sirve ser transparentes, si no inspeccionamos nada. Tampoco sirve de inspección, si después seguimos haciendo lo mismo. Tampoco son útiles los cambios si no los hacemos públicos ni indicamos los efectos positivos y negativos que hemos ido encontrando.

El éxito de un equipo Scrum llega cuando éste se sustenta en los pilares que hemos mencionado y es el Scrum Master el que fomenta entre el equipo el cambio de mentalidad que consiga unos cimientos sólidos donde colocar estos pilares.
Para ello, la mejor opción es incorporar al equipo los valores de Scrum. Cuando estos valores son vividos por el equipo, los pilares se materializan y fomentan la confianza de todo el mundo.
Los valores de los que hablamos son:

Coraje : Para hacer las cosas bien y trabajar en los problemas difíciles, saliendo de la zona de confort.
Focalización : En el trabajo del sprint y los objetivos del equipo.
Compromiso : En finalizar de forma exitosa cada iteración según las metas del equipo.
Respeto : Tanto entre los miembros del equipo como fuera de éste, se confía en la profesionalidad de los demás y se respeta el resto de opiniones para lograr ser más capaces e independientes.
Apertura : Del equipo e interesados, a todo el trabajo y a los desafíos que se les presenten al realizarlo.

Cuando un equipo hace suyo todos los puntos de los pilares y valores, puede conseguir un máximo nivel de auto-organización y además facilita la incorporación, y evaluación, de pequeños cambios periódicos que tengan el objetivo de buscar la mejora continua del equipo.

Por último, recuerda siempre que vayas a introducir algún cambio en el equipo, hacer referencia a los pilares:
" Otros equipos están haciendo XXXXX para ZZZZZ y les está yendo bien... " (transparencia) " ...podemos probarlo durante uno o dos sprints... " (inspección) " ...si nos funciona lo dejamos, si nos supone un problema lo quitamos y si vemos mejora lo cambiamos " (adaptación).

¿Qué es Scrum?

183:752009322 (Antonio Jesús Ruiz Córdoba) — Sun, 16 Sep 2018 10:49:57 GMT

Scrum es un framework Agile

Scrum es un marco de trabajo basado en Agile caracterizado por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.
Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados.
Solapamiento de las diferentes fases del desarrollo, en lugar de realizarlas una tras otra en un ciclo secuencial o de cascada

Entre todas las metodologías Agile que se pueden encontrar, Scrum es la más extendida. El principal motivo es por ser ligero y simple, tal y como se autodefine en la guía de scrum , aunque como bien dice la guía, también es difícil de dominar.

Para facilitar esa sencillez, Scrum prescribe una serie de roles, eventos y artefactos. Veamos una breve descripción de todos ellos:

Roles
- Scrum Master : Conocedor de Scrum, sus pilares y valores. Es un sirviente líder del, y para el Scrum Team.
- Product Owner : Dueño del producto y encargado de obtener el máximo retorno de inversión.
- Development Team : O equipo de desarrollo, lo componen todos aquellos miembros que ayudan en la creación de un incremento del producto. Para Scrum, un QA, un analista, un gestor de base de datos, un programador web... todos ellos son desarrolladores.
Eventos
- Sprint : Tiempo en el que se producirá un incremento en el producto. Siempre constante, suele variar entre 1 y 4 semanas.
- Sprint Planning : Reunión que da inicio al sprint y se decide cuál será el incremento que se realizará en ese Sprint.
- Daily Scrum : Reunión diaria para conocer el estado de las tareas. Máximo 15 minutos.
- Sprint Review : Reunión al final del Sprint con el equipo e interesados para revisar el incremento del producto y con el objetivo principal de obtener feedback.
- Sprint Retrospective : Reunión al final del Sprint, sólo del equipo, para ver qué fue bien, qué se puede mejorar y crear un plan para implementar dichas propuestas de mejora.
Artefactos
- Product backlog : Lista de tareas a realizar en el producto. El Product Owner es el responsable de su estado y priorización.

Sprint backlog : Lista de tareas que se realizarán en el sprint actual. El Equipo de Desarrollo (Development Team) es el responsable de su estado.
Increment : Conjunto de tareas terminadas durante el Sprint (y en Sprints anteriores) y que dan valor al producto.

En próximas entradas veremos con más detalle cada uno de los puntos anteriores.
No olvides apuntarte a la newsletter para mantenerte informado.

¿Qué es eso del Agile?

Sun, 09 Sep 2018 14:34:48 GMT

Agile es una mentalidad

Empecemos con un poco de historia:

En 1986, Ikujiro Nonaka e Hirotaka Takeuchi publicaron " The New New Product Development Game " donde apareció por primera vez el concepto de Scrum.
En 1995, Ken Schwaber y Jeff Sutherland presentaron el " Scrum Development Process " en el OOPSLA’95 donde dieron a conocer las reglas por las que se iba a basar Scrum.
En 2001, se firmó el " Manifesto for Agile Software Development " entre los representantes de los principales marcos de trabajo.

Y ahora que ya tenemos encuadrados los principales eventos, veamos qué es realmente Agile:
El movimiento Agile surgió como respuesta al modelo en cascada que se había impuesto ampliamente en el mundo del desarrollo software.
Este modelo en cascada se caracterizaba básicamente por contratos cerrados, en los que en una fase inicial se le indicaba al cliente las características de su software y cuándo se le iba a entregar. Posteriormente, esos requisitos se pasaban al equipo de diseño, cuando éste acababa al equipo de desarrollo, cuando éste acababa al equipo de pruebas y cuando éste acababa se entregaba al cliente. ¿Problema? Al estar todo tan cerrado, no había margen a rectificaciones (salvo con penalizaciones por contrato), si finalmente se hacían el coste era demasiado elevado, los errores se encontraban en fases finales por lo que las correcciones eran pesadas, los productos eran de dudosa calidad por lo cerrado de los plazos y porque en caso de problemas la última fase (la de pruebas) era la que acababa recortándose para ajustarse a tiempo... En resumen, " la culpa siempre es de otro " (según el analista el cliente no sabía lo que quería, según el desarrollador el diseño era muy malo, según el probador le entregaron la aplicación el último día, según el cliente el producto recibido no funciona como él esperaba y además ya está anticuado)
Con " The New New Product Development Game ", basado en el análisis de empresas como Fuji-Xerox, Canon, Honda, Hewlett-Packard, etc., se puso la primera piedra para solventar el problema, creando el concepto Scrum.

Con esa base, comenzaron a salir distintos frameworks Agile. Scrum creó sus reglas en 1995 en el OOPSLA. También en los 90 salieron otros como Extreme Programming, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming... Si bien al comienzo su principal función parecía ser la de desprestigiar a los otros, en 2001 se unieron para firmar el conocido como " Agile Manifesto ".
Este acuerdo comienza con una declaración de intenciones, dejando claro cuáles son los valores por los que se rigen todos ellos:

Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
Colaboración con el cliente sobre negociación contractual.
Respuesta ante el cambio sobre seguir un plan.

Aunque no se le quita valor a los elementos de la derecha, sí que se le da el máximo valor a los elementos de la izquierda.
De estos valores se pueden desprender las siguientes conclusiones:

Es vital mantener a un equipo motivado.
El valor de la aplicación está en su buen funcionamiento.
El primer objetivo debe ser la máxima satisfacción del cliente.
Hay que ser flexible ante las evoluciones del mercado.

Una vez confirmados los valores Agile, se incluyeron los 12 principios sobre los que todos los frameworks se basarían:

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
El software funcionando es la medida principal de progreso.
Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Puedes encontrar más información sobre los valores, los 12 principios, los firmantes y su historia en el agile manifesto .

¿Y todo esto para qué?

183:752009322 (Antonio Jesús Ruiz Córdoba) — Tue, 04 Sep 2018 00:00:00 GMT

Para crecer...

Voy a empezar con una cita de George Bernard Shaw : "Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tu tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

En este blog hablaremos de Agile (principalmente de Scrum), buscaremos buenas prácticas, cosas a evitar y cómo intentar mejorar el trabajo diario de un equipo de desarrollo.
Intentaré compartir contigo mis experiencias como Scrum Master, con qué he tenido que enfrentarme y cómo lo he solucionado (o al menos intentado).

¿Y qué espero de ti? Espero tu ayuda y tu participación. Espero que opines y que des otro punto de vista. Espero que si algo te resulta útil, me cuentes cómo te ha ayudado o con qué problemas te has enfrentado.
Con esos sencillos gestos, yo sabré que mi participación es útil y que te ha servido de ayuda. Además, ese " feedback " ayudará a cualquier otra persona que pueda tener un problema similar.

¿Cómo? Hay tres opciones:

Comenta las entradas con Disqus. Puedes usar tus redes sociales o hacerlo de forma anónima.
Usa el formulario de contacto, para lo que necesites (proponer otras entradas, preguntar dudas...).
Apúntate a la newsletter para conocer las últimas entradas del blog. No recibirás publicidad, ni compartiré tus datos. Si te apuntas porque quieres saber más del blog tendrás eso y sólo eso.

Y hasta aquí esta primera entrada, con mi declaración de intenciones.
¿Quieres que crezcamos juntos?