Author: jmartinmateo

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

A different kind of PMO. Lean-Kanban PMO.

jmartinmateoLeave a comment

When you talk about a PMO to a group of developers or designers or even project managers there are many prejudices about this kind of entity and in many cases a negative perception of its work.

This biased opinions have their foundations in the way PMOs tend to be used by organizations. As David Joyce explains in this presentation at the LKCE12, they focus on:

  • Governance: control. Monitoring and reporting.
  • Compliance: execution. Processes compliance prevail on delivering value to the client.

Another mindset of traditional PMOs is to maximize utilization of the resources: “The more we start, the more we finish”.  This mindset has 2 problems:

  • Increases the WIP (Work In Progress) and causes unnecessary stress to the team.
  • Increases the time to finish, as the TOC (Theory of Constraints) explains in this presentation from Teoce (in Spanish language). Starting many projects leads us to multitasking. And multitasking isn’t usually well managed. We should move from one task in a project, to another one in another project only if the first one is finished. We should jump between tasks only when it is possible to generate flow. Our project portfolio should be managed as a pull process in order to avoid overloading it.

Another kind of PMO is possible

Instead, the PMO mindset should be “The more we finish, the more we finish” as Markus Hammarberg explains in this post. “Stop starting, start finishing”.

Kanban can be a very interesting tool to improve a PMO, as it allows visual management of projects and the portfolio. This allows to keep informed the senior management limiting the overhead caused by traditional reports and meetings.

But there are other benefits that support this different approach for the PMO:

  • Risk management can be performed making work constantly visible and keeping the team together to be able to take quick decisions.
  • Break down big projects into small pieces that can be frequently delivered and allowing the teams to adapt to the changing needs of the business.
  • Producing and mantaining a dashboard of leading strategic metrics (value delivered, overall speed, quality and cost of delivery, lead times,…)

Portfolio and pipeline management deserve a special chapter and lean can be very useful for this purpose. Lean aims to focus in allocating the resources on highest priority projects to make them finish earlier and avoid starting new projects until resources are available.

What is your experience?

I think lean principles, TOC and kanban can be good project management tools in a PMO. They are a powerful way to:

  • increase value delivered
  • reduce lead times
  • improve management reporting through visual boards

and also Kanban can be introduced incrementally, step by step, without the need to implement drastic changes in the organization. What do you think?

A different kind of PMO. Lean-Kanban PMO.

5 ejemplos de contratos ágiles

jmartinmateo, , , , Leave a comment

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

jmartinmateo, , , 1 Comment

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

3 formas de control de costes que deberías conocer

jmartinmateoLeave a comment

La rentabilidad de los proyectos es fundamental para la supervivencia del negocio. Un elemento clave en este sentido es el control de los costes.
En la fase de venta el equipo que luego deberá desarrollar el proyecto debería intervenir ya en las estimaciones, sin embargo en esa fase en muchas ocasiones se carece de una información completa y también del tiempo necesario para desmenuzar el proyecto en tareas suficientemente pequeñas como para ser estimadas con facilidad antes de presentarle la propuesta al cliente.
Por otra parte, después, aunque en muchos casos se trabaje con prácticas ágiles los contratos no suelen serlo. En un contrato FP (Fixed Price) el proveedor asume el riesgo en relación a los costes. ¿Cómo podemos mitigar ese riesgo de la mejor manera posible?

Identificación y análisis de riesgos

Idealmente, el equipo que luego llevará a cabo el proyecto debe realizar las estimaciones pero el project mánager debe supervisar estas estimaciones y detectar posibles riesgos; ya sean debidos a la incertidumbre sobre posibles tareas que se van a hacer por primera vez en ese proyecto, a la inexperiencia de parte del equipo, a la falta de definición por parte del cliente (que a menudo empieza a saber lo que quiere conforme va viendo resultados), etc

Actualización del presupuesto en base a riesgos detectados

