Mixing Agile and Waterfall aproaches for projects

Many organizations have decided that there is no need to choose between Agile and Waterfall aproaches to manage projects. There is a sinthesys solution than can be tested in some environments.

The project management world has followed a triad evolution, as in Hegel’s dialectical method. Waterfall was the thesis, Agile the antithesis … and now there are approaches that try to be a kind of synthesis of both models. A logical evolution.

 

Mixed approaches

How can agile and waterfall be combined?

There are differents approaches to achieve the convergence of both mindsets:

 

Benefits of a mixed system

What are the benefits of these kind of approaches?

Probably there will be people used to work in ‘pure agile’ or ‘pure waterfall’ environments who will say that these approaches are just a perversion of the core values of their project management systems.

Nevertheless I think there might be situations where these options may be valuable:

  • Organizations who are transitioning from waterfall to agile and vice versa and need to remain in an intermediate step for some time instead of moving directly from one environment to the other one.
  • Organizations where the top management is used to deal with waterfall project managers and whose development teams have found that they achieve a better performance being agile.
  • Complex and big projects where there is part of software development and part of hardware or infrastructure deployment.

 

What is your opinion? Have you tried any hybrid approach to project management? What were the results?

Do you know any other hybrid approach to project management? I would like to know more about it, please add comment with your explanation.

 

 

Mixing Agile and Waterfall aproaches for projects

5 ejemplos de contratos ágiles

Como comentaba en mi último post del año pasado, uno de los motivos del posible fracaso de la utilización de Scrum en las organizaciones es el no trabajar con ‘contratos ágiles’.

Este tipo de contratos busca principalmente dotar de flexibilidad a las relaciones contractuales entre proveedor y cliente, de forma que este aspecto de la relación se alinee con la dinámica de la agilidad en la gestión de los proyectos.

Modalidades de contratos ágiles

Hay muchas modalidades de contratos que incorporan esa flexibilidad en la relación cliente-proveedor. El objetivo principal es repartir el riesgo de forma razonable entre ambas partes. La forma de hacerlo, en pocas palabras, es fijar coste y plazos de entrega y permitir flexibilidad/variabilidad en el alcance. El cliente va sabiendo conforme avanza el proyecto qué es lo que va a querer como resultado de su proyecto y el contrato debe permitir moldear el alcance conforme el proyecto avanza beneficiando a ambas partes y priorizando la entrega de valor para el cliente por encima del cumplimiento de un plan. Voy a enumerar y explicar brévemente algunos tipos de contrato ágiles  que conozco:

  • Money for nothing, change for free; el cliente puede cancelar el proyecto en cualquier momento pagando al proveedor un porcentaje del alcance cancelado. Cualquier funcionalidad puede cambiarse por otra de igual peso.
  • Time and materials iterativo e incremental; entregas funcionales al final de cada sprint. Posibilidad de terminar el contrato en cualquier momento (con o sin coste).
  • Precio por función; incentiva la entrega de software funcional cuanto antes. Los cambios son bienvenidos si se pagan.
  • Puntos y velocidad; calcula puntos y velocidad. Calcula el coste del proyecto en base a horas. Reduce el precio de horas y pon el resto en precio de puntos.
  • Compromiso agile; target time para MoSCoW. Mínimo y máximo agresivos. Por encima del máximo el proveedor pierde, por debajo del mínimo el proveedor gana. En el medio comparten costes y beneficios al 50%.

Recomiendo la revisión de esta presentación de Proyectalis y esta otra de Peter Stevens donde se analizan en profundidad las características, riesgos y beneficios de estas formas de contrato y algunas más.

¿Y todo esto por qué?

Pues, como decía al principio, para evitar movernos en el triangulo de hierro que acostumbra a perjudicar al proveedor y entrar en una dinámica de ganar-ganar en la que ambas partes salgan beneficiadas.

¿Utilizáis contratos ágiles en vuestras organizaciones? ¿qué tipos de contratos empleáis? ¿cuáles son los resultados? ¿estáis satisfechos?

5 ejemplos de contratos ágiles

Scrum no es para todos

Hace algún tiempo que me pregunto si Agile y Scrum en particular son una moda o si están aquí para quedarse. En mi trabajo tengo contacto con gente de muchas empresas que desarrollan software; desde clientes a proveedores o candidatos a los que entrevisto en procesos de selección. La gran mayoría me explican que en sus respectivas empresas usan Scrum pero todos ellos puntualizan en seguida que no son talibanes de Scrum. Utilizan aquello que les es útil. No sé si eso es Scrum o si en muchos casos se pervierte el sistema y se pierden los beneficios.

Scrum es fácil de entender a nivel teórico pero más complejo de aplicar en la práctica. Y es que Agile no es para todos. No se trata simplemente de una forma de hacer las cosas por parte del equipo de desarrollo. Se precisa de un cambio organizacional importante y de equipos experimentados y técnicamente muy capaces.

Hay muchas cosas que pueden hacer que una implementación de Scrum no funcione. En mi empresa hemos estado probando Scrum durante unos 6 meses y estamos llegando a la conclusión de que no es la forma ideal de trabajo para nosotros por diversos motivos:

– Trabajamos con contratos de precio fijo y alcance definido.
– Nuestros clientes, en general, no están interesados en comprometerse como Product Owners.
– Nuestros equipos, con frecuencia, no tienen la madurez suficiente y no se autogestionan.
– Los equipos de proyecto no son estables y sus integrantes trabajan en varios proyectos simultáneamente.

Y podría seguir con más razones.

Eso sí, en nuestras pruebas hemos descubierto cosas positivas. Los valores ‘lean’ y los tableros Kanban nos resultan muy útiles. Detectar y eliminar desperdicios (waste) además de ver todo el proceso en su conjunto nos está resultando provechoso.

Y es que, como en muchas otras disciplinas de conocimiento, la dirección de proyectos está en constante evolución. Es importante mantener una actitud abierta a los cambios, a la posibilidad de cometer errores y aprender de ellos y a la mejora constante (un valor de ‘lean’).
Estoy seguro de que en breve (si no han aparecido ya) surgirán metodologías de síntesis entre lo ágil y lo predictivo, como ya anunció hace años Juan Palacio. Y deberemos seguir experimentando y aprendiendo de forma constante y con actitud al tiempo crítica y abierta.

¿Cuál es tu opinión? ¿Qué experiencia tienes con Scrum o con otras formas de trabajo ágiles?

Scrum no es para todos