Los postit, quizás la herramienta más conocida de Scrum

Scrum

Scrum

Scrum y los principios básicos de la gestión de proyectos

Hay miles de libros y artículos sobre Scrum. Es imposible que una entrada de novanotio se sitúe en las primeras páginas de los buscadores. Entonces, ¿por qué molestarse en escribir otro artículo sobre metodologías ágiles? Y ya puestos, ¿por qué incluir Scrum dentro de Novanotio Certified cuando hay academias que imparten ya esta formación?

Desde luego no para describir la metodología o explicar sus ventajas.  Eso puedes encontrarlo aquí, aquí, aquí o aquí

Nuestra intención es reforzar vuestros conocimientos sobre los principios básicos de la gestión de proyectos.

Si entiendes los principios básicos, puedes adoptar con éxito Scrum o cualquier otra metodología.

A lo largo de nuestra historia hemos participado en proyectos bien gestionados que no seguían ninguna metodología formal.

También hemos participado en proyectos pobremente gestionados que cumplían al pie de la letra diferentes metodologías; CMMI, Waterfall, ITIL y sí, Scrum.

Estaba claro que la metodología por si misma no explicaba el éxito o el fracaso de la gestión del proyecto.

Tampoco explicaba por qué, con buena gestión o sin ella, la mayor parte de los proyectos sufrían retrasos y fuertes sobrecostes.

Son más importantes los fundamentos que las metodologías. Cuando conoces los problemas intrínsecos del desarrollo de software y dominas los principios básicos de la gestión de proyectos, puedes adoptar cualquier metodología. O no utilizar ninguna.

Las Cuatro Leyes

Las Cuatro Leyes condensan en cuatro sencillas frases buena parte de los conocimientos que necesitas para gestionar proyectos. Cómo enfocar la toma de requisitos, cómo organizar los equipos, cómo liderar a los consultores y cómo gestionar a los clientes. Todo en 35 palabras:

1ª ley. Las especificaciones son inciertas, imprecisas e infinitas.

2ª ley. One project, one team, one site.

3ª ley. Presión x Talento = Constante.

4ª ley. Alcance, Plazo y Calidad. Si fijas dos de ellas, la tercera se degrada porque es la variable de ajuste

Las Cuatro Leyes son una forma sencilla de enseñar los principios básicos de la gestión de proyectos. Nos gusta comenzar las visitas de seguimiento repasando estas 35 palabras, así las recordarás durante toda tu carrera profesional.

Nuestros artículos sobre Scrum

En esta serie de artículos vamos a analizar desde diferentes ángulos las similitudes entre Scrum y los principios básicos de gestión. Qué relación existe entre las Cuatro Leyes, los cuatro apartados del Manifiesto Ágil, los doce principios de Scrum y el proceso de desarrollo Scrum.

Espero de corazón que os ayuden a comprender los enormes desafíos a los que nos enfrentamos en la construcción y soporte de sistemas informáticos.

Con el tiempo añadiremos nuevas entradas, no olvides visitarnos de vez en cuando.

El proceso de desarrollo Scrum es eficiente porque cumple las Cuatro Leyes de gestión de proyectos informáticos.

Si no entiendes los fundamentos de Scrum, vas a implantar la metodología como si fuera una religión. Y tus proyectos no mejorarán.

Las empresas cometen una y otra vez los mismos errores al implantar Scrum.


El proceso de desarrollo SCRUM y las Cuatro Leyes

El proceso de desarrollo SCRUM y las Cuatro Leyes

¿Por qué el proceso de desarrollo SCRUM es más eficiente que las metodologías tradicionales Waterfall?

En este primer artículo de la serie que dedicamos a Scrum, vamos a explicaros la relación entre el proceso de desarrollo Scrum y los principios básicos de gestión de proyectos.

Nuestro objetivo es que entendáis por qué motivos Scrum es más eficiente que las metodologías tradicionales waterfall.

El proceso de desarrollo SCRUM es una implementación de las Cuatro Leyes

Los beneficios de Scrum se derivan de que cumple las Cuatro Leyes Básicas de la gestión de proyectos tecnológicos. Por eso es más eficiente que las metodologías clásicas de desarrollo en cascada o Waterfall, que no cumplen ninguna de ellas.

Recuerda que hay otras implementaciones de las Cuatro Leyes como XP (extreme programming), que aportan mejoras de productividad similares.

SCRUM cumple la 1ª ley.

Las especificaciones son inciertas, imprecisas e infinitas.

