¿Por qué SCRUM es más eficiente que las metodologías tradicionales Waterfall (II)?

¿Por qué SCRUM es más eficiente que las metodologías tradicionales Waterfall (II)?

En la primera parte de este artículo explicamos cómo algunas empresas tecnológicas implantan SCRUM sin conocer sus fundamentos. Adoptan los ritos de la metodología como el daily o los sprints pero no obtienen las mejoras de productividad prometidas.

En esta segunda parte vamos a explicar de dónde proceden los [celebrados | cacareados | esquivos] beneficios de SCRUM y cuál es el cambio de paradigma que proponen las metodologías ágiles.

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.

El cambio de paradigma que propone Scrum es que proveedor y cliente asumen que lo construido es lo mejor que se puede hacer con el plazo y el presupuesto disponible.

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, sabiendo 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 equipos 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 un incremento de la jornada de trabajo produce un retraso de los desarrollos y, sin embargo, reducir la jornada a cinco horas diarias puede lograr incrementos de productividad del 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 se finalicen y superen los test, en muchas ocasiones al acabar el sprint habrá desarrollos a medias o que no superen las pruebas. Estos trabajos vuelven al team backlog y se abordarán (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.

Así que como cliente debes elegir entre

– Sacrificar el Alcance y entender que ciertas funcionalidades nunca se desarrollarán.

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

– Sacrificar la Calidad, y aceptar que te entregarán un sistema apenas probado, con constantes errores en producción y difícil de operar.

En las metodologías tradicionales de desarrollo en cascada, se fijan por contrato 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é se degrada al elegir SCRUM?

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

– El Plazo -y por tanto el presupuesto- se establece en el contrato. El Alcance se deja abierto.

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

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

¿Puedo usar las Cuatro Leyes sin necesidad de implementar metodologías ágiles?

Como hemos visto, las ventajas de Scrum se derivan de que cumple las Cuatro Leyes, y no del puntual cumplimiento de sus rituales. Por eso es frecuente que las organizaciones cometan errores en su implementación. Aquí aparece la figura del Scrum Master, que ayuda a realizar con éxito la transición.

También es posible el caso opuesto, puedes usar las Cuatro Leyes aplicando el sentido común, y mejorar los resultados sin necesidad de implementar una metodología de nombre exótico.

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’.

Los proyectos funcionaron muy bien hasta que la organización apostó por metodologías formales como CMM, más preocupadas por la especificación que por las personas.

Emplea con sabiduría las Cuatro Leyes y cualquier metodología será la adecuada.


¿Por qué SCRUM es más eficiente que las metodologías tradicionales Waterfall (I)?

¿Por qué SCRUM es más eficiente que las  metodologías tradicionales Waterfall (I)?

SCRUM no es una religión. SCRUM es solo una forma de implementar las Cuatro Leyes Básicas de la gestión de proyectos. 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 seguramente no encontrarás la tierra prometida.

Si impones SCRUM a tu organización 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 oscuros de las cintas magnéticas, los profetas Brooks y DeMarco nos advirtieron que nos enfrentamos a problemas extremadamente complejos en los que podemos trabajar 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

El ritual SCRUM que nos inspiraron es como sigue:

La Sagrada Firma

El  Sumo Account Manager descubre una necesidad del cliente y junto con su acólito el Product Owner, preparan una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realizan 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 productos indeterminados. Es inútil explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, aunque 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, 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 Manager 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 los escuadrones de desarrollo, con un 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 de una parte de la aplicación. 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 van a intentar implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. El squad conoce su velocidad de ejecución.

Cada mañana, antes de la salida del sol, el squad 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 finalizado y apto para entregar al cliente.

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 entrega al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.

El Sprint Retrospective

La ceremonia final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de mejorar su capacidad y ser más productivos en los próximos sprints.

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 vistosos y diferentes de los que desconocemos su significado y son tentadores de imitar.

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

En el siguiente post de esta serie, explicaremos cómo usando las Cuatro Leyes Básicas de la gestión de proyectos, puedes conseguir la productividad de las metodologías ágiles sin necesidad de rituales.


La tragedia del analista programador

El rol de Analista/Programador es la primera promoción dentro de la carrera tecnológica, y es una trampa que debes conocer.

Con un poco de paciencia, en dos o tres años serás el programador más veterano dentro de un grupo de cinco o seis consultores, lo que te convierte de facto en su Líder Técnico. Aquí aparece el primer dilema de los profesionales del mundo IT.

¿Dedico mi tiempo a realizar mi [importante] trabajo técnico o a formar a los recién incorporados?

Existen tres soluciones posibles:

1. Dedicas la mayor parte de tu tiempo a realizar tu [crítico] trabajo técnico y sólo ratos sueltos a dar soporte a los nuevos. Éstos aprenden lentamente ya que no puedes encargarles tareas complejas. Es el caso más habitual, representado en la gráfica por la línea roja. Conseguirás una alta rotación entre los recién llegados y mucha presión para que el equipo mejore sus resultados.

2. Haces tu [complejo] trabajo técnico y además dedicas mucho tiempo a formar a los nuevos. El volumen de horas necesario para realizar ambas tareas te llevará a presentar la baja voluntaria o la baja por depresión.

3. Dedicas la mayor parte de tu tiempo a formar a los nuevos consultores hasta que son capaces de trabajar con autonomía. Es el caso menos habitual, representado en la gráfica por la línea verde. El equipo tendrá resultados pobres durante los primeros meses pero a largo plazo construirás un Equipo de Alto Rendimiento. Si consigues soportar la presión, claro.

La gráfica presenta los resultados obtenidos por un equipo siguiendo las diferentes estrategias.

Como puedes ver, las tres estrategias ofrecen resultados que están por debajo de las expectativas del cliente, lo que se traduce en presión; retrasos, lista de tareas pendientes que tiende a infinito y tensas reuniones con el cliente.

En siguientes post estudiaremos estrategias que consiguen resultados que superan las expectativas del cliente. Y también veremos los nuevos problemas que eso genera.


Las cuatro leyes de la gestión de proyectos tecnológicos

Las cuatro leyes de la gestión de proyectos tecnológicos

Tan solo cuatro leyes gobiernan la gestión de los proyectos tecnológicos:

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.

La primera ley asume que no disponemos de una herramienta para transmitir las instrucciones técnicas. La comunicación se hace mediante sucesivas iteraciones soportadas en relaciones personales. Corolario: Especifica menos y relaciónate más.

La segunda ley nos indica cómo fomentar las relaciones personales; los equipos de diseño, desarrollo, pruebas, integración y delivery están en una única oficina y cada consultor trabaja para un único proyecto. Las software labs y las organizaciones matriciales son ineficientes.

La tercera ley anticipa que si incrementas la presión de trabajo, obtienes menos producto. El desarrollo tecnológico es más inspiración que transpiración. Deja que el equipo encuentre su ritmo y gestiona las expectativas del cliente.

La cuarta ley nos propone cómo gestionar las expectativas del cliente. Dado que las especificaciones son infinitas, uno de los tres parámetros debe degradarse y lo habitual es fijar Alcance y Plazo, degradando la Calidad. La propuesta de SCRUM es fijar Plazo y Calidad mientras el Alcance se determina con el cliente en sucesivas iteraciones. La propuesta de TIME & MATERIAL es fijar Alcance y Calidad, sin plazo cerrado y facturando por el tiempo dedicado.

Son pocas y son fáciles, y sin embargo buena parte de las organizaciones, como consecuencia de la herencia cultural de la ingeniería industrial, trabajan contra ellas preparando extensos documentos funcionales, deslocalizando parte de los equipos, trasladando la presión del cliente a los desarrolladores y fijando en los contratos alcance y plazo de entrega.

Quizás la magia no está en conocer las cuatro reglas, están ahí a disposición de cualquier gestor que quiera aplicarlas. Lo difícil es comprender la psicología que hay detrás de cada una de ellas, de forma que puedas adaptarlas a tu organización. Las referencias básicas son ‘Introducción a la PNL’ de Seymour,The mythical man-month’ de Brooks, ‘Peopleware’ de DeMarco y ‘Drive’ de Pink.

Por eso cuando hay retrasos en los proyectos, se forman silos dentro de las organizaciones o los resultados se evaporan sin razón aparente, algunas empresas contratan un análisis estratégico y otras invitan a su coordinador de Novanotio a tomar un café y le preguntan la forma más sencilla de aplicar las cuatro reglas a su caso particular.

Si quieres ayudar al desarrollo del sector, puedes compartir experiencias sobre proyectos en los que se trabajó a favor o en contra de las cuatro leyes. También puedes proponer nuevas leyes y abrir un debate sobre por qué son necesarias y por qué tienen un carácter universal.