No es profesional hacer ‘padding’. Por el contrario, podemos hacer 3 cosas en el presupuesto en base a los riesgos:
1. Actualizar las partidas concretas en las que hemos detectado riesgos, para cubrir los costes de las actividades previstas para mitigarlos o eliminarlos.
2. Incluir una partida (contingecy reserves) para afrontar que se materialicen aquellos riesgos detectados pero que no hayamos podido ver cómo eliminar por completo en el análisis de riesgos realizado.
3. Incluir una partida final (management reserves) para cubrir posibles riesgos no detectados. Si todo va bien, no tendremos que hacer uso de esta partida y de esta forma no inflamos artificialmente partidas del presupuesto ‘por si acaso’.

Control de costes durante el proyecto

Una buena opción es usar la medición del valor ganado (Earned Value Measurement, EVM). Esta metodología permite medir la situación de un proyecto en relación a su alcance, su calendario y sus costes (que son el motivo inicial de este post).
Los resultados del EVM permiten detectar desviaciones, hacer previsiones y solicitar cambios con datos en la mano que los soporten.

¿Cómo controlas los costes en tus proyectos? ¿Has utilizado EVM?
¿Eres capaz de prever cómo acabará tu proyecto? ¿Dispones de datos suficientes para soportar tus previsiones o para fundamentar los cambios necesarios durante la vida de un proyecto?

3 formas de control de costes que deberías conocer

Do you control your projects or do they control you?

jmartinmateo, Leave a comment

“A tree as great as a man’s embrace springs from a small shoot;
A terrace nine stories high begins with a pile of earth;
A journey of a thousand miles starts under one’s feet.”

Lao-Tse – Tao Te Ching

It is a lot easier to face a problem when it is in an early stage than when it has grown too much. So, this shows us one of the most important attributes of a good project manager: proactivity.
A project manager’s work should not focus on dealing with problems, it should focus on preventing them. We must manage the risks of a project, but how can we do it more efficiently? It is not possible to preview everything.

In my opinion, we must be prepared and have:

A system

A system, for instance, like the one explained in the PMBoK. It is necessary plan to manage risks, to identify them not only in the beginning of a project but during the project too, analyze the identified risks and develop responses. And repeat this process periodically during the life of the project.

Team support

The whole team must participate in the process of identifying risks and planning responses. They are able to help us identify possible problems that the project manager couldn’t imagine.

Communication

That takes me to the third point: good and fluent communication with the team, the client (and/or the Product Owner).
The Project Manager also must contribute to create an environment of confidence amongst the project team so that ideas, problems, risks, solutions, … flow in the team.
Everybody should feel that they can share their thoughts freely and all the important information should flow easily so that the ones who must use it to make decisions have it when they need it.

Tools

And that brings me to the final point: the tools.
We need tools to support communication, plans, assessments, … I have included them in the end because I think they are necessary but they don’t make the system. They make our life easier but they are useless if we do not have a plan and processes to systematically manage risks and we have not created an environment with the team where they feel free and motivated to communicate.

What do you think is more important? What kind of processes do you use in your projects to manage risks? Does the team always help proactively?
Please, share your comments.

Do you control your projects or do they control you?

La falacia de los costes hundidos

jmartinmateoLeave a comment

Los directores de proyectos con cierta experiencia tarde o temprano se habrán encontrado con un proyecto complejo o que, simplemente, se ha complicado y está resultando mucho más caro de lo previsto. Es posible que incluso antes de haber logrado desarrollar la mitad del alcance el proyecto ya haya superado el presupuesto para el total del mismo. ¿Qué hacer entonces? ¿Debemos continuar o es mejor para ahora? Al fin y al cabo la inversión realizada ya es importante…

La falacia de los costes hundidos

Para tomar la decisión sobre si continuar con el proyecto o cerrarlo tal y como está no debemos tener en cuenta lo ya gastado en el proyecto. Eso ya está gastado y no se va a recuperar, por mucho que emocionalmente nos duela.
Se trata de costes hundidos (sunked costs) .