La primera ley nos advierte tres cosas:

– Que el tiempo empleado en especificar es, en general, tiempo perdido

– Que la única interpretación válida de la especificación es la del cliente.

– Que no es posible finalizar los trabajos.

¿Como responde Scrum a estos tres desafíos?

– En Scrum el diseño es muy liviano; los principales requisitos se capturan en Epics y Features, cuya extensión es de un párrafo. Epics y Features se descomponen en Historias de Usuario cuya extensión es de una sola línea. El tiempo que se ahorra en la especificación se dedica a desarrollar código, asumiendo que tendremos que modificarlo cuando se lo presentemos al cliente.

– Se incorpora al squad un representante del cliente, el Product Owner, cuya misión es ayudar a los programadores a interpretar las historias de usuario.

– El cliente asume que no se concluirán los desarrollos, pero el Product Owner se asegura de que el software construido resuelva sus principales necesidades.

SCRUM cumple la 2ª ley.

One Project, One Team, One Site.

La segunda ley nos instruye sobre la importancia de construir vínculos emocionales y relaciones de confianza.

Y la mejor forma de construir vínculos y relaciones es mediante el contacto diario y la dedicación exclusiva.

¿Cómo construye Scrum vínculos y relaciones?

En Scrum los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí.

El grupo es autosuficiente para hacer sus tareas e incluye a programadores, testers y en caso necesario arquitectos de sistemas o administradores de BBDD.

El Product Owner es un miembro más del equipo, y está junto a ellos toda la jornada para ayudarles a interpretar las historias de usuario.

SCRUM cumple la 3ª ley.

Presión x Talento = Constante.

La tercera ley nos recuerda que la velocidad de avance de los desarrollos sólo depende del número de ideas que aporten los consultores del equipo, y no del número de integrantes ni del número de horas de su jornada.

Para que florezca el talento es necesario rebajar la presión. Se ha demostrado que incrementos de la jornada de trabajo producen retrasos en los desarrollos y, por el contrario, reducir la jornada a cinco horas diarias mejora la productividad un 30%.

¿Cómo elimina Scrum la presión?

En Scrum no es obligatorio completar todas las Historias planificadas para el sprint.

Aunque buena parte de los desarrollos pasan sus test, algunos pueden quedar a medias o no superar las pruebas. Estas Historias vuelven al team backlog y se abordan (o no) en siguientes sprints.

SCRUM cumple la 4º ley.

El triángulo de Acero.

La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero necesariamente se degrada.

Como cliente debes elegir entre

– Sacrificar el Alcance y entender que ciertas funcionalidades no se construirán.

– Sacrificar el Plazo (y multiplicar el coste) y asumir que el sistema siempre estará en desarrollo.

– Sacrificar la Calidad, y aceptar que obtendrás un sistema con errores en producción y complejo de operar.

Habitualmente en los contratos se fijan Alcance, Plazo y Calidad. ¿El resultado? En el 80% de los proyectos se sacrifican las tres variables simultáneamente. ¿Es posible elegir peor metodología?

¿Qué variable se degrada en el proceso de desarrollo SCRUM?

La metodología SCRUM se asegura que la única variable sacrificada sea el Alcance.

– El Plazo, y por consiguiente el presupuesto, se establecen en el contrato. El Alcance se deja abierto.

– Para garantizar la Calidad, no se permite entregar desarrollos que no hayan superado sus correspondientes pruebas unitarias.

– Para maximizar el retorno de la inversión, el cliente desplaza un Product Owner a los squads para priorizar aquellos desarrollos que aporten más valor a la empresa.

¿Puedo mejorar la eficiencia sin usar Scrum?

Como hemos visto, las ventajas de Scrum se derivan de que cumple los principios básicos de la gestión de proyectos.

Es frecuente que las organizaciones se obsesionen con la puntual observancia de sus rituales, lo que les lleva a cometer una y otra vez los mismos errores en su implementación, sin encontrar las prometidas mejoras de productividad.

Pero también es posible el caso opuesto. Puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin  implementar el proceso de desarrollo de Scrum.

Recuerdo mis primeras experiencias de trabajo a comienzos de los años 90, antes de la fundación de novanotio, donde usábamos una metodología que cariñosamente llamábamos ASDM (A Salto De Mata).

Nunca invertimos mucho tiempo en especificar, los compañeros éramos uña y carne, teníamos una fantástica relación con el cliente y nunca nos pidieron trabajar un fin de semana. ASDM se podía resumir en la frase ‘Trata bien a tus consultores y estos harán un gran trabajo’.

