project mangement

Mixing Agile and Waterfall aproaches for projects

jmartinmateo, , Leave a comment

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

7 tips to work with virtual teams

jmartinmateo, , , , Leave a comment

Let’s say it. Executing projects with virtual teams has many advantages but, in spite of the many tools that are currently available to improve the communication between team members when they are not co-located, working with virtual teams has an added level of difficulty. Is it possible to take advantage of the benefits without die trying?

I have been managing some virtual teams in the last year and also following the way other project managers in our PMO were doing it. With these experiences and some documentation from experts that I have read recently I have gathered 7 recommendations to have chances of success when you have to manage a virtual team.

7 tips

  1. Be available and keep frequent formal and informal conversations with the team.
  2. Provide the appropiate channels and encourage your team to share their feelings and chat informally whenever they can. It should be a kind of water cooler, using separate chat channels, for instance.
  3. This has not been my case but if there are cultural differences between your team members it is crucial to promote cultural training for all members. For instance, Mediterranean workers are used to take more time for lunch than their northern team mates. It is important that the team understands and respects it whenever it is possible.
  4. Use video calls preferably over chat and email. And, if possible, it is good to have a regular structured video call with the whole team.
  5. Schedule a periodical in-person meeting from time to time. It is better if you can do it early on the beginning of the project.
  6. Provide a rhythm to the team. Stablish regular meetings (same days and time each week) and use best practices of meeting governance.
  7. Introduce the practice of sending a status email at the end of the day to recap the status of on-going tasks and to inform the team members on updates from the customer or other stakeholders.

The key is to treat your far team members the same as your team members who work in your immediate vincinity. Respect them, listem to them, feel their needs and stay in personal and emotional communication constantly.

 

7 tips to work with virtual teams

Funciones de una PMO en una organización ágil

jmartinmateo, , Leave a comment

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

The importance of the lessons learnt

jmartinmateo, 2 Comments

During this month (july 2012) I am going to finish a software development project that I have been leading as a project manager since its beginning in february. It has been hard, physically and mentally, and with very challenging deadlines.

Also in these weeks I am reading an interesting book from Peter Taylor, “The lazy project manager”. I have taken notes of two important ideas from the book that I can apply in this final phase of my project:

The shape of the projects.

Projects are thick in the beginning, thinner in the middle and thick again in the end.

It means that we must dedicate a lot of time and effort to bring the project inside the road at its initial phase (planning) in order to be able to “rest” a little bit during its execution and  monitoring phases. Finally we have to notice the importance of the closing phase and dedicate the necessary time and effort to finish our projects properly.

This final effort must be shared with the rest of the team, the sponsor, the client and also the other stakeholders. A part from obtaining acceptance of all the deliverables and closing contracts a very important activity in this phase is to register the lessons learnt during the project.

This is something that many times is forgotten or understimated.

What we know we know, what we know we don’t know  and what we don’t know we don’t know.

At the end of the book Peter Taylor quotes Mr. Donald Rumsfeld (12 February, 2002, US Dept. of Defense news briefing): ‘As we know, there are known knows. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know‘.

I have enjoyed specially this part of the book.

When we work on the registry of the lessons learnt during the chapter we must consider:

  1. What we didn’t know at the beginning of the project and we have learnt during its development. That is to know what we know.
  2. To know what we don’t know. The gaps in our experience of the project that we can fill up by asking our team.
  3. The unknown unknowns. This must be unveiled through a project retrospective where all the stakeholders should participate. It is a healthy habbit to plan for this in the final phase of the project.
Would he repeat it ?
Horse stumbles after the jump, would he repeat it ?

And why do we have to dedicate so many time and effort to all these lessons learnt if our project is almost closed and the deliverables have already been accepted?

In order to avoid that the sentece that says that ‘the man is the only animal capable to trip twice over the same stone‘ continues being true in the future. At least I think we should try it. Don’t you?

The importance of the lessons learnt