Lo ya gastado en el proyecto es irrecuperable, sea cual sea nuestra decisión. Lo que debemos valorar es la inversión que sería necesaria en este momento para acabar el proyecto y decidir si vale la pena realizarla y si es la mejor inversión que podemos hacer (coste de oportunidad).

En base a esas premisas podemos tomar una decisión racional.

Las emociones juegan en contra

¿Por qué nos cuesta tanto entonces dejar de lado proyectos que van mal?
Uno de los motivos es que no nos gusta perder. Tenemos aversión a las pérdidas. Reconocer que hemos tirado a la basura tiempo, dinero y recursos es duro.

Otro motivo es nuestro compromiso con nuestro trabajo. Una vez que empezamos algo intentamos acabarlo a toda costa. Dejarlo a medias es visto por algunos de nosotros como un fracaso y como un incumplimiento de nuestras obligaciones con el cliente y con nuestra organización.

Tener que sentarnos ante un cliente con el que hemos negociado la realización de un proyecto por un precio fijo que hemos estimado mal es duro. Continuar con el proyecto en esas condiciones no es bueno ni para proveedor ni para cliente. Es necesario asumir la responsabilidad y afrontar la situación para evitar males mayores.

¿Qué opinas? ¿Tienes experiencia en este tipo de situaciones? ¿Cómo las has abordado?

La falacia de los costes hundidos

4 Reasons to prototype in mobile app projects

jmartinmateo, , Leave a comment

There are many situations when creating a prototype of the final product of a project is not possible, because of the costs, the timing or just because of the nature of the product. But if you have the chance I recommend you to do it.

Prototyping in software projects

Currently I manage projects whose goal is the creation of mobile apps for different kinds of clients. The product of our projects is a software and software by its nature allows prototyping and progressive development.

There are different kinds of prototype solutions for mobile apps. Frequently we use Marvel and Flinto. They both allow to create very high fidelity prototypes that can be tested in the intended devices as if they were the real app.

Why is this so interesting inside the project of creation of an app?

1. It is very frequent that the client (and/or the product owner) doesn’t know exactly how the final product should look like, exactly what kind of functionalities should it include and how should they be presented to the app user.
The prototype allows the client to rethink the product if necessary as the result of its interaction with the prototype.

2. It is a lot cheaper and faster to introduce changes in a prototype of this kind than in the final app (product).

3. Design is fundamental in a mobile app. This allows designers to go always at least 1 sprint ahead of developers during the project. If you can create a first project just for prototyping it will be even better.

4. As the designs are realistic, all the assets created for the prototype and approved by the client can be used by the developers during the following phases of the project without any additional work from the designers.

What is your opinion?

What do you think? Do you prototype in your projects? What kind of tools do you use? Do you know any more reasons in favor of prototyping? And against?
I would like to know your comments.

4 Reasons to prototype in mobile app projects

¿Gestionas tu tiempo o te lo gestionan?

jmartinmateo, Leave a comment

¿Consideras que te falta tiempo en tu jornada laboral para hacer todo el trabajo? ¿Aprovechas bien tu jornada? ¿Regresas a casa con frecuencia con la sensación de no hacer progresado lo suficiente en tus tareas?

En este ‘post’ vamos a analizar la importancia de gestionar bien nuestro tiempo (dentro y fuera de la jornada laboral), vamos a identificar los principales enemigos de la productividad y propondremos algunas soluciones.

Si no somos capaces de gestionar bien nuestro tiempo van a ser los otros, nuestro entorno, quienes nos van a hacer ir siguiendo sus dictados en base a prioridades que probablemente no serán las nuestras.

La importancia de gestionar bien el tiempo en una empresa de servicios

Cuando te dedicas a proporcionar servicios, por ejemplo haciendo aplicaciones móviles como en Slashmobility, el buen o mal uso del tiempo afecta directamente a la cuenta de resultados de la compañía. Nuestros clientes compran horas de nuestro trabajo para que durante las mismas apliquemos en sus Apps todo nuestro conocimiento. Si somos ineficientes vamos a emplear más horas de las necesarias en ese trabajo… y no vamos a poder facturarlas.