La productividad fue excelente hasta que la organización apostó por CMMI, una metodología más preocupadas por la especificación que por las personas.

Emplea con sabiduría los principios de la gestión de proyectos y cualquier metodología será la adecuada.


Es fácil confundir Scrum con una religión. No cambies el triángulo de acero por el ojo sagrado.

Scrum no es una religión

Scrum no es una religión

SCRUM no es una religión. SCRUM es una forma de aplicar las Cuatro Leyes Básicas de la gestión de proyectos. El proceso de desarrollo Scrum es eficiente porque cumple estas cuatro reglas.

Si entiendes los fundamentos de la gestión de proyectos informáticos, puedes adaptar SCRUM, o cualquier otra metodología, a tu empresa.

Pero si no conoces estos fundamentos, corres el riesgo de implantar SCRUM en tu organización como si fuera una poderosa religión.

Y no encontrarás la tierra prometida.

Si adoptas SCRUM como si fuera una religión…

SCRUM es la religión de los elegidos

Scrum es todopoderoso porque es la religión de los elegidos. Si quieres llegar a la tierra prometida de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.

Ya en los tiempos olvidados de las tarjetas perforadas, los profetas Brooks y DeMarco nos advirtieron que los proyectos son tan complejos que podemos trabajar en ellos por los siglos de los siglos. Imbuidos por el espíritu, propusieron abordar la solución en sucesivas iteraciones, meditando junto al cliente tras cada una de ellas qué se ha conseguido y qué se debe hacer a continuación.

El ritual SCRUM que inspiraron es como sigue:

La Sagrada Firma

El  Sumo Account Manager descubre una necesidad del cliente y prepara una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realiza sacrificios a Poseidón y ofrendas a Baco para que el cliente realice la Sagrada Firma.

La Sagrada Firma es el ritual más complejo y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de servicios indeterminados. No intentes explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, donde el alcance si estaba definido, en media sólo se entregaba el 50% de lo especificado.

El Product Backlog y el Team Backlog

Tras la Sagrada Firma, el cliente unge a uno de sus acólitos con la pesada responsabilidad del éxito de la empresa. A partir de ahora todos le conocerán como el venerable Product Owner.

En un concilio entre cliente, Account Manager y Product Owner, describen el sistema en una docena de tarjetas sagradas de una extensión de algunos párrafos llamadas Epics y Features. Las sagradas tarjetas se exponen a los acólitos en un altar de corcho llamado Product Backlog para que sean para ellos fuente de inspiración.

En sucesivos aquelarres, el Product Owner y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen su trabajo en un nuevo altar de corcho, el Team Backlog.

La implementación

Es el momento de comenzar los ritos de implementación.

El primero es formar la escuadra de desarrollo, con el Product Owner, un Scrum Master y entre cinco y siete consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario. Su sagrado apostolado incluye definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.

Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne para decidir qué Historias de Usuario intentarán implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. La escuadra intuye su velocidad de ejecución.

Cada mañana, antes de la salida del sol, la escuadra se reúne para maitines, rito también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera apto para depositar a los pies del cliente e implorar su aceptación.

El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.

El Sprint Review

Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se ofrece al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.

El Sprint Retrospective

El acto final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de ser más productivos en próximas iteraciones.

Que los Dioses te sean propicios

Sigue religiosamente este ritual y alcanzarás la tierra prometida con la bendición de los Dioses.

Los peligros de imponer SCRUM a tu organización como si fuera una religión

Los ritos de SCRUM son folclore, comportamientos llamativos que emplean otras organizaciones. Desconocemos su significado, pero hay cientos de artículos describiendo su éxito y son tentadores de imitar.

Un ejemplo de imitación del folclore. Una organización que compró una mesa de billar, pero despidió a un consultor por ir al médico. ¿Veis a lo que me refiero? Si te despiden porque estás enfermo y vas al centro de salud, ¿cuál será el castigo si estás sano y dejas de trabajar para hacer carambolas?

Si no conoces las reglas básicas de la gestión de proyectos, corres el riesgo de implantar SCRUM como si fuera una religión, y cometer los mismos errores que buena parte de las organizaciones.

Y entonces no llegarás a la tierra prometida.


¿Cuáles son los tres errores más frecuentes al implantar SCRUM?

Errores más frecuentes al implantar Scrum

Errores más frecuente al implantar Scrum

Vamos a repasar en este artículo los errores más frecuentes al implantar Scrum y sus consecuencias.

