Bienvenido
¿Cómo te puedo ayudar?
Si buscas formación de Scrum con certificación oficial, si necesitas ayuda en la transformación de tu empresa o simplemente quieres saber algo más de Agile, estás en el lugar ideal. Continúa leyendo...
Formación en Agilidad y Scrum
Próximos cursos presenciales (2024/25):
Scrum Master
- Curso Scrum Master Madrid:
- 13-14 de Junio: Últimas 11 plazas.
Product Owner
- En tu provincia. Pdte. de nueva fecha.
¡Haz tu propuesta!
Más info.
Agile Coach
- En tu provincia. Pdte. de nueva fecha. ¡Haz tu propuesta! Más info.
Scrum Master Avanzado
- En tu provincia. Pdte. de nueva fecha. ¡Haz tu propuesta! Más info.
¿Tu curso no está en la lista? ¿Necesitas otra fecha u otro lugar?
¡Usa el formulario de contacto y haz tu propuesta!

Formación a distancia (2024/25):
Online (Directo):
100% en directo:
- Curso Scrum Master Online:
- 16-19 de Junio:
Últimas 3 plazas.
- Curso Product Owner Online:
- 26-29 de Mayo: Plazas limitadas.
- Curso Agile Coach Online:
- Pendiente de nueva fecha.
- Curso Scrum Master Avanzado Online:
- Pendiente de nueva fecha.
Ya han confiado en mí:
Algunas de las empresas que ya han contado con mis servicios de formación y/o consultoría. Puedes ver más en mi portfolio:
Últimas entradas del blog:

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

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