Introducing agile into a huge organization: where do we start?

Last month I attended an internal training session at work which aimed to introduce agile in our services unit. After 9 months in the company I have started to understand how it works and how difficult is to introduce changes in a huge organization. These companies are quite stable, like a merchant vessel, and time and effort is required to change their course of direction. So I was scheptical about what the guys providing the training would be able to suggest.

Start with the basics

And our coaches started with the basics. There are different layers of elements involved in Agile:

  • Mindset
  • Values
  • Principles
  • Practices
  • Tools & processes

The first in the list are the ones less visible and more powerful. On the contrary, the last one is the more visible but less powerful.

It is very typical to fall into the trap of the tools and practices but not having changed first the essence of your ways of thinking. This leads to false agility. So our trainers were focused in the mindset and values of agile.

Mindset and values

In order to create a change some steps are usually recognized as needed. Sharing and explaining the agile manifesto and its values is the starting point of our journey. Our team has now awareness of what can be done and is able to recognize opportunities to apply these principles.

It is true that the support of our management is needed. It si true that we have many processes and tools that are far from agile. It is true that when projects arrive to us many decisions have already been made. However every individual can do something to be more agile within its zone of influence.

Potential next steps

Now, according to P. Kotter, it would be time to create the sense of urgency and a guiding team that is able to communicate the vision and the benefits of the change. That is the phase to ‘prepare the change’ that should be followed by the change it self and that hopefully would end with a new culture (agile) in the organization. It will require time but we are already on the way.

There is an exciting journey ahead of us. What is your experience? Have you lived this kind of changes in big organizations? Were they successful? What were the keys of success and the main pain points?

Introducing agile into a huge organization: where do we start?

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

Funciones de una PMO en una organización ágil

Tradicionalmente se ha considerado una PMO (Project Management Office – Oficina de gestión de proyectos) como una entidad encargada de la centralización y coordinación de proyectos de la organización: coordinando recursos compartidos entre proyectos; identificando metodologías, buenas prácticas y estándares; formando y mentorizando a los Project Managers o coordinando la comunicación entre proyectos. Sin embargo, en una organización ágil este paradigma debe ser modificado en parte. En el “agilismo” hay una serie de principios que se tratan de respetar: personas sobre procesos, software que funciona sobre documentación, colaboración con el cliente sobre el contrato y respuesta al cambio sobre planificación.

Así pues, en una organización ágil, la PMO no es una entidad controladora y perseguidora de estándares. Más bien se debe convertir en una entidad facilitadora para los diferentes equipos de trabajo y que promueva el aprendizaje continuo.

Su rol se debe reorientar hacia otras funciones que aporten más valor y sean coherentes con la filosofía ágil:

  • Mentorizar y proporcionar servicios de coaching a los equipos de trabajo y a los scrum masters.
  • Desafiar continuamente a los equipos de trabajo para que apliquen la mejora continua en sus prácticas ágiles.
  • Ayudar con los informes de seguimiento: determinando qué métricas utilizar y ayudando a los equipos a concentrarse en la entrega continua de valor. Todo lo que no proporciona valor es desperdicio.
  • Gestionar el WIP (Work In Progress): Todas las organizaciones tienen un ratio de ‘trabajo en curso’ con el que trabajan de forma óptima. La PMO ágil debe vigilar que su organización se encuentre lo más cercana posible al valor óptimo. Se puede incorporar un nuevo proyecto a la cartera de proyectos en curso sólo cuando se ha finalizado un proyecto de esfuerzo similar que haya liberado recursos de la organización. En cuanto a las herramientas, podemos apoyarnos en aquellas que nos ayuden a planificar y hacer un seguimiento de los proyectos (herramientas visuales para definir y seguir los backlogs, controlar el WIP, etc.).
  • Reducir el desperdicio (muda en términos ‘lean’): ayudando a los equipos de trabajo a identificar y eliminar todas aquellas actividades y artefactos que no aportan valor.
  • Coordinar equipos: especialmente cuando tenemos miembros que trabajan de forma parcial para varios proyectos de forma simultánea.
  • Fomentar la comunicación entre equipos: favoreciendo que las buenas ideas y buenas prácticas identificadas por un equipo sean conocidas y aprovechadas por otros. En este ámbito, es útil el uso de herramientas para facilitar el rápido intercambio de información entre los miembros del equipo (que cada vez de forma más habitual trabajan distribuidos). Dicha información debe ser clasificable para su rápida recuperación posterior. Necesitamos herramientas de colaboración tanto síncronas (chats, teléfono, Skype, etc.), como asíncronas (correo electrónico).
  • Proteger a los equipos de proyecto: defendiendo y explicando sus necesidades a otros departamentos (personal, CEO, etc.) cuando deben tomarse decisiones que afecten a la ubicación de los miembros de un equipo en la oficina, la adquisición o eliminación de herramientas de trabajo, etc.

Y todo esto sin olvidar que estamos hablando de trabajos intensivos en conocimiento, en los que el principal activo son las personas, los profesionales que llevan a cabo el desarrollo. Por ello, es fundamental dedicar el tiempo necesario a hablar con el equipo y con los project managers; actuando en cada momento según lo requiera la situación: a veces sólo preguntando y ayudando a que el propio equipo encuentre las soluciones, a veces siendo más expeditivo y marcando el camino a seguir y en otras ocasiones sólo escuchando.

En resumen; en una organización que busca ser ágil el rol de la PMO debe ser, como siempre, apoyar la estrategia corporativa. Esto no cambia. Sin embargo, si la estrategia pasa por la agilidad, la PMO debe pasar a ser una entidad más orientada a aconsejar y orientar que a controlar. En lugar de focalizarse en garantizar el cumplimiento de los calendarios y presupuestos de proyectos, debe poner más énfasis en que los proyectos proporcionen el máximo valor posible al negocio o a los clientes finales (sin que esto signifique que calendarios y presupuestos dejen de tener que cumplirse).

En cualquier caso, no todo es blanco o negro; predictivo o ágil. Cada organización debe buscar su camino entre las metodologías predictivas de gestión de proyectos y los modelos más ágiles y muchas veces la opción más adecuada estará en el medio. La PMO deberá ser coherente con la opción escogida por su organización y apoyar al máximo la implementación de su estrategia.

Este post fue publicado primero en el blog de Slashmobility.

Funciones de una PMO en una organización ágil