Muchos de los proyectos en los que participamos han comenzado su transición a las metodologías ágiles. El resultado más visible es que hacen ‘sprints‘ de tres o cuatro semanas, pero los incrementos de productividad siguen siendo una promesa; los proyectos continúan con sus dinámicas previas.

Y tiene sentido. ¿Por qué hacer el mismo trabajo en bloques de tres semanas va a mejorar la productividad? Scrum es mucho mas que sprints o tableros con post-it.

1. No subir los desarrollos a producción después de cada sprint.

Quizás el error más frecuente y también el más importante. Asume que tu cliente no puede saber lo que quiere y que tendrás que modificar el trabajo realizado. Cuanto antes descubras lo que en realidad necesita, más productivo será el proyecto.

Además, como la inversión económica de un sprint es pequeña y tu cliente utiliza las nuevas funcionalidades en tres semanas, su retorno de inversión -ROI- es mucho más rápido. Música celestial para cualquier CFO.

En las metodologías tradicionales los desarrollos se entregan al final del proyecto. Esto no solo retrasa el ROI. Comienzas las modificaciones cuando ya no queda presupuesto.

La única forma de comprobar que has acertado es poner el software en manos de sus usuarios finales.

2. Obligar a que se finalicen todos los trabajos planificados para el sprint.

El segundo error clásico. Si te has equivocado en el sprint planning y no es viable finalizar los trabajos, ¿cuáles son las posibles opciones?

a) Puedes pedir al equipo que haga un sobreesfuerzo y trabaje más horas.

b) Puedes rebajar la calidad y no hacer las pruebas de regresión.

c)  Puedes rebajar el alcance y entregar menos desarrollos.

Por inercia cultural, la mayor parte de los proyectos comienzan por la opción a) y terminan por añadir la opción b). Scrum establece que la respuesta mas apropiada es la c).

Buena parte de los incrementos de productividad asociados a Scrum proceden de eliminar la presión de trabajo de los consultores.

3. No tener un Product Owner integrado en el equipo.

El Product Owner es una figura esencial en Scrum, y es otra de las vías del incremento de productividad.

Los programadores trabajan sin una especificación detallada, así que constantemente tienen dudas sobre la funcionalidad a desarrollar. Es necesario que alguien procedente del cliente les explique las Historias de Usuario.

El Product Owner es también el guardián del ROI. No sabe programar, pero entiende el valor que aporta cada Historia al negocio. Si prioriza adecuadamente los desarrollos, conseguirá un mayor retorno de inversión en cada iteración.

Si el Product Owner no está con su squad, los programadores no interpretan bien las Historias, las modificaciones son más frecuentes y el valor para el negocio de cada sprint es menor.

¿Hay más errores típicos?

Aunque estos sean los tres errores más frecuentes al implantar Scrum, hay otros muchos que puedes cometer. Sin ánimo de ser exhaustivos:

Hacer una especificación pesada.

En Scrum se pasa de una idea de alto nivel al desarrollo que hacen los programadores. ¿Para que emplear meses en una especificación detallada si damos por sentado que el cliente no puede saber lo que quiere?

Solicitar que el cliente valide la especificación.

Aunque el cliente firme la especificación, sigue sin ser lo que necesita. Y lo sabe. Tu equipo puede estar valiosas semanas esperando a que el cliente dé su consentimiento. ¿No es mejor emplearlas en desarrollar un prototipo?

Mantener las jerarquías dentro de los equipos.

Ni el Jefe de Proyecto se transforma en Product Owner ni el Líder Técnico en Scrum Master. La figura del Líder Técnico desaparece. Los programadores colaboran desde un plano de igualdad y ninguno impone su criterio a los demás.

El Jefe de Proyecto también se difumina porque ya no es necesario negociar alcance y plazo de cada desarrollo.

No automatizar las pruebas a la vez que se hacen los desarrollos.

Si no automatizas las pruebas, ¿cómo piensas hacer DevOps? No podrás hacer pruebas de regresión y con cada sprint tus desarrollos tendrán menor calidad.

Tener a los equipos separados geográficamente.

No es solo que no puedan hacer el daily. Recuerda que los equipos están creando la especificación a la vez que hacen el desarrollo. Si están separados ¿cómo van a construir ese conocimiento?

No hacer retrospective.

Celebrar los éxitos del sprint y analizar los puntos de mejora aporta cohesión y les permite crecer como equipo. Potencia estos momentos de reflexión para que crezcan en la aplicación de la metodología.