Por otra parte, después del jefe, el hecho de acabar quemado es uno de los motivos de abandono más habituales en las empresas. Una de las causas de esta situación es la sensación de falta de control sobre nuestro trabajo, de falta de progreso en nuestras tareas y proyectos,…

Los enemigos de nuestra productividad

Son básicamente 2: las distracciones/interrupciones y la multitarea.

Como ejemplos de interrupciones podríamos incluir el correo electrónico, el chat, el móvil o internet. ¿Tengo que estar continuamente mirando el correo y contestando inmediatamente? ¿O puedo gestionar mis correos 2, 3 ó 4 veces al día y ya está? ¿Se espera que estemos todo el tiempo pendientes de whatsapp? ¿Debemos tener el chat abierto durante toda la jornada laboral? ¿Controlamos nuestro estado en el chat y lo vamos actualizando en base a nuestra disponibilidad? ¿Tenemos el navegador abierto todo el tiempo? ¿Es necesario? ¿Nos limitamos a aquellas pestañas que nos ayudan a realizar la tarea concreta que tenemos entre manos en ese momento?

¿Cómo combatirlos?

 Aquí van algunas propuestas:

  • Escritorio minimalista

No guardamos documentos y/o accesos directos a aplicaciones que puedan distraernos de nuestro trabajo. En su lugar podemos usar programas como ‘Spotlight’ en Mac o ‘Launchy’  en Windows para arrancar aquellas aplicaciones con las que queremos trabajar simplemente escribiendo las primeras letras de su nombre.

  • Navegador minimalista

Sólo mantenemos abiertas aquellas pestañas que nos ayudan a ejecutar la tarea que tenemos entre manos en ese momento. El resto fuera.

  • Uso eficaz de las comunicaciones

El chat es una forma síncrona de comunicación; usémoslo de esa forma pero

  • Informemos a nuestros compañeros de cuando estamos disponibles para chatear y cuando no (porque, por ejemplo, estamos concentrados en realizar una tarea)
  • Si quiero chatear con un compañero, le puedo preguntar si está disponible (tal vez no lo está pero ha olvidado actualizar su estado en el chat) en lugar de abordarlo directamente.
  • Email

Revisemos el correo electrónico y el whatsapp varias veces al día. Cada uno debe decidir la frecuencia que le resulta más conveniente. Pero el resto del tiempo cerramos el cliente de correo y silenciamos whatsapp para evitar distracciones.

Una herramienta de mejora de la productividad: el método GTD

GTD (Getting Things Done) es un método, creado por David Allen para ayudarnos a sistematizar la gestión de las tareas a realizar en nuestro día a día.

No voy a explicar en esta entrada en qué consiste GTD. Podéis encontrar una primera descripción en la Wikipedia, pero os recomiendo que reviséis también los blogs de algunos expertos en el tema como David Torné, Berto Pena o Francisco Sáez.

Comentario final

Tener el control sobre nuestro entorno es complejo. Nuestros compañeros de trabajo, proveedores y clientes pueden seguir dinámicas muy diferentes a las nuestras y afectar negativamente a nuestra productividad.

Sin embargo, en este post hemos visto que hay algunas herramientas que nos pueden ayudar a mejorar la forma como interactuamos con nuestro entorno y mejorar nuestra productividad, al tiempo que estar más satisfechos de nosotros mismos.

No hay recetas mágicas, cada uno debe probar diferentes técnicas y herramientas y encontrar la combinación que le ayude mejor en su día a día.

¿Qué herramientas o métodos utilizáis vosotros? ¿Habéis probado GTD? ¿Cuáles son vuestras impresiones?

Este post se publicó en primer lugar en el blog de Slashmobility

¿Gestionas tu tiempo o te lo gestionan?