CONFERENCIA AGILE SPAIN 2018 (CAS 2018) PRIMERA JORNADA

Los pasados días 13 y 14 de diciembre, se celebró en Alicante la Conferencia Agile Spain 2018 en su novena edición.  Es un punto de encuentro internacional para los profesionales interesados en las metodologías ágiles.

Los objetivos del CAS 2018 buscan promocionar y divulgar el uso de las metodologías ágiles en organizaciones españolas, así como tratar de crear sinergias mediante la compartición de conocimientos y experiencias , además de servir como plataforma para la realización de proyectos de cooperación entre todos.

Nuestra empresa fue uno de los patrocinadores del evento. Y dado que la Dirección está comprometida con la transformación cultural enfocada a la mejora y a la eficiencia, un buen grupo de compañeros pudimos disfrutar de la experiencia de asistir a este interesante evento.

A nivel general, destacar que las salas donde se desarrollaron las ponencias eran muy desiguales en cuanto a aforo disponible, unas salas eran muy pequeñas y otras muy grandes. Respecto a los contenidos de las ponencias, la organización de CAS 2018 se comprometió a proporcionar los vídeos grabados de todas ellas a través del canal de Agile Spain de Youtube a partir de enero. A los talleres solo se podía asistir mediante inscripción y sorteo. Por otra parte, la comida que se sirvió fue abundante y variada.

Por cuestiones de agenda, no pudimos asistir a  la primera ponencia, a cargo de Lyssa Adkins llamada “We are the Leaders we have been Waiting For”. No obstante, a la espera del vídeo oficial, desde aquí se puede acceder a una grabación de su misma charla en otro evento, fechada en marzo de este año, en formato vídeo:

Las ponencias a las que asistí fueron las siguientes.

PRIMERA JORNADA:

1 ING: HAZ EL CAMBIO Y LUEGO HAZ QUE FUNCIONE –  IVÁN CORPS

Iván comento, para dar contexto, que ING en un grupo holandés que tiene 160 años y cuenta con 34 millones de clientes (10% en España) . Están en España desde 1982. Son 52.000 profesionales en todo el mundo  (2% en España).

Para ING transformar significa:

  1. Ejecutar eficientemente la estrategia (ejecutar las prioridades, tener foco y ser adaptativos)
  2. Aumentar el compromiso de los empleados (pues al final son los que cuidan a los clientes)
  3. Mejorar la manera de colaborar entre todo el equipo.

Iván Corps lleva dos años y medio ejerciendo de Agile Coach en ING. Con dos misiones específicas:

  1. Acompañar a una “tribu”. En concreto a la del “Daily Banking” (medios de pago, cuentas, servicios digitales)
  2. Formar parte del equipo de transformación

Hubo varias etapas  en la transformación. Un primera etapa fue desde el nacimiento ING hasta enero 2018, para preparar la transformación. Se dedicaron 40 días a esta labor.

Hay que tener en cuenta de que desde 2012 al 2017 ING ya tenía una cultura de mejora continua, (Scrum , WIP con Kanbam, PMO Agil…), y que la cantidad de servicios digitales entregados ya era muy grande.

Se lanzaron dos iniciativas: una con dos proyectos célula (con un equipo multi disciplinar)  y otra referida a compartir ideas  con los compañeros de ING Holanda.

El equipo holandés  comentó que en la empresa habían delimitado cuatro áreas fundamentales: Delivery, Ventas, Servicios (operaciones) y Soporte. Ellos ya habían generado un modelo de referencia con su aprendizaje, que le pareció muy interesante y aprovechable cara modificar la unidad de Delivery. Contenía a Marketing, Negocio, IT, Comunicaciones e Innovación (sobre 700 profesionales)

Al CEO esto le “sonó” familiar, pues cuando él estuvo en la empresa en una primera etapa y se convirtió en un enorme apoyo. Es más, quería el cambio para ya mismo.

Se pusieron a trabajar en el CÓMO con un equipo de transformación, con cuatro características que debería de cumplir: relevante, influyente, balanceado y empoderado.

Y empezaron a trabajar  en la transformación con un backlog dividido en cuatro grandes bloques:

  1. Un nuevo diseño organizacional, basado en el modelo de Spotify y basado en buscar cadenas de valor independientes. Formado por nueve tribus y cinco COES. (Center of Expertise)
  2. Un nuevo modelo de RRHH. Nuevas funciones y nuevos roles
  3. Actualización del entorno de trabajo. Las Tribus deberían trabajar juntas. Fuera despachos y dentro “Salas Obeya“,  basado en experiencias de Toyota.
  4. Nueva manera de trabajar. Explicando los valores, los principios, los frameworks  y las formas  de trabajar (en tres oleadas). Compartiendo toda la información con las personas impactadas por el cambio. Durante la Agile Week se explico el porqué del cambio, el cómo del cambio, roles, tribus, squads, chapters, y se porporcionó formación. Lo mas interesante fue el ejercicio del “vaciado de bolsillos” (en qué estaba trabajando cada uno y estas tareas se repartían en el backlog a un responsable, squad o tribu).

Ya llevan ocho meses en Delivery, donde han recolectado unas enseñanzas básicas.

Mejoras:

  1. Los niveles directivos estaban muy comprometidos
  2. Soporte local y del grupo. Se consultaba  a otros grupos. sobre los problemas y sus soluciones. Escuchar las preocupaciones de las personas, pues las personas van a diferentes velocidades. Les funcionó muy bien seguir el modelo de gestión del cambio ADKAR (Awareness, Desire, Knowledge, Ability, Reinforce).
  3. Equipos multi disciplinares. Es ideal para producir conversaciones inspiradoras.
  4. Mecanismos de alineamiento, por ejemplo, las Salas Obeya ya mencionadas construidas para uso de todas las tribus.
  5. Convivir con los objetivos de la organización. Se obtuvo un máximo de clientes de  “cuenta nómina” con un mínimo de incidencias. Es el “Learn by Doing” , es decir, aprender haciendo.

Aprendizajes:

  1. Llevó tiempo explicar que esto no era solo una reorganización, sino que era una reorganización y también un cambio en la forma de trabajar.
  2. Se necesita mucho más aprendizaje que el inicialmente planificado. Hubieran sido necesarios más talleres.
  3. Se sufre cuando se rompen “silos”. Hay que volver  a aprender  a trabajar (Modelo de Tuckman)
  4. Equipo de agile coaches. Todos los coaches tienen ideas sobre cómo hacer las cosas, como todos saben qué hacer es agotador. Ya han cambiado tres veces de forma de trabajar.
  5. Asumir la pre asignación de roles a personas. Todos los empleados tienen un nuevo rol. Pero hay personas que, a pesar de todo, deciden abandonar la empresa.

Como resumen, Iván destacó que un proyecto de este tipo hay que ser valientes, ser humildes y tener claras las batallas en las que merece la pena pelear (o no). Disfrutar del viaje, recomendó Iván, pase lo que pase.

Los archivos de las presentaciones aportadas por el ponente se pueden consultar aquí:     Presentación 1    Presentación 2

 

2 LIDERAZGO PARTICIPATIVO, UNA NUEVA MANERA DE DESARROLLAR ORGANIZACIONES CAÓRDICAS – ISRAEL ALCAZAR

Israel comentó que vivimos en un mundo VUCA,  acrónimo utilizado para describir o reflejar  la Volatilidad, incertidumbre (Uncentainly), Complejidad y Ambigüedad de condiciones y situaciones. Los móviles Nokia o las cámaras Kodak son un buen ejemplo de esto.

El mundo actual plantea nuevos retos y nuevas estructuras organizacionales. Se debería buscar la anti-fragilidad, es decir, aprovechar el cambio para hacerse más poderoso. O el enfoque de Federic Laloux en su libro “Reinventar las Organizaciones“. Lo ideal sería llegar a ser una organización modelo TEAL (que son las empresas que fomentan la auto organización, el auto propósito y la plenitud de las personas).

Todos los modelos hablan de la importancia de la adaptación y de tener un propósito. Y que haya un equilibrio entre el orden y el caos. Se necesitan organizaciones de este tipo. La naturaleza cumple con este esquema. La naturaleza se adapta continuamente, tiene un propósito, es auto organizada, y tiene un orden y una estructura. Como todo sistema tiende al caos, es necesario aportarle energía para evitar el caos absoluto. El propio cuerpo humano tiende al orden. Se necesitan unas estructuras mínimas para evitar el caos.

Es lo que se llaman Organizaciones Caórdicas, que están entre un exceso de caos y el exceso de orden. Este término lo acuñó Dee Hock, en su libro “The Chaordic Organization: Out of Control and Into Order”. Fue fundador de VISA.

Usando metáforas podemos contemplar a las organizaciones como sistemas vivos:

  • Solo acepta sus propias soluciones. En las organizaciones, si no implicamos a las personas impactadas en la solución, no la harán suya y no desearán participar.
  • Sólo prestan atención a lo que tiene sentido para ellos en el aquí y en el ahora. Es decir, hay que prestar atención a la tensión existente pero no a todas las tensiones, pues sería agotador.
  • Participa en el desarrollo de sus vecinos. Un departamento que se aísla se hace cada vez más pequeño y perjudica al resto.
  • Está en continuo cambio, pero no tiene un sistema de gestión del cambio. El cambio es y debe ser algo natural
  • Busca diversidad, de género, de edades, de culturas. Los equipos con más diversidad son los equipos más exitosos y los que aportan más valor, aunque no sean fáciles de gestionar.
  • Buscan las mejores soluciones que funcionen, no las soluciones perfectas. Es buscar la solución que sirva
  • No pueden ser controlados en su totalidad. Se pueden monitorizar, pero no controlar completamente. Solo se puede gestionar el trabajo, pero no a las personas.
  • Todos sus miembros obtienen mejores resultados juntos que por separado. Es usar la inteligencia colectiva frente a la individualidad.

Pero en las organizaciones actuales  la mayor parte son estructuras piramidales, que fomentan la estabilidad y la eficiencia. Y  de forma paralela, se crean estructuras informales para solucionar problemas, que tienden al caos, pues nadie puede obtener sus objetivos sin la ayuda de los demás. Se deberían de fomentar las estructuras informales, pero añadiendo  un poco de orden y orientadas a la generación de valor.

Y el ponente se preguntó qué tipo de liderazgo debería de existir en este tipo de organizaciones. Serian líderes que fomenten el liderazgo de otros y la auto organización de las personas. Y esto se fomenta poniendo algunos límites,  pero dejando que el equipo busque sus propias soluciones. Se debe buscar una situación equitativa, que no igualitaria. Se necesitan solo establecer unos principios guía, las reglas básicas de juego. Por ejemplo, si se presupone la transparencia, que cada persona decida cómo actuar respetando ese principio-guía.

Los líderes deben promover la diversidad en los equipos. Aunque sea complicada. Y ver el conflicto como una oportunidad de desarrollo. Y se debe promover el  liderazgo participativo, que potencie las nuevas estructuras organizaciones, que fomente el liderazgo de otros y que fomente la auto organización y la auto gestión.

Las mejores herramientas de ingeniería social para buscar soluciones son sencillas: la conversación y el feedback.  Parecen sencillas, pero son complejas de llevar a la práctica.

Herramientas más concretas son:  Art of Hosting, la Estructura en Círculo, Open Space, herramientas sociales que fomentan conversaciones productivas. Liberating Structures , Visual Thinking. O  A3 Thinking.

Conclusiones:

  • La complejidad solo puede ser gestionada con complejidad.
  • Es útil usar la metáfora de las organizaciones como seres vivos y no como máquinas.
  • Se debería fomentar el Liderazgo Participativo.
  • No hay solución para todo. Las soluciones deben ser adaptadas a los problemas actuales de la empresa. Las soluciones de Toyota solo eran válidas para Toyota y adaptada a ese momento concreto. Son difícilmente exportables a otras situaciones.

Acceso al SlideShare de la Presentación:

 

3 RIGHTS AND RESPONSABILITIES OF A DELIVERY TEAM – SANDRO MANCUSO

Sandro lleva trabajando en agilidad desde los 17 años de edad. En un único proyecto en concreto fue feliz porque la agilidad funcionaba. El producto no funcionó pero en  11 meses lo supieron. Y la empresa no necesitó invertir más, es de decir, ahorraron dinero.

Es decir, solo un proyecto de 11 meses en un lapso de tiempo de 14 años fue considerado como ideal al efectos de metodología ágil. En el resto hubo problemas. A partir de esta situación, el ponente se preguntó si sería posible que el equipo de Delivery  llegara a un acuerdo satisfactorio con Sponsors y como sería eso. Implicaría establecer responsabilidades y derechos para el equipo de Delivery. La regla de oro para los equipos de Delivery sería:

  • Reducir el lapso de tiempo entre las ideas y el software funcionando
  • Habilitar a negocio a que trabajen estratégicamente (probando cosas)
  • Concentrarse en las entregas útiles a negocio (no solo en cumplir con  los tickets de Jira)
  • Entrega continua

Cual sería la composición ideal del equipo de Delivery. Según Scrum, debería de estar formado por: un Product Owner (PO), un Scrum Master (SM) y un Delivery Team.

Pero vieron que el PO rara vez es parte del equipo. En teoría, el PO debería de tener estas funciones:

  • Ser parte del equipo. Pero no  lo suele ser.
  • Ser responsable de maximizar el valor del producto
  • Debería ser el único que controla el Product Backlog del producto
  • Debe ser una única persona, no un comité. El es el único que debe marcar la prioridad de los items en el backlog
  • Se deben respetar las decisiones del PO por parte de la organización. Las decisiones del PO deben ser visibles. Nadie debe forzar al equipo a trabajar en otro tipo de requerimientos

Cómo se debería gestionar el backlog:

  • Debe expresar claramente los items
  • Ordenados los items para obtener mejor los objetivos
  • Optimizar el valor del trabajo del equipo de desarrollo
  • Asegurarse de que el backlog del producto es visible, transparente y claro
  • Asegurarse de que el equipo de desarrollo entiende el los items del backlog, al nivel adecuado
  • El PO debe hacer todo esto mencionado, o dejar que el equipo lo haga. Sin embargo, el propietario del producto sigue siendo responsable

Por otra parte, el rol del Scrum Master (SM) implica:

  • Ser responsable de apoyar al equipo, como se define en la Guía de Scrum (19 páginas). Ayudan a entender la teoría scrum y sus reglas, valores y prácticas.
  • Ser un líder sirviente del equipo. Ayudar a los que están fuera del equipo a entender la utilidad de sus interacciones con el equipo y ayudar a cambiar estas interacciones para maximizar el valor creado por el equipo de scrum.
  • El ponente afirmó que el papel del SM es un papel demasiado especializado. El equipo podría hacer esto solo.

En el modelo de organización de Spotify, que es uno de los más avanzados que existen, existen las squads, equipos multifuncionales, cada una con una misión diferente y mucha autonomía trabajando con una estrategia global. El problema de los equipos autónomos es que es difícil mantener a los equipos alineados en un único objetivo. Y ellos tienen a un PO que forma parte del equipo como en scrum. Todos son responsables. Y no tienen un SC dentro del equipo, pues no hace falta. Esta es la principal diferencia entre el modelo Spotify y el modelo Scrum. Y ojo, llamar a los equipos “squads” y a los SM llamarlos “squad masters”, no convierte a tu empresa en un modelo como el de Spotify. Es un error.

En un modelo ágil,  en un lado están los stakeholders, de otro el equipo de desarrollo, en otro los PO y en otro los Coach Ágiles/Scrum masters. Pero es que los SM no son parte del equipo, lo único que hacen es decir al equipo lo que tienen que hacer, y esto es un problema, pues va en contra de la autonomía de los equipos.

Los problemas en la composición del equipo que el ponente manifestó fueron los siguientes:

  • El SM es inútil y puede ser sustituido por el equipo fácilmente
  • El PO frecuentemente no es parte del equipo. Perteneces a una organización vertical.
  • PO se comporta como un Project Manager autoritario, pues ve al equipo como una entidad separada que trabaja para el
  • El equipo de desarrollo responde no solo ante el PO sino también ante el CTO, los arquitectos y a veces, ante los coaches agiles
  • El equipo de desarrollo es responsable, pero pocas veces tiene suficiente autonomía para gestionar sus problemas.

Una mejor aproximación es hacer a los equipos autónomos y que el PO realmente forme parte de ellos. Y que no se resuma el trabajo del equipo en contar cuantos tickets de Jira se han cerrado sino en hacer caso a problemas de negocio, por ejemplo, evaluar cuanto se ha vendido o si se ha incrementado el número de clientes. Esos son  las necesidades de negocio que deben ser cubiertas. Y que el PO ayude al equipo a entender los problemas que sufre negocio, pues es el más adecuado para esta labor.

Un buen acuerdo  sería “establecer un contrato de trabajo entre el equipo y los stakeholders en le cual los derechos y responsabilidades estén acordados”.

DERECHOS DEL EQUIPO DE DESARROLLO:

  • A definir la estructura del equipo.
  • Acceso a la estrategia de negocio y  a los stakeholders
  • Definir el proceso de trabajo
  • De no ser responsables de las cosas que no controlan
  • A entender los objetivos de negocio
  • A tener autonomía para crear soluciones
  • A controlar el tiempo o el alcance
  • A obtener apoyo cuando se enfrentan a factores externos
  • Al intercambio de feedback regular
  • A trabajar con colegas respetuosos
  • A experimentar y a aprender

RESPONSABILIDADES DEL EQUIPO DE DESARROLLO:

  • A proporcionar un servicio profesional
  • Actuar en el mejor interés de negocio
  • A maximizar el valor proporcionado
  • A entregar valor de forma contínua
  • Habilitar  a los stakeholder para que puedan planificar
  • Alinear las estrategias de negocio y de las tecnología
  • Buscar la excelencia
  • Proporcionar continuidad
  • Asegurarse de que el equipo está siempre desarrollando
  • Entregar objetivos del equipo, no objetivos de individuales
  • Crear un entorno de desarrollo respetuoso

Es obligatorio alinear la intersección entre negocio (diseño de producto) y tecnología (diseño de software). Si este área es pequeña hay un problema. Estas dos áreas no pueden ignorarse.

Por último, el equipo debe pasar de ser un equipo de desarrollo a ser un equipo de resolución de problemas

Conclusiones:

  • Se tienen derechos, en tanto en cuanto las responsabilidades estén cumplidas
  • Los derechos y responsabilidades deben estar equilibrados
  • Pueden servir como un compromiso de trabajo entre el equipo de negocio y de entrega.
  • Negocio y tecnología son un solo equipo
  • Debe ser un equipo solucionador de problemas, en lugar de equipo de desarrollo
  • Proceso de diseño de producto y de software entrelazados

Me ha parecido una ponencia muy recomendable. Es valiente contar realidades, aunque estas sean incomodas y  vayan en contra de los estándardes.

 

4 NO RETROSPECTIVES – TONI TASSANI

Aunque esta ponencia estaba planificada que fuera desarrollada en castellano, el ponente preguntó a la audiencia si había algún impedimento para explicarla en inglés. Y así lo hizo.

El principal objetivo de la sesión es permitir a los asistentes que lanzara una mirada crítica a la agilidad, poniendo foco en las Retrospectivas y pasarlas por el tamiz de la experiencia y el sentido común.

Toni trabaja como “Catalyst” en la empresa Ocado.  Su labor se resume en hacer que el trabajo sea mas efectivo.

Llegó a sus oídos que las sesiones de Retrospectiva no estaban funcionando correctamente. Dado que esto impide la mejora continua se puso a estudiar qué es lo que estaba pasando.

Estudió la “Ladder of inference”. Esta llamada Escalera de la Inferencia fue desarrollada por el estadounidense Chris Argyris, un ex profesor de la Escuela de Negocios de Harvard. Muestra cómo los modelos mentales se forman inconscientemente.  Las personas observan la realidad, seleccionan los hechos de los eventos, interpretan los eventos, hacen suposiciones, sacan conclusiones, buscan en sus creencias y entonces la persona procede a actuar. Para evitar este error se debe asumir que estamos mediatizados por las experiencias previas  y nuestras creencias (que no cuestionamos).

Las limitaciones se pueden convertir en oportunidades de mejora.  Una primera limitación es la obligación de hacer sesiones retrospectivas obligatorias. En los Principios del manifiesto ágil podemos leer: “A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta y ajusta su comportamiento en consecuencia”. Muchos agilistas traducen esta declaración directamente a “Retrospectivas”. Pero no son obligatorias. No se quiere caer en los “Scrum buts” y por eso se hacen.

Otra limitación es la inercia.

Problemas detectados en las retrospectivas, que pueden convertirse en riesgos:

  1. Evitar conversar sobre los problemas específicos. Es decir, limitarse a poner una nota sobre el problema en la retrospectiva, que no puede valer entonces para nada.  No se debe esperar y se debe tratar el problema en el  momento en el que se produce a través de una conversación.
  2. El llamado Teatro de los Post-It. Es un escenario de un equipo enel cual no hay mejora sino mucho  movimiento de notas post it.
  3. Optimizaciones locales. Es el problema de estar centrados solo en el equipo (team centrics). Y no pensar en la estrategía o en lo global, sino solo en el equipo.
  4. Solucionar problemas individuales, uno detrás de otro. este enfoque de los problemas evita encontrar una causa raiz y obtener una única solución.
  5. Cambiar por cambiar, pero no producen una mejora.
  6. Malos experimentos, que parecen buenos pero no van a ser valiosos por la forma de enfocarlos y realizarlos.

Todo esto va de obtener “mejora continua”. Y de evitar restricciones. Para obtener esa mejora continua puede ser útil conocer estas herramientas:

  • Improvement Board
  • Popcorn Flow
  • Improvement Kata
  • Service Delivery Review

Y siempre manteniendo un espíritu de investigación sobre lo que puede ser interesante para obtener mejora continua.

 

5 IMPLANTACIÓN  DE AGILE LPM EN LA FIRMA DE ABOGADOS CUATRECASAS – JOAN OLIVERAS

Fue una lástima que esta ponencia se desarrollara en la sala más pequeña, la sexta, porque había público a reventar,  y muchos tuvieron que asistir a la misma de pie.

Se presentó el caso real de la implantación del LPM (Legal Project Management) en la firma de abogados Cuatrecasas, en su versión agile.

Joan dividió su ponencia en tres partes.

Problema:

La crisis ha hecho que el crecimiento de la facturación año tras año de los despachos de abogados se diera por finalizada. A los despachos  no les preocupaba la gestión porque se facturaba mucho dinero. Ahora se deben hacer cosas que no se les había planteado, como es mejorar la gestión de los casos y trabajar con márgenes más ajustados.

Solución:

Joan comentó que, en un primer momento, se tuvo en cuenta la gestión predictiva de los casos, pero rápidamente se dieron cuenta de que los abogados no veían útil este enfoque basado en proyecto predictivo y pasaron al enfoque agile del LPM. Los abogados son muy pragmáticos y si algo no funciona no lo van a utilizar.

Los abogados no están acostumbrados a gestionar, son muy buenos en lo que hacen pero necesitan obtener la capa de gestión, y lo saben. Por ello, comenzaron a gestionar los casos de los equipos estables utilizando kanban en un proceso definido que incluía litigios. La transparencia es un problema porque los abogados trabajan en un entorno de “Up or Out” (Arriba o fuera) que está alejada de la colaboración. Joan explicó la forma en la que se delega, diciendo: “haz esto” pero sin explicar el entorno. Y unos abogados están sobrecargados y otros hacen pocas tareas.

Se introdujo el Visual Management para obtener una visión global de todos los asuntos abiertos y realizar su seguimiento. Les ayuda  a obtener una visión global del asunto  y ofrece transparencia y colaboración. Cuando los abogados vieron en un panel todo lo que gestionaban (algunos de ellos llevan hasta 50 casos a la vez) les pareció interesante porque les proporcionaba una visión global de sus tareas (toda la información sobre tareas y deadlines estaba solo en su cabeza).

Y también agregaron una reunión semanal para explicar la situación de los casos delante del tablero físico.  Posteriormente se añadieron las reuniones diarias (dailys). En esa media hora de la daily se ganó colaboración  y transparencia, que antes no existía.

Se buscó al abogado más involucrado para que hiciera de kanban leader. Porque el cambio debe ser interiorizado por ellos mismos.

Ahora trabajan en dos niveles:

  • Kanban de los socios. Con todos los casos
  • Dashboard de los abogados. Con todas las tareas

Ambos tableros están unidos. Fácilmente se puede ver la dedicación de cada abogado en todo momento. Han dado el paso de usar tableros físicos a tableros digitales (www.leankit.com).

Por último se montaron unos KPIs para hacer seguimiento, pero no son todavía operativos.

Cambio provocado:

El objetivo de entregar valor está cumplido y esto justifica el proyecto. Los abogados lo ven interesante y lo usan. Buscan que sean los propios abogados hagan de “obispo negro”, es decir, que los propios abogados vendan el proyecto y otros compañeros pidan este cambio.

Progresivamente, se van introduciendo nuevas funciones y herramientas ágiles (CoS, WIP, etc…)

Este proyecto se lanzó en el año 2016 y sigue vigente (abarca ya a unos 70 abogados y 9 equipos).

Me quedé con ganas de más información. Esta ponencia me pareció una experiencia de lo más interesante. Y de lo más pragmática, los profesionales solo usan lo que consideran útil.

Como nota curiosa, anotad que Joan, siendo una persona muy cercana y accesible,  no acepta contactar  en Linkedin de quien no conozca personalmente.

 

6 “¿AGILE FUERA DE SOFTWARE? VMF FRAMEWORK + ENDESA COMO CASO DE ÉXITO”- XAVIER QUESADA, JOSÉ A. RANEA

Xavier y José Antonio presentaron el caso de la implantación de un marco de trabajo basado en VMF (Visual Management Framework) para extender Scrum  a tareas complejas en entornos productivos que no son del mundo de software, tales como las gestión de tareas recurrentes, tareas delegadas, tareas con deadlines, etc..

Comentaron que lo primero en un proyecto ágil es trabajar el liderazgo, cultura y valores. Pero la mentalidad ágil no es suficiente. también se debe reincorporar un rediseño organizacional . Y finalmente se necesita trabajar con las practicas del día a día, como son scrum y kanban. Y esto fuera de software puede quedar un poco corto. De esto hablan en esta ponencia.

Y para ilustrar el caso, pusieron el caso de “encargar” un bebé, como si fuera un proyecto ágil. Con tablero y todo.

El desarrollo y testeo se enfocó en equipos de logística y transporte, con un día a día compuesto de proyectos, tareas recurrentes, tareas con deadlines y tareas no planificadas. Para suplir carencias  de scrum y kanban en la gestión de un equipo se agregó el concepto de “calendario” (a tres niveles: macro, semanal y diario).

Otras diferencias con la agilidad en software son:

  • El Product Owner y de Scrum Master pueden ser la misma persona (algo prohibido en Scrum de software). No existe tanto trabajo del Product Owner con los stakeholders como en el entorno de software
  • Se pueden unir en una las sesiones de Retrospectiva más las sesiones de Sprint Review (R2).
  • Quizás la agilidad (como el flamenco) no es para todos los públicos, o al menos, hay que adaptarlos a la empresa y enfocarlo a la entrega de valor.
  • Había tareas derivadas de proyectos, tareas recurrentes y  tareas no recurrentes. Fundamental es que todos los equipos tengan claro el “Definition of Done” de las tareas, pero especialmente de las tareas recurrentes, pues es la única forma de mantener la calidad
  • Los equipos debe ser auto organizados. Y se debe meter auto reflexión en el equipo.
  • Fundamental es medir la capacidad del equipo, para no saturar al equipo con tareas que realmente no se van a hacer.

Como conclusión, un enfoque visual de este tipo proporciona grandes ventajas en materia de seguimiento del trabajo.

 

7 UNA VIDA DESCUBRIENDO AGILE – TOÑO DE LA TORRE

El ponente desea que conozcamos su trayectoria en el mundo de la agilidad, a modo de retrospectiva vital.

Toño descubrió el Manifiesto Ágil, complementado con  los valores del sprint de scrum (compromiso, coraje y foco) y con los de kanban, (transparencia y flujo).

En Madrid, en el año  2004 se incorporó a la empresa DIA y descubrió el agilismo. Su jefe allí, que se comportaba como un líder y no como un jefe  le recomendó un libro: “Pragmatic Programmer“.

En el año 2008 el paso a una consultora no fue una buena experiencia. Pero se trasladó al departamento de software libre, y de un jefe controlador pasó a a trabajar en un entorno Scrum, con responsabilidad y acceso libre al cliente. La CAS del año 2010 fue un festival donde conoció el mundo Agile y especialmente cuando pudo conocer a la comunidad, donde se compartía todo el conocimiento.

Un hito importante fue  la creación de la empresa Kaleidos y la ventaja de no estar en una empresa grande les permitió trabajar de forma ágil con sus clientes.

En el año 2012 oyó el termino Agile Coach y se quiso convertir en uno. Convocó la “Comunidad de Scrum Masters”, que era un espacio para compartir experiencias. Pero en Kaleidos no había Scrum Master  y no era efectivo en su transferencia de conocimiento. Esto producía frustración. La enseñanza fue que cuando un grupo de gente no quiere hacer algo, no lo va a hacer.

Y llegó la crisis del Agile Coach.  En el año 2013, durante la CAS de Bilbao anunció que dejaba de ser Agile Coach. Solo quería ser uno más en el equipo.

Durante el año 2014 vivió una doble vida, pues en la comunidad ágil estaba en lo más alto, pero en su empresa (Kaleidos) estaba en crisis.

En el año 2015 tuvo la gran crisis, pues nada le llenaba. Buscó coaching y encontró a Hana Kanja, que fue una ayuda. Y quiso dar un giro a la situación. Volvió de Madrid a Oviedo y ya en Asturias se sumó a la empresas Codesai. Esta empresa está basada en  la desestructuración de cualquier concepto de procesos y herramientas, pues para ellos lo más importante son las relaciones y la entrega de valor. Adicionalmente, aprendió el proceso de dar y recibir feedback y la forma en la que la confianza de los equipos puede destruirse si suceden cosas graves.

En el año 201 8 Codesai se convirtió  en una cooperativa de siete socios. Actualmente el ponente está en un proceso de investigación acerca de cómo realizar una entrega de valor constante a los clientes.

Aprendizaje:

  • Siempre hay que volver a revisar cómo gestionar personas. Ser líder y no jefe.
  • Se debe aprender siempre.
  • El mentoring es muy recomendable.
  • Se debe agradecer lo recibido. La comunidad ha dado mucho y hay que responder para que la rueda siga girando.

Gran aprendizaje:

  • La respuesta ante el cambio y hay que vivir sin miedo

Los fallos técnicos sufridos durante el evento hacen difícil valorar la charla (una lámpara falló y el proyector dejó de funcionar). Una verdadera lástima.

 

8 EMPRENDIMIENTO CORPORATIVO- NESTOR GUERRA

Nestor comenzó su charla con una cita de Drucker: “Una organización tiene solo dos funciones básicas: marketing e innovación. El resto son costes”.

Hay diferencia entre  riesgo y  la incertidumbre.  El riesgo se gestiona. No es lo mismo. La incertidumbre es lo desconocido. Los nuevos productos fracasan no por el riesgo sino por la incertidumbre. La innovación no es divertida, siempre es agresiva. Y se mueve en la incertidumbre.

Es un hecho que las compañías cada vez duran menos.  Los modelos de negocio de las empresas caducan y muchas eran excelentes en lo que hacían. Por ejemplo, el Banco Popular, que llegó a ser el cuarto banco mejor gestionado de Europa. Un indicador muy importante es que las compañías nuevas crecen más rápido. Y como nos enfocamos para resolver este paradigma. Pues innovando, claro, pero la pregunta es cómo hacerlo.

Y aquí surge el intra emprendimiento. Para entenderlo hay que entender el pasado y lo que fue mal. Un ejemplo fue caso de la quiebra de Iridium (fabricaron y lanzaron 77 satélites).  Que el producto funcione no significa que el negocio funcione.

En este punto de la charla, el ponente solicitó a todos los asistentes que completaran una encuesta en el móvil sobre lo que cada uno consideraba que fue el motivo del éxito de AIRBNB.

El intra emprendimiento es llevar adelante una actividad emprendedora en el interior de una organización existente con sus empleados y en actividades que no tienen nada que ver con su “core” de negocio. Pero hay dos dinámicas contradictorias que deben convivir en la empresa, una es la de tratar de innovar y la otra es la de ejecutar el plan de negocio, que es el que da de comer a la empresa. Las organizaciones ambidextras son las que saben hacer compatibles estas dos dinámicas.

Eric Ries, creador de Lean Startup, dijo que las compañías modelo son aquellas en los empleados pueden experimentar y que haya algún mecanismo en la empresa para que esa idea pueda llevarse al mercado.

Existen cuatro modelos de intra emprendimiento, en base al estilo de liderazgo y a los recursos asignados:

  • Oportunista (no existe una estrategia, los recursos se definen de manera informal y espontánea),
  • Facilitador (la empresa provee recursos a los intra emprendedores, siempre que consigan el apoyo de un directivo),
  • Productor (Existen mecanismos de apoyo integrales y formalizados para el conjunto  de los intra emprendedores),
  • Independiente (la empresa promueve activamente  el intra emprendimiento, pero es cada unidad de negocio la que asigna los recursos)

Estos modelos deben construir ecosistemas para que haya muchas ideas y que alguna de ellas germine. Y así se crea cultura.

Tres bloques dentro de la innovación:

  1. La estrategia de innovación:
    • Es importante la tesis de la innovación, hacia donde mirar a largo plazo
    • El portafolio de innovación. Cómo categorizar las ideas (por horizontes de innovación)
  2. Gestión de la innovación:
    • Framework de innovación
    • Contabilidad de la innovación, cómo medir el progreso de la innovación
  3. La puesta en práctica:
    1. Aceleradoras. Significa atraer talento de fuera
    2. Intra emprendedores, de dentro de la empresa

Nota importante. No se puede puede saber cuantos experimentos se deben hacer hasta llegar a iniciativas innovadoras. Matar proyectos es casi tan importante como hacerlos nacer.

Tres escenarios de las hipótesis:

  1. No es válida. Y se debe pivotar
  2. Que siga siendo incierta
  3. Que se valide. Y se debe avanzar a la siguiente fase.

Innovar es difícil por el mal uso que se hace de la palabra “experimento”. Por ejemplo, solo hacer una pagina web no es un experimento. No se debe frivolizar con la experimentación.  La hipótesis define el método de investigación (Francis Bacon dixit). Se puede utilizar Lean Startup y Agilidad en la innovación, pero también hay mucho ya inventado.

Y hay umbrales en los cuales más experimentos no ayudan a reducir la incertidumbre. Y hay que tomar decisiones.

Lecciones:

  1. Es una iniciativa de arriba a abajo. El CEO debe estar implicado
  2. Sin recursos no se puede hacer nada, se requieren tanto recursos económicos como humanos
  3. Es una apuesta a largo plazo
  4. Hay que crear cultura  de la experimentación
  5. Hay que formar a la gente, para que aprendan de otros
  6. Hay que llevarlo a toda la compañía, para  conocer lo que hacen los otros
  7. Existe un componente de suerte, pero hay que crear una cultura de sistematización de todo el proceso

PD. Por cierto, el éxito de www.airbnb.com se debió a que al público le gustaron las “fotos bonitas” de las casas.

Seguirá en la entrada: …CONFERENCIA AGILE SPAIN  (CAS 2018) SEGUNDA JORNADA

NOTA: Fotos de Ángel de la Iglesia (mucho mejores que las mías, dónde va a parar)

EXAMEN DE CERTIFICACIÓN PMI RISK MANAGEMENT PROFESIONAL (PMI-RMP)

OBJETIVO:

A petición de algunos colegas de profesión, comparto mi experiencia acerca del examen correspondiente a la de certificación PMI Risk Management Professional (PMI-RMP) realizado con fecha 03-09-2018.

Me voy a centrar en la preparación y en el examen propiamente dicho. Los requerimientos para poder presentarse al examen se pueden encontrar en la web de PMI, dentro del manual oficial de PMI (PMI-RMP Handbook). En ese documento se pueden encontrar los pre-requisitos de eligibilidad para poder optar a la certificación:

  1. Un título de 4 años (título universitario o equivalente):
    • 3.000 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 30 horas de educación en materia de gestión de riesgos
  2. Un diploma de educación secundaria:
    • 4.500 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 40 horas de educación en materia de gestión de riesgos

Por otra parte, el esquema del contenido del examen se puede encontrar aquí: …ESQUEMA EXAMEN PMI-RMP

 

IMPRESIONES TRAS SALIR DEL AULA DEL EXAMEN:

Me ha parecido un examen más fácil que el examen PMP, pues está más centrado y es más específico.

Las preguntas está mucho mejor redactadas que en los simuladores. Esto hace que algunas preguntas puedan responderse “por descarte”.

En mi caso en el examen no tuve tiempo para repasar las preguntas que se pueden “marcar” para revisión. El tiempo (tres horas y media) me pareció muy justo, pues el rendimiento es decreciente. Me costó más responder a las últimas 40 preguntas que a las 130 anteriores.

Ya no se puede realizar el “volcado de memoria” durante los 15 minutos que dura el tutorial del examen basado en ordenador. Personalmente creo que tampoco valía para mucho.

Si no se ha  estado nunca en un examen por ordenador auditado por Prometrics, puede desconcertar el nivel de exigencia del mismo. No se puede llevar al aula de examen ni agua ni snacks. Todo debe guardarse en la taquilla (monedas, llaves, cartera, pañuelos). Las gafas son sometidas a revisión y  se realiza un examen de detección de metales cada vez que se sale al baño y se vuelve a entrar en la sala de examen. No obstante, debido a la pandemia, ya es posible realizar el examen “on line” pero en modo “Proctorizado”.

 

SOBRE LAS PREGUNTAS:

Esto es lo que pude observar sobre las preguntas del examen

  • Varias preguntas (5 o 6) sobre el Análisis Montecarlo
  • Sobre 3 o 4 preguntas sobre EMV
  • Muchas preguntas situacionales, del tipo ¿Qué harías tú? o del tipo ¿Qué es lo siguiente que se debe hacer?
  • Ninguna pregunta sobre teorías motivacionales (Maslow, McGregor, Vroom, Herzberg…)
  • Bastantes cuestiones sobre gestión y manejo de Stakeholders
  • Bastantes preguntas sobre escoger la herramienta más adecuada para ciertas situaciones.
  • No obsesionarse con los ITTOS (entradas, herramientas, salidas de cada uno de los procesos de gestión de riesgos). No salen tantas preguntas que justifique tener que aprendérselos todos. Solo se deben memorizar los más importantes
  • No observé demasiadas preguntas con “distractores” (datos insertados sin relación con la pregunta).
  • Hay referencias a la agilidad en algunas preguntas, que sospecho que cada vez van a ser más.
  • Ninguna pregunta sobre:
    • Norma ISO 31000
    • Heurística
    • Tuckman
    • Estilos de liderazgo
  • Aplicación directa de fórmulas de Valor Ganado
  • Sobre 5 o 6 preguntas directas sobre respuestas al riesgo
  • Varias cuestiones sobre cuál sería el riesgo más alto, considerando Probabilidad e Impacto

MATERIAL DE ESTUDIO:

Libros recomendados:

  1. Libro Secretos para Dominar la Gestión de Riesgos en Proyectos de Liliana Buchtik:
    • Idioma español
    • Muy completo. Trata con detalle la parte de las herramientas de cada parte del proceso
    • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
  2. Libro Secretos para salvar el PMI-RMP (300 preguntas de examen) de Liliana Buchtik:
    • Idioma español.
    • Son 300 preguntas con sus correspondientes respuestas
    • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
    • Es un material complementario al libro de la misma autora “Secretos para dominar la gestión de proyectos”
  3. Libro PMI-RMP Exam Prep Study Guide, de Belinda Freemow:
    • Idioma inglés
    • Muy práctico y sencillo de entender
    • Al final de cada tema hay una serie de preguntas para responder
    • Cuenta con 150 preguntas de examen
  4. Apuntes y otro material del preparador Wolf Project:
    • Amplio resumen de los temas.
    • Ahorra mucho tiempo de estudio
  5. Libro Risk Management Tricks of the Trade for Project Managers + PMI-RMP Exam Prep Guide de Rita Mulchay:
    • Idioma inglés
    • Es obligatorio leerlo, pero a este libro ya se le nota mucho el paso de los años (fue editado en 2010)
    • Cuenta con un apartado final de 75 preguntas de examen
  6. PMBOK Versión 5, OJO, la versión actual ya es la 7:
    • Versión Español
    • Descarga gratuita digital siendo socio de PMI
    • Es interesante leerse los siguientes procesos:
      • Riesgos, Stakeholders, Comunicaciones y Adquisiciones
    • Se deben repasar los ITTOs (entradas, herramientas, salidas) de esos procesos
    • El examen se basó en el PMBOK 5, pero ya ha ido publicada la versión 6.
    • Ojo, que la versión 7  difiere de la versión 5 (se ha incorporado un nuevo proceso denominado “implementar la respuesta de los riesgos” y se ha creado una nueva respuesta al riesgo llamada “escalar”, tanto para amenazas como para oportunidades). Se debe averiguar qué versión estará vigente para cuando se planifique el examen.
  7. Libro Practice Standard for Project Risk Management, editado por PMI: Idioma inglés
    • Lectura obligatoria
  8. Libro Passing the Risk Management Professional (PMI-RMP) Certification Exam the First Time! De Daniel Yeomans:
    • Idioma inglés
    • Sencillo de entender
    • Al final de cada tema hay una serie de preguntas para responder
    • Cuenta con un apartado final de 150 preguntas de examen

Simuladores de examen:

  1. Es muy importante escoger bien los simuladores, pues existe una gran variedad en el mercado y no todos son adecuados para preparar el examen.
  2. Existen varios simuladores de preguntas recomendables sobre esta materia:
    • Simulador de Simplilearn. Es gratuito
    • Yo recomiendo seleccionar y comprar dos o tres paquetes de preguntas de la web de Udemi. De pago.
    • Es muy importante responder preguntas de varios simuladores, no solo de uno, pues así se logran entender más planteamientos de las posibles preguntas.

CALENDARIO Y PREPARACIÓN:

Considero que la preparación de este examen es difícilmente compatible con el desempeño laboral a tiempo completo. Yo he aprovechado la jornada continua del verano para prepararlo.

Recomiendo realizar el curso de preparación de 30 o 40 horas en un proveedor de confianza. Es tiempo de estudio ganado.

Tiempo de preparación. En un intervalo de un mes y medio o dos meses se puede preparar.

Un condicionante, dado que se incluyen preguntas del examen PMP, es que es muy importante refrescar los conocimientos adquiridos en esa certificación.

Es muy importante saber que este examen actualmente solamente se administra en inglés, por lo que:

  • Recomiendo estudiar en español al inicio de la preparación (pues se avanza muy rápido)
  • Pero me parece interesante pasar a estudiar en inglés pasada la mitad de la fase de preparación, pues es absolutamente necesario familiarizarse con los términos en inglés que se encontrarán en el examen final.

Como rutina de estudio, es recomendable repasar cada día uno o dos temas y completar el estudio respondiendo una serie de preguntas sobre lo estudiado. Los libros de Fremow, Mulcahy y de Yeomans mencionados permiten hacer eso.

Es muy útil días antes del examen real realizar dos exámenes completos de 170 preguntas y hacerlos a la misma hora que el examen que se ha programado en Prometrics (si se hace el examen por ordenador). Para poder presentarte con garantías al examen, es recomendable sacar al menos un 75 /80 % de aciertos.

 

 

El examen ya se ha adecuado tanto al PMBOK versión 6 como a la actualización del Standard for Risk Management. Se debe tener este punto en cuenta a la hora de planificar el examen de certificación.

¿Por qué certificarse en PMI-RMP?. Porque mejorarás tus habilidades en materia de gestión de proyectos, en concreto, mejorarás tus capacidades para gestionar riesgos y por tanto, para mejorar tu tasa de éxito de los proyectos que dirijas. Adicionalmente, tu empresa saldrá beneficiada de este conocimiento de gestión de los riesgos.

5 Reasons to Get Your PMI-RMP® Certification

Y por último, mucho ánimo. Es una materia muy interesante y es un examen más sencillo que el  PMP. El resultado merece el esfuerzo.

 

ACTUALIZACIONES:

TALLER Y CERTIFICACIÓN PMO-CP

TALLER PMO-CP  (CERTIFIED PRACTITIONER)

El pasado día 12 de junio asistí a un taller de metodología PMO-CP que, opcionalmente, permite acceder a la certificación oficial.

En el curso nos encontramos varios profesionales habituales de los eventos relacionados con proyectos que, como me pasó a mí, se sintieron interesados por lo que podía aportarles este curso.

Todos coincidimos en que la formación en materia de Oficina de Gestión de Proyectos (PMO) se da por supuesta a los profesionales que han superado el examen PMP de PMI, pero eso no es cierto. La información que proporciona el PMBOK sobre las PMO se limita a unas pocas páginas de contenido.

La metodología ha sido creada por la empresa PMO GLOBAL ALLIANCE, que cuenta con una comunidad de mas de 5.000 miembros en varios países. Su foco es la creación, desarrollo y gestión de una comunidad global de profesionales que trabajan de forma cotidiana en la gestión de PMOS. Su enfoque está basado en un benchmarking realizado sobre las experiencias de una comunidad internacional, formada por profesionales de la PMO.

Según el folleto del curso, “Este curso tiene como objetivo principal certificar profesionales en la metodología internacional denominada PMO VALUE RING, que se puede utilizar para crear, evaluar y reestructurar una Oficina de Proyectos – PMO, centrándose en la generación de valor para la cartera de proyectos para toda organización tanto para proyectos Waterfall como Agile”. El profesional certificado PMO-CP puede demostrar la alineación con la metodología más importante en el mundo para la gestión estratégica de las PMO, basada en las mejores prácticas y la investigación internacional.

De forma adicional, existe un software opcional, basado en esta metodología, que hace más sencilla su implantación y mantenimiento. Durante el curso se va haciendo referencia a los diferentes pasos en la herramienta, pero se debe destacar que se puede hacer uso de la metodología sin necesidad de adquirir una licencia de uso de la herramienta.

Su mindset (o mentalidad) es la de proponer que la PMO sea vista como un “proveedor de servicios” y como tal, posee sus clientes, los stakeholders, cada uno con necesidades y  expectativas específicas. Atender esas expectativas es la mejor forma de generar valor percibido. La PMO cumplirá este objetivo proporcionando “servicios” (funciones) de la mejor manera posible.

Según esta metodología, existen 8 pasos que es necesario seguir para asegurarse de que una PMO aporta valor:

  1. Definir las funciones de la PMO, de acuerdo con las necesidades de los stakeholders.
  2. Equilibrar las funciones de la PMO. Las funciones que la PMO deberá desempeñar deberán ser elegidas considerando su capacidad de generar valor percibido permanente (corto, medio y largo plazo) en los stakeholders.
  3. Estabilizar los procesos de la PMO. Es esencial describir como será ejecutado cada proceso elegido, pues es la vía más efectiva de asegurarse de que la PMO entrega valor.
  4. Seleccionar indicadores de desempeño, para poder monitorizar la calidad y demostrar que la PMO está generando valor
  5. Evaluar al equipo, asegurarse de que los miembros del equipo de la PMO cuentan con las competencias adecuadas y elaboración de planes de desarrollo
  6. Evaluar la madurez de la PMO y planificar su evolución
  7. Determinar el ROI de la PMO, considerando la realidad de la empresa.
  8. Establecer un panel de control que monitorice ciertos indicadores estratégicos, que determinen si la PMO cumple con lo prometido
PMO Value Ring

De forma paralela, existen varios mitos sobre la gestión de las PMO que consideran que se deben desmontar:

  1. Mito Nº 1: “El primer paso es elegir el tipo ideal de PMO. Adherirse a un tipo de PMO establecido no va a hacer que la PMO tenga éxito. Lo que realmente importa es que la PMO ofrezca servicios que atiendan las necesidades de sus stakeholders. Las funciones pueden ser estratégicas, de soporte, centro de excelencia o de varios tipos mezclados.
  2. Mito Nº 2: “Proveer una metodología y herramientas para gestionar proyectos es  suficiente para que una PMO sea exitosa.  Las expectativas diferentes deben ser atendidas por un conjunto de funciones diferentes. Por lo tanto, no hay estándares para las PMOs. Cada una debe proveer una mezcla específica de funciones.
  3. Mito Nº 3: “Primero defina el equipo de la PMO, después qué va hacer la PMO. Comúnmente, las PMOs son creadas de forma contraria a lo que se recomienda. Primero se establece el equipo de la PMO, a continuación, se define lo que hará la PMO.  Lo recomendable es hacer esto justo al revés.
  4. Mito Nº 4:El éxito de los proyectos de la organización es la mejor prueba del  éxito de la PMO”.  No siempre el éxito de los proyectos indica el éxito de la PMO
  5. Mito Nº 5: “Las competencias  necesarias para un profesional en PMOs son  las mismas de un director de proyectos.” Todos los asistentes al taller estuvimos de acuerdo en que las competencias no son necesariamente las mismas. Esta metodología propone 10 competencias básicas: Capacidad de influenciar, Capacidad de integración, Gestión de conflictos, Comunicación efectiva, Gestión de proyectos, Gestión de procesos, Proactividad, Relación interpersonal, Enfoque al cliente,  Gestión del conocimiento.
  6. Mito Nº 6: “Una PMO entre más estratégica, más  madura será“. Ser estratégico o operativo no es una señal de madurez, sino una  consecuencia de las necesidades de las partes interesadas.
  7. Mito Nº 7: “Es imposible calcular el retorno financiero de la PMO. Es obligatorio descubrir el retorno financiero de una PMO, considerando la realidad de la empresa
  8. Mito nº 8: “Monitorizar estratégicamente la PMO es lo mismo que monitorizar el porfolio estratégico de la organización”.  Monitorear el portafolio estratégico de proyectos es una función, no necesariamente un propósito.

 

Es interesante el enfoque práctico de esta metodología, es decir, si los stakeholders no perciben que la PMO les aporta valor, lo más probable es que la PMO acabe siendo cancelada. O peor aun, la PMO puede acabar siendo un “muerto viviente”, que no sabe que ya no está viva.

Enlaces interesantes:

 

CERTIFICACIÓN PMO-CP (CERTIFIED PRACTITIONER)

Realizado el taller formativo, lo siguiente es afrontar el examen de certificación.

El examen se compone de un total de cuarenta preguntas, de las cuales es necesario acertar un 75% de las mismas, es decir, treinta. No se permite la consulta de ningún tipo de material durante el examen. Las preguntas son de tipo test, con cuatro posibles soluciones. Las preguntas más complejas se pueden resolver por descarte.

El examen se realiza a través de la plataforma Moodle de PMOGA eso si, planificado y supervisado on line a través del sistema Proctoru.  Para lo que no conozcan este sistema, es bastante exigente en lo que se refiere a las condiciones en las cuales se desarrolla el examen, para asegurarse de que no se consulta ningún tipo de material durante el examen.

Sin sorpresas, asistiendo al taller de preparación (obligatorio) y estudiando los dieciséis Papers (en inglés), junto con el material complementario que compone el curso, es suficiente para poder aprobar la certificación.

 

 

 

 

 

 

 

 

 

LIBRO PEOPLEWARE Y EQUIPOS ÁGILES

Título original: Peopleware y Equipos Ágiles

Autor: Javier Garzás

Editorial: 233gradosdeTI

Páginas: 200 (color)

Idioma: español

ISBN: 978-84-697-7450-2

Palabras clave: Proyectos, gestión equipos

Esta reseña nació cuando, hace unos meses, un grupo de compañeros de empresa asistimos a una keynote de Javier Garzás llamada  “Qué es la Agilidad y cómo te puede ayudar a no acabar en una empresa zombi“:  Keynote en la Universidad de Alicante.

La verdad es que nos pareció muy interesante, pues  ya seguíamos desde hace tiempo el blog de Javier.

Así que cuando saltó la noticia  de que Garzás había publicado un nuevo libro, varios fuimos los que nos apresuramos a adquirirlo.

Destacar que es todo un detalle que el autor te dedique el libro bajo petición. Adicionalmente, yo obtuve un dibujo de Darth Vader de bonus. ¡Mola!

Ya entrando en materia,  el objetivo del libro es profundizar en el cambio en la organización de las personas y en los equipos dedicados al software/hardware que se ha producido en las últimas décadas. Según la Wikipedia, Peopleware es “…cualquier cosa que tenga que ver con el papel de las personas en el desarrollo o uso de software y sistemas hardware, incluyendo cuestiones como productividad de los desarrolladores, trabajo en equipo, dinámicas de grupo, la psicología de la programación, gestión de proyectos, factores de organización, diseños de interfaces de usuario e interacción hombre-máquina.”

Originalmente, “Peopleware, Projects and Teams” es el título de un libro de los años 80 de los autores De Marco/ Lister, referido específicamente al desarrollo de software.

Javier desea remarcar la importancia de las personas en los proyectos/productos /equipos, pues en el fondo son la clave del éxito de cualquier proyecto.

El principal mensaje del autor, adquirido a través de una experiencia de haber trabajado en un montón de empresas remarcables, es que en el desarrollo de software se debe  dejar atrás el taylorismo y la industrialización. Pues se implantó esa visión también en los proyectos de desarrollo de software, un verdadero error, pues no es adecuado y ha generado muchos más problemas de los que ha solucionado. Desarrollar software no es lo mismo que construir un puente o levantar un edificio.

El nacimiento de la agilidad y del Manifiesto Ágil fue una reacción a lo poco apropiados que eran los métodos de trabajo tradicionales para gestionar el desarrollo de proyectos de software. Es más, cambiando la palabra “Software” por “soluciones” se puede aplicar el manifiesto ágil más allá del desarrollo de software.

La visión del Management ya no es gestionar a las personas como a máquinas y procesos (versión 1.0), sino orientada a personas y equipos en una estructura organizativa pensada para ello (versión 3.0).

Destaca que en las empresas existen “tribus” entendidas como la forma en la que trabajan, que hace que se entienda mejor el concepto de “Peopleware” y que van desde el tipo 1 (individualismo por la superviverncia)  hasta el tipo 5 (equipo ágil).

Se mencionan los equipos Good to Great, que cumplen con  siete pautas que distinguen  a las empresas punteras del sector, que pasaron de lo bueno a lo excelente.

Los equipos son complejos. Por eso, la adaptabilidad es adecuada para los sistemas complejos y para las incertidumbres.

Ante todo, en la gestión de equipos debería evitarse tratar de resolver problemas complejos con soluciones fáciles, que suelen acabar empeorando el problema que pretendían solucionar: es lo que se llama reduccionismo o “populismo tecnológico”  (véase el caso del efecto cobra). Pensad en ejemplos que se os ocurran (fomentar el presencialismo en la empresa en lugar de la productividad, montar sistemas para fichar todas las mañanas, exigir un montón de documentación, nombrar un comité para resolver un problema, etc…)

Los equipos de trabajo deberían de contar con las siguientes características:

  • Estar motivados. El tema de las motivaciones y recompensas tiene mucha miga. El autor alerta de que las recompensas pueden hacer que las personas trabajen casi exclusivamente para obtenerlas.
  • Ser Auto organizados, pero que un equipo sea dirigido y organizado por sus propios miembros no significa que non haya jefes o managers. lLa diferencia es que estos se reducen a lo necesario.
  • Ser Mutifuncionales, todos deberían de poder hacer casi cualquier tarea dentro del equipo
  • Por supuesto, ser Productivos. en este punto, ojo con medir el trabajo con sistemas que no favorecen la calidad, como el de contar las lineas de código/hora.

Y un equipo debería de estar orientado a la mejora continua, es preciso fomentar una cultura de la reflexión y de la mejora (a través de sesiones de Retrospectiva o de Lecciones Aprendidas).

Resumiendo, un gran libro que merece una lectura detenida, (yo ya lo he releído un par de veces), pues la gestión de los equipos y de las personas tiene actualmente más importancia que nunca si se desea obtener el éxito en  proyectos o iniciativas.

 

 

 

 

 

 

 

 

LIBRO CADENA CRÍTICA

Título original: Critical Chain

Autor: Eliyahu M. Goldratt

Editorial: Ediciones Díaz de Santos, año 2014 (kindle)

Páginas: 296

Idioma: español

ISBN: 9788479784843

Palabras clave: Proyectos, gestión recursos, ruta crítica, cadena crítica

En esta entrada voy a hablar de “Cadena Crítica”, un libro que ha obtenido la categoría de clásico en la materia de la gestión de proyectos y cuya edición impresa data de de más ni menos que del año 1997. Y el caso es que ya conocía la teoría de la cadena crítica de haberla estudiado para la certificación PMP (un par de preguntas fueron de esta materia).  Y aún así, su lectura me ha sorprendido. Mil gracias, Juan Carlos, por proporcionarme el libro.

El autor (Eliyahu M. Goldratt) es el creador de una serie de libros de Management y creador de la Teoría de las Restricciones (TOC). Este libro “Cadena Crítica” fue dedicado por su autor a la aplicación de TOC a la materia de la gestión de proyectos. Se ha convertido en la base de la teoría de la cadena crítica, apta para un esquema de limitación de recursos.

La lectura es novelada. No es muy habitual en libros de Management, pero eso hace que se lea con interés. Además de ser interesante para la gestión de proyectos, también es interesante para formadores que desean un enfoque diferente para sus clases. Esto se debe a que el relato presenta a un profesor que busca conjugar el conocimiento teórico de la universidad  en el entorno de la impartición de un MBA con las situaciones que le presentan sus estudiantes, procedentes de su día a día en sus empresas. Al final, estamos en presencia de interesantes clases de descubrimiento del conocimiento. Un  tema secundario que subyace en el libro está de plena actualidad, ¿Están preparadas las universidades para entregar verdadero conocimiento práctico a las empresas?.

Hablando ya de la gestión de los proyectos, en las clases se duda de la eficiencia de medir el grado de avance de los proyectos como medida eficaz para establecer su progreso. Irónicamente, el proyecto puede estar al 90% de progreso una vez transcurrido un año, y luego emplear otro año para cumplir con el restante 10 %. Si se pierde el foco en la ruta crítica ( secuencia de los elementos terminales de la red de proyectos con la mayor duración entre ellos, determinando el tiempo más corto en el que es posible completar el proyecto), entonces es fácil que se produzca retraso, pero que no se sepa, que es lo peor de todo.

El mensaje está claro, es un error el modo en el cual medimos el avance de los proyectos, pues:

  1. Las mediciones deberían inducir a las partes a hacer lo que sea bueno para para el sistema entero
  2. Las mediciones deberían de guiar a los gerentes hacia los puntos que necesiten su atención.

Por lo tanto, la conclusión a la que llegan en las clases es que en los proyectos las mediciones alejan al líder del proyecto.

A través de un técnico que trabajó en otra empresa, los protagonistas conocen la teoría de las restricciones (TOC). El autor del libro había sentado las bases de la TOC en su libro previo (1984) “La Meta, Un proceso de mejora continua”. Sus características son tres:

  1. Es una nueva filosofía gerencial
  2. Es un método de investigación
  3. introduce un amplio espectro de aplicaciones

La metodología de esta teoría se basa buscar la limitación del sistema estudiado y se compone de cinco puntos:

  1. Primer paso, identificar las restricciones del sistema  (el eslabón más débil)
  2. Segundo paso, diferenciar las restricciones físicas y políticas
  3. Tercer paso, subordinar todo lo demás a la decisión tomada
  4. Cuarto paso, elevar (superar) las restricciones del sistema
  5. Quinto paso, si se rompe una restricción, no permitir la rutina y volver al primer paso

Existen tres posibles tipos de limitaciones:

1. Limitaciones físicas: son por ejemplo los recursos personales o materiales

2. Limitaciones políticas: son por ejemplo las reglas empresariales

3. Limitaciones de mercado: por ejemplo los producidos por el propio mercado al que se dirige la empresa

La TOC exige definir un problema con precisión, pues un problema no está bien definido hasta que no puede representarse como un conflicto entre dos condiciones necesarias.

Otra experiencia que aportan los estudiantes del relato es el de tener prevención con los indicadores operativos obsoletos (en la novela se habla de la medición de tonelada/hora de la industria metalúrgica) . La gente se comporta según se la mide.

Para resolver problemas, el método que introduce la TOC es el de la “evaporación de las nubes“,  es decir,  proponer una estructura lógica diseñada para identificar e ilustrar todos los elementos en una situación conflictiva o dilema y sugerir formas de resolverlas. Por ejemplo, no puede haber arreglos a medias (un edificio o mide 30 o 40 metros, pero no se puede dejar a la mitad, pues esto es lo que pasaría si se tratara de optimizar la respuesta).  Si se detectan  situaciones ganar-perder, es porque no se está observando adecuadamente el problema: ganando en amplitud, identificaremos la situación ganar-ganar. Al estudiar y comprobar las suposiciones adyacentes es posible encontrar  soluciones en las que ambas partes ganen (win to win), y nos permitan “Evaporar la nube”.

Otra cosa que descubren los estudiantes del relato es que en sus propias empresas nadie quiere reconocer que mete un factor de protección en sus estimaciones de tiempo de las tareas que componen los proyectos. Es más, a mayor incertidumbre mayor protección se suele añadir. Y los managers agregan su propio factor de protección. Así las estimaciones de tareas de un proyecto están realmente infladas. Pero ¿que es lo irónico de todo esto?. Pues que si las estimaciones incluyen tanta protección, ¿Por qué tantos proyectos no se acaban a tiempo?. La conclusión a la que llegan los estudiantes en las clases es sencilla: si las tareas se acaban antes de lo planificado las siguientes no se inician antes, por lo que este tiempo se desperdiciará. Es decir, las demoras se acumulan, pero lo avances no.

Otros factores destacados que se suman para hacer que la protección se desperdicie son:

  • El síndrome del estudiante. Es decir, retrasar las tareas hasta las últimas fechas y pedir mas plazo para hacer un mejor trabajo.
  • La multitarea y el robo de tiempo que implica, por el gran trabajo que cuesta volver a enfocarse cuando se trabaja en múltiples proyectos a la vez
  • Las dependencias entre las tareas, pues las dependencias son las verdaderas culpables de que las demoras se acumulen, pero los retrasos se desperdicien

La idea surgió casi por sí sola, poner amortiguadores (o buffers) protegiendo la ruta crítica y claro está, teniendo cuidado de que las tareas que no estén en la ruta crítica se convierta en parte de ella. La experiencia dice que la ruta crítica cambia durante el proyecto.

Existen tres tipos de buffers:

  • Buffer de Proyecto: Para proteger el camino o ruta crítica del proyecto.
  • Buffers de Alimentación: Para proteger las tareas que podrían  convertirse en camino crítico en un futuro
  • Buffers de Recursos: se protege la cadena crítica avisando a los recursos críticos del comienzo inminente de sus tareas. Es una tarea virtual que queda insertada justo antes de las actividades de la cadena crítica, cuando requieren de la utilización de recursos de idéntica importancia.

Un problema especial se puede producir con las entregas de los proveedores. No están condicionados a entregar a tiempo sino que compiten en base al precio. En sus estimaciones de entrega se ponen un generoso colchón de tiempo para resolver conflictos entre los pedidos. Pero las demoras en la entrega cuestan mucho dinero a las empresas contratantes. La idea para solucionare esto es añadir a las RFP un “precio tope” pero también un “tiempo tope”. Es interesante no dar una fecha de finalización al proveedor para evitar el mencionado “síndrome del estudiante” .

Respecto a la gestión de los recursos, hay que entender que la restricción es la cadena más larga entre pasos dependientes, tanto de tareas como de recursos. En este punto hay que tener cuidado, pues si si existe competencia por los recursos, entonces la cadena crítica puede ser muy diferente de la ruta crítica. Un problema con los recursos puede hacer que la ruta crítica salte por los aires. Por eso, la cadena crítica busca eliminar la competencia entre los recursos de un proyecto y debe esforzarse en tratar de eliminar la competencia entre los diferentes proyectos que compongan un  portfolio.

Por cierto, la traducción del libro es bastante pobre y muy mejorable. Dicho lo cual, se trata de una lectura imprescindible para todo Project Manager.

 

 

 

 

 

 

 

 

 

 

 

 

 

LIBRO AGILE PRACTICE GUIDE

Título original: Agile Practice Guide

Autores: PMI + Agile Alliance

Editorial: Project Management Institute, año 2017

Páginas: 210

Idioma: inglés

ISBN: 978-1628251999

Palabras clave: Proyectos, Metodología, Agile, PMP, Project Management, Predictiva

Interesante este libro escrito conjuntamente entre PMI y Agile Aliance. Un apunte, si formas parte de PMI y pagas las cuotas anuales de socio, puedes descargar este libro de forma gratuita en formato pdf desde la web de www.pmi.org 

Y da que pensar que el PMI (que ya cuenta con una certificación especifica en materia de agilidad) da por sentado que la agilidad es una metodología que ha llegado para quedarse durante mucho tiempo entre los Project Managers.

Dado que la agilidad se ha expandido a otros ámbitos de desarrollo, el enfoque de este libro se expande más allá del mundo de desarrollo de software

Esta guía está dividida en siete secciones.

1. Introducción

¿Por qué un manual de este tipo ahora? Porque la agilidad es una metodología que busca proporcionar al cliente una inmediata entrega de valor, a través de varias interacciones y esto es muy valorado ahora, pues las empresas buscan ser competitivas orientándose a la experiencia que obtiene el usuario. Son adecuadas para manejar la disrupción.

Los autores comentan que no está en alcance de este libro estudiar cómo extender la agilidad entre toda la organización sino extenderla a uno o varios proyectos. Es una lástima, porque si la organización no cambia es difícil que los proyectos ágiles tengan éxito.

2. Introducción a la agilidad

  • Esta sección trata fundamentalmente del origen de la agilidad y de los principios que lo sustentan
  • la justificación de la agilidad se basa en que el manejo de la incertidumbre es algo que las metodologías predictivas no manejan bien, pues no están orientadas a aceptar el cambio, la complejidad y el riesgo.
  • El manifiesto ágil de desarrollo de software del año 2001 puso por encima de todo a las personas por encima de los procesos. Se crearon cuatro valores y doce principios
  • Me llama la atención la referencia a la relación entre Lean/agile, pero el enfoque de ambos es diferente
  • Interesante la matriz de complejidad de Stacey. Un proyecto puede empezar en un sitio de la matriz y acabar en otro.

Resumiendo, los proyectos más adecuados para ser abordados por la metodología agil son aquellos que:

  • Requieren de investigación
  • Tienen altas posibilidad de sufrir cambios
  • Presentan requerimientos desconocidos o poco claros
  • Tienen un propósito difícil de describir

3. Selección del ciclo de vida

Es la parte más interesante del libro, con diferencia.

Habla de los cuatro tipos de ciclos de vida de los proyectos: predictiva, iterativa, incremental y ágil y de sus características.  Estoy de acuerdo con su apreciación de que no hay un ciclo de vida perfecto para todos los proyectos:

  • Los ciclos de vida predictivos se benefician de entornos en los cuales los requerimientos están bien definidos y marcados (ej. un proyecto fruto de una exigencia legal). Su punto débil son los cambios y que no entregan valor hasta el final del proyecto.
  • Los ciclos de vida iterativos son beneficiosos si existe una alta complejidad, si hay cambios frecuentes o si el alcance depende de diferentes interesados. Están optimizados para el aprendizaje. Un ejemplo son las “refactorizaciones” de software.
  • Los incrementales se orientan a la velocidad de la entrega. Se entregan frecuentes y pequeños entregables. Un ejemplo puede ser completar un aplicativo de software mediante el desarrollo de diferentes módulos. O mostrar cómo quedaría una habitación en el proyecto de construcción de un edificio.
  • Los agiles son excelentes aproximaciones cuando se espera una gran cantidad de cambios en un proyecto. La diferencia de ágil con los ciclos interactivos e incrementales es que estos últimos proporcionan feedback para la siguiente parte del proyecto, pero, sin embargo, en proyectos ágiles, la entrega incremental descubre ocultos o requisitos incomprendidos. A su vez, los ciclos agiles pueden basarse en iteraciones o en flujos de trabajo. los ciclos ágiles combinan aproximaciones incrementales e iterativas para entregar valor de forma frecuente al cliente.
  • Como síntesis de todo lo anterior surgieron los ciclos de vida híbridos, que son los que se combinan para obtener ciertos objetivos. Por ejemplo, se puede trabajar en las primeras fases de un proyecto con metodologías ágiles (si se necesita investigación) y luego pasar a una metodología predictiva (si se debe cumplir una certificación). O combinar ambas metodologías según para qué aspectos (a mí esto me parece más complejo). Hay muchas combinaciones posibles.
  • Este apartado es tan interesante y está descrito a tan alto nivel, que necesita más desarrollo.

4. Implementando ágil: Creando un entorno ágil

Mencionan que un entorno ágil exige un líder “sirviente”, (que haga de facilitador del éxito del equipo), en lugar de un líder tal y como se describe en los proyectos predictivos. Este tipo de lider debería de pasar de “gestionar” la coordinación a “facilitar” la coordinación.

No se ha tocado la parte correspondiente al “mapeo” de roles entre metodologías predictivas/ágiles. Otro tema interesante pendiente.

Y le impone al líder “sirviente” una tarea adicional, tratar de remover los impedimentos organizativos al equipo del proyecto que pudieran hacer de “cuello de botella”. Sinceramente pienso que si la organización no se orienta a la agilidad, es bastante complejo que el líder sirviente pueda solucionar por sí solo este problema.

Precisamente y dado que el papel del project manager no se contempla dentro de la agilidad, pues según el PMOK 6 son los encargados de obtener los resultados del proyecto y esta responsabilidad en ágil se distribuye por igual en el equipo del proyecto, propone que hagan de lideres “sirvientes”, es decir, que sirvan al equipo del proyecto, allanando su camino.

Si el enfoque predominante es ágil, entonces el papel del PM cambia radicalmente y debe orientarse hacia el liderazgo servil que requiere este tipo de enfoque.

Se habla de los atributos de los equipos agiles exitosos. Comenta que a los equipos ágiles se les debe evitar el coste que supone la “multitarea” de trabajar en varios proyectos de forma simultánea, así como que idealmente deberían de compartir el mismo espacio físico. Se alerta contra el peligro de querer trabajar en forma de “mini waterfalls” que es lo que sucede si se presupone que ya se tienen todos los requerimientos y ya se puede hacer todo el diseño (por ejemplo) o todo el desarrollo. El equipo se dará cuenta de que esa asunción en el mundo ágil no es válida.

Los tres roles que menciona son: product owner, equipo multifuncional y facilitador del equipo (llámese scrum master, project manager o team coach). Apunta que lo ideal es contar con especialistas de tipo “T”, que son los que complementan ser expertos en una materia con conocimientos en otras areas.

Alerta acerca de evitar “silos” en la empresa que impidan que la comunicación fluya en el equipo.

5. Implementando ágil: entregando en un entorno ágil

Todo proyecto necesita un acta de constitución donde se defina el proyecto. Pero esto no es suficiente n un entorno ágil. También necesita una visión, un propósito y unas normas de cómo trabajar en equipo.

Las prácticas agiles más importantes son:

  • Retrospectivas. Permite al equipo aprender, mejorar y adaptar su proceso. No es necesario que sea al final de una iteración de dos semanas. se puede solicitar en cualquier momento. Busca las causas raíz de los problemas sufridos y se desarrolla un plan de acción para solucionarlos.
  • Preparación del backlog (lista del trabajo presentado en forma de historias de usuario). No es necesario tener todo el trabajo que el proyecto requiera sino solo el que se va a desarrollar en siguiente sprint o iteración. Esta es tarea del product owner
  • Refinamiento del backlog. Es la preparación de historias de usuario para la siguiente iteración. Si no se conocen las dependencias entre tareas entonces el product owner puede solicitar al equipo la realización de un “spike“, con el fin de conocer los riesgos. Señala que el equipo no debería de emplear más de una hora a la semana en refinar historias. En caso contrario podría indicar que al equipo le faltan habilidades técnicas necesarias para evaluar y refinar el trabajo.
  • Reuniones diarias. Las mini reuniones diarias (de no más de 15 minutos) se usan para declarar lo trabajado, lo que se va a trabajar, así como para hacer aflorar posibles problemas. No se deben convertir en sesiones de análisis de situación del proyecto ni tampoco se deben usar para tratar de resolver problemas.
  • Demos/reviews. Para proporcionar feedback al product owner, se organizan demos de lo desarrollado en cada iteración. Deben ser frecuentes para así poder dar con la dirección adecuada.
  • Planificación de la iteración. La capacidad de cada equipo es diferente. Se debe hacer una estimación de la capacidad.
  • Prácticas de ejecución que ayudan a los equipos a entregar valor:
    • Integración continua
    • Test en todos los niveles
    • ATDD test de aceptación.
    • TDD y BDD test driven development y behavior driven development
    • Spikes. Útiles para aprender sobre elementos técnicos o funcionales críticos.
  • Cómo las iteraciones y los incrementos ayudan a entregar producto. Las iteraciones ayudan al equipo a crear una cadencia de entrega y muchos tipos de feedback. Las demos son una parte necesaria dentro del flujo de los proyectos ágiles.

Por otra parte, se señalan los desafíos que implican los proyectos ágiles y las posibles soluciones. Muy interesante esta parte.

Medidas en los proyectos ágiles:

  • Es un desafío tratar de determinar la medida de avance en un proyecto ágil. Además de las medidas cuantitativas habituales, cobra importancia añadir medidas cualitativas, como la satisfacción del usuario o la moral del equipo de desarrollo.
  • Los valores de avance en agil son empíricos y tratan de lo que se ha hecho, en lugar de que va a realizar. Por su naturaleza, la estimación se limita a unas pocas semanas.
  • La velocidad del equipo calculada en story points es lo que realmente puede permitir hacer una estimación de cuando se podrá terminar el proyecto.
  • Si el quipo depende de las tareas de externos al proyecto, esto puede interferir en su velocidad notablemente.
  • Para que el progreso de un proyecto ágil sea comprensible a un project no iniciado en ágil, se hace una equivalencia de cómo calcular el Valor Ganado (EMV) haciendo un sencillo cálculo del índice SPI (cronograma) características completadas/características planificadas y del CPI (coste) valor ganado/costes actuales

6 Consideraciones organizativas para proyectos agiles

Los autores son conscientes de que los proyectos existen en un contexto determinado. Por eso se considera fundamental el cambio organizativo que permita aplicar la agilidad, en especial se consideran fundamentales los cambios asociados a la entrega rápida y frecuente y a los cambios constantes en los requerimientos. El mismo PMI publicó una guía para gestionar el cambio en las organizaciones: Managing Change in Organizations: a Practice Guide

Dice la frase de Peter Druker “Culture eats strategy for breakfast”, la cultura de la empresa, que es su ADN, siempre impacta de forma intensa en las estrategias y en especial en el uso de aproximaciones ágiles en la gestión de proyectos.

Respecto a la parte de la gestión de contratos con proveedores, los autores animan a seguir un esquema de contratos de tipo “win-win”, (todos ganan con el acuerdo) que no es una característica en absoluto privativa de los enfoques ágiles.

Por otra parte, los típicos contratos con proveedores que se firman en ciclos de vida predictivos pueden generar grandes riesgos si se trasladan a ciclos de vida ágiles. En especial, puede ser muy arriesgado firmar tanto contratos de tipo “Time and Materials” o “llave en mano” con precio cerrado.

Se menciona cómo gestionar varios equipos ágiles, cuando se requiere la gestión de un portfolio o un programa se hace necesaria. En Scrum se desarrolla el “Scrum of Scrums“.

Es destacable la parte que habla de la relación entre proyectos ágiles y la PMO (Oficina de Gestión de Proyectos). La PMO ayuda a los equipos de proyectos a tener éxito. Y dado que la agilidad crea un cambio, por consiguiente, la PMO debe cambiar y debería perseguir ayudar a los equipos ágiles, una PMO ágil debería de ser una PMO que busque la satisfacción de los usuarios y compatibilizar este objetivo con ser un centro que busque la excelencia.

7 Llamada a la acción

La demanda de agilidad está incrementándose en todos los sectores, la cuestión es cómo enfocar los proyectos para que se aprovechen los beneficios de la agilidad. Y los autores son conscientes de que sus lectores pueden haber echado en falta más información. Precisamente por eso apuntan a seguir cubriendo este interesante tema en sucesivas entregas.

 

 

 

APÉNDICES:

El libro finaliza con una interesante selección de apéndices, entre los cuales destaca el Apéndice X3 Modelo para la Idoneidad del Enfoque Ágil, enfocado a determinar cuándo es mejor utilizar un enfoque ágil en los proyectos

CONCLUSIÓN:

¿Cuál es el objetivo de este libro? Se trata de buscar una aproximación e integración entre las metodologías predictivas y el mundo ágil. ¿Y cómo enfocar esa integración? Está claro que no se trata solamente de añadir más apartados al PMBOK que ya está en su sexta edición. Se trata de construir una versión unificada de ambos puntos de vista. Creo que, aunque se trate de metodologías muy diferentes, el project manager deberá escoger la más adecuada que dependerá del tipo de proyecto de que se trate. Tan sencillo como que se aproveche lo mejor de cada una de ellas, es decir, la aproximación “híbrida” a la gestión de proyectos. Un project manager que se precie, debería saber qué enfoque adoptar, en base a las características del proyecto. Una tendencia que se destaca después de una lectura del PMBOK 6 es que las diferentes metodologías empiezan a converger y cada una adopta lo mejor de las otras.

Es un libro hecho para ser leído por project managers expertos en proyectos predictivos, que deseen conocer lo que les puede aportar el enfoque agile. A un experto en agilidad no le va a aportar nada nuevo.

Esta lectura me ha sabido a poco. Es un tema muy interesante y que tiene mucho recorrido por delante. Esperemos que no tarden en publicar más libros sobre esta temática.

REFERENCIAS:

What is the Purpose of the New PMI Agile Practice Guide?

ACTUALIZACIÓN DE 2018:

Ya ha salido publicada en español la Agile Practice Guide.

Este libro se puede obtener en estos dos sitios:

  • Siendo miembro de PMI:
    • Se puede descargar de forma gratuita en formato pdf (protegido) desde la web de PMI
    • Alternativamente, se puede encargar en formato papel a mitad de precio que los no miembros
  • No siendo miembro de PMI:

 

 

 

 

 

 

 

 

 

SCRUM LEVEL

Esto se había quedado en el tintero. Hace unos meses realicé un interesante curso de Scrum Level, que merece la pena ser comentado. 

Cuando se desea implantar la agilidad en las empresas, se pueden producir problemas  o conflictos con la “cultura” o las prácticas aceptadas dentro de la propia empresa, pues cada una es diferente del resto.

Scrum Level está orientado a evitar esos conflictos, estableciendo las mejores prácticas que se deben implantar y lo hace realizando un diagnóstico personalizado de lo que se necesita poner en práctica  para hacer que las empresa se aprovechen de los beneficios de los enfoques ágiles, sin romper con todo lo anterior.

¿Cómo se define Scrum Level? Es un modelo de evaluación y mejora de la agilidad de las empresas, tanto a nivel técnico, como de la organización en su conjunto.

Extraido de su web: “Propone un método sistemático con el que analizar y evaluar las dimensiones y aspectos que determinan el nivel de agilidad organizacional. El análisis obtenido con Scrum Level revela las fortalezas y debilidades de los diferentes ejes que define el modelo, y apunta las áreas susceptibles de mejora, así como las actividades o prácticas que pueden reforzarse”

http://scrumlevel.com

Scrum Level nace de la experiencia de un reducido número de profesionales y  busca reducir la variabilidad  típica de las implantaciones y progreso de la agilidad,  a partir de los proyectos desarrollados entre sus clientes.

Para ello Scrum Level analiza indicadores y evidencias deforma separada en dos dimensiones:

DIMENSIONES:

  • Dimensión técnica:  flexibilidad.
  • Dimensión organizativa:  fluidez.

FACTORES ANALIZADOS:

  • Ejes orgánicos.
  • Técnicas y prácticas de trabajo.
  • Capacitación técnica de las personas.

Las organizaciones que desean implantar o mejorar un entorno de trabajo ágil, necesitan una guía y criterios de referencia para identificar y analizar las áreas de mejora.

“Scrum Level cubre este objetivo, definiendo una guía de referencia y apoyo para mejorar la agilidad de las organizaciones”

En curso  se aprende el uso del modelo de evaluación y mejora Scrum Level, y se dispone de la guía, herramientas de protocolo y competencia necesarios para llevar a cabo procesos de evaluación con los que identificar las fortalezas y áreas de mejora en la agilidad organizativa de equipos y empresas. Es un curso eminentemente práctico.

Respecto al modelo de licenciamiento, derecho de uso del material y de la certificación, se distinguen tres niveles:

  1. Consultor independiente:
    El modelo y los materiales de Scrum Level se ofrecen con derechos de uso liberados (Creative Commons By). Pueden emplearse libremente en actividades profesionales de mejora o evaluación, con o sin ánimo de lucro.
  2. Consultor certificado:
    La certificación garantiza el conocimiento profesional del modelo Scrum Level adecuado para el desempeño en actividades de mejora o evaluación. Para conseguir la certificación es necesario aprobar el examen oficial de consultor Scrum Level que forma parte de los cursos profesionales de Scrum Manager®.
  3. Evaluador certificado:
    Profesional autorizado por ScrumLevel para realizar evaluaciones oficiales como evaluador responsable.
    Para ser evaluador certificado es necesario ser consultor certificado y acreditar los requisitos profesionales necesarios:

    1. Experiencia profesional mínima de 5 años en asesoría o gestión en organizaciones TIC.
    2. Experiencia profesional mínima de 3 años en asesoría o gestión en organizaciones TIC, y experiencia previa en evaluaciones Scrum Level independientes

Por otra parte, señalar que para los que hayáis realizado el curso de Scrum Manager, que la realización y superación del curso de certificado en  Scrum Level en un centro asociado os proporciona 65 PDUS válidos para el mantenimiento de la certificación  Scrum Manager. Recordad que Scrum Manager distingue entre Acreditación (examen aprobado con nota mínima de 8, pero no realizado ante centro asociado) y Certificación (examen aprobado con nota mínima de 8 y realizado en un centro homologado).

Usar técnicas y prácticas ágiles en un marco de producción sin una cultura ágil, no es propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de vida incremental, o lo que se podría llamar “agilidad técnica”

 

Referencias:

 

 

 

 

 

 

 

 

 

 

LIBROS SOBRE GESTION DE RIESGOS EN PROYECTOS

Dado que uno de mis objetivos de este año a nivel de empresa es poner en marcha un sistema de gestión de riesgos en nuestra PMO (Oficina de Proyectos), me puse a explorar por Internet para ver material de apoyo y encontré estos dos libros de la autora Liliana Butchik que son objeto de la reseña.

La verdad es que me llamaron la atención, puesto que  no suele haber mucha literatura sobre este tema en idioma español.

Por eso los compré. Destaco que el único sitio donde pueden adquirirse “on line” es en la web de la autora, exactamente aquí: libros Secretos Riesgos en Proyectos

El envío tardó unos 15 días en llegar vía Correo Uruguayo y lo recibí sin problemas, lo mismo que otro libro que compré, “Secretos para Dominar el Portfolio de Proyectos” y del que más adelante escribiré su reseña.

El libro Secretos para dominar la gestión de riesgos sigue la metodología establecida por PMI acerca de la gestión de riesgos y está enriquecido por las experiencias personales de la autora, que trabajó en el staff de PMI USA

Destaco que tiene una sección de plantillas, pues se trata de un libro pero que muy práctico, cuyo objetivo es  ayudar a poner en marcha la gestión de riesgos en una empresa.

Sobre su nivel, está orientado a ser utilizado tanto por personas sin experiencia previa, como por profesionales que desean investigar más en alguna faceta particular del campo de la gestión de riesgos.

A destacar la parte referente a la sección de software orientada para gestionar riesgos. No es sencillo encontrar este tipo de información comparada.

Otro uso de este libro es para preparar la certificación de RMP-PMI. En este aspecto, se complementa  con el siguiente libro adquirido.

Secretos para salvar el examen RMP-PMI

Este libro tiene dos partes, de los capítulos 1 al 4 habla de qué es la certificación PMI-RMP, qué memorizar, qué dominio y habilidades requiere y una serie de consejos para afrontar con garantía el examen.

La segunda parte (capitulo 5) se corresponde a trescientas  preguntas, muy similares a las que se pueden esperar en el examen oficial de PMI.

Una  vez leídos ambos libros, destaco que me han gustado mucho, me ha interesado especialmente su enfoque práctico, es decir, que la lectura sea util.  Un gran valor añadido está en la experiencia aportada por la autora. Por sacarle alguna pega, pediría que las plantillas estuvieran disponibles para su descarga, (manteniendo su autoría) pues esto evitaría tener que elaborarlas manualmente una a una.  Pero mi experiencia leyendo los libros ha sido muy positiva. Me gustaría que hubiera disponible más material de esta calidad en idioma español.

Ah, y si la autora se decidiera a escribir sobre su experiencia gestionando proyectos bajo metodologías ágiles, ya tiene un ejemplar vendido.

 

 

 

 

 

 

 

 

 

 

CERTIFICACION PRINCE2 PRACTITIONER

¿QUÉ ES PRINCE2?

Después de haber realizado la certificación de Scrum Level y para cerrar el círculo de las metodologías, me propuse conocer lo que me podía aportar Prince2 Practitioner a la gestión de proyectos.

Para superar los exámenes de Prince2 no es obligatorio pasar un curso en un preparador oficial (como se exige en la certificación PMP) pero es muy recomendable realizarlo. Asi que, junto con un compañero de trabajo, me matriculé en un curso de preparación de la certificación Prince2. El examen de certificación se planificó para enero de 2017.

¿Que es Prince2?. La web de QRP lo define así:  “Es un método estructurado de gestión de proyectos. Es una aproximación a las “buenas prácticas” para la gestión de todo tipo de proyectos que se ha convertido en el estándar de facto para la organización, gestión y control de proyectos El método divide los proyectos en fases manejables permitiendo el control eficiente de los recursos y el control periódico de su evolución. PRINCE2 está “basado en los productos”, es decir, los planes del proyecto se centran en obtener resultados concretos, y no sólo en la planificación de las actividades que se llevan a cabo; PRINCE2 proporciona un lenguaje común en los proyectos.”

Más que un conjunto de buenas practicas (como es el PMBOK de PMI), PRINCE2 propone una metodología específica de gestión de proyectos, es decir, cubre todas las temáticas y propone cómo llevarlas a la práctica.

PRINCE2 es el estándar de facto para la gestión de proyectos en varios países, empresas privadas y organizaciones, especialmente en el Reino Unido. Es la metodología seguida, por ejemplo, por la EUIPO.

CERTIFICACIONES:

Existen dos niveles de certificación:

  • Foundation: certifica el conocimiento de la terminología y metodología de gestión de proyectos con PRINCE2
  • Practitioner: certifica la capacidad para gestionar proyectos según la metodología PRINCE2. Se necesita aprobar el nivel Foundation para presentarse a este nivel.

Un apunte, si ya dispones de uno de estos certificados: CAPM, PMP o IPMA no es necesario examinarse previamente del nivel Foundation, pues se convalida automáticamente.

Adicionalmente, Prince2 también dispone de una solución enfocada al mundo Agile. Esta certificación proporciona la guía para adaptar PRINCE2 en un contexto ágil e incluye:

  • Cómo adaptar el conjunto integrado de principios, temáticas y procesos de PRINCE2
  • La forma de crear los productos de gestión de PRINCE2
  • Cómo mapear los roles ágiles a la estructura de equipo de gestión de PRINCE2
  • La manera de incorporar los comportamientos, conceptos y técnicas ágiles fundamentales dentro de PRINCE2

Durante el año 2017 se produjo una gran actualización de Prince2, tanto a nivel de guía como de exámenes. Una de las consecuencias de este cambio es que los exámenes ya no están disponibles en español.

FUNDAMENTOS:

No es mi intención hablar en detalle de la metodología, pues existen otros blogs donde detallan este punto, solo destacar que Prince2 se basa fundamentalmente en:

  • Siete temáticas:
    1. Caso de negocio: manera en que se desarrolla una idea hasta convertirse en un proyecto viable para la organización.
    2. Organización: puestos, funciones y responsabilidades del equipo encargado de ejecutar el proyecto.
    3. Calidad: Se ocupa de desarrollar la comprensión de los interesados respecto a los atributos de calidad de los productos a entregar.
    4. Planes: Describe los pasos requeridos para desarrollar los planes establecidos y las técnicas de PRINCE2 que se deben aplicar.
    5. Riesgo: gestión de las incertidumbres en sus planes.
    6. Cambio: cómo se evalúa y actúa para incorporar los posibles cambios a la línea base del proyecto
    7. Progreso: proceso de toma de decisiones para aprobar planes, seguimiento del avance real y el manejo de excepciones cuando los planes no se cumplen.
  • Siete procesos:

    1. Puesta en Marcha de un Proyecto.
    2. Dirección del Proyecto.
    3. Inicio del Proyecto.
    4. Control de Fase.
    5. Gestión de la Entrega de Productos.
    6. Gestión de los Límites de Fase
    7. Cierre de Proyecto
  • Siete  principios (que se deben seguir obligatoriamente):
    1. Justificación comercial continua
    2. Aprender de la experiencia
    3. Roles y Responsabilidades definidos
    4. Gestión por Fases
    5. Gestión por excepción
    6. Orientación a productos
    7. Adaptación al entorno del proyecto (un proyecto de PRINCE2 se debe adaptar al tamaño, el entorno, la complejidad, la importancia, la capacidad de la empresa y el riesgo del proyecto).

EXÁMENES:

Ahora vamos a hablar de los exámenes de las dos certificaciones:

  • El examen Foundation:
    • Se puede hacer on line.
    • Duración: una hora
    • Nivel de dificultad: es bastante sencillo
    • Material permitido: ninguno
    • Son 75 preguntas. Se necesitan 35 aciertos para aprobar
    • Renovación: no es necesario
  • El examen Practitioner:
    • Duración: son dos horas y media. Os aseguro que no sobra ni un minuto de tiempo. Se debe gestionar bien el tiempo para evitar sorpresas desagradables.
    • ¿Su nivel de dificultad? Pues depende, si se compara con el examen PMP de PMI  el Practitioner es mucho más sencillo pero exige dedicación y conocer los tipos de preguntas de las que se compone el examen.
    • Se basa en un escenario. Por eso es muy interesante poder realizar el examen en papel, en lugar de escoger hacerlo on line, pues es muy recomendable tener a la vista la información de cada pregunta y también del escenario propuesto.
    • Tipos de pregunta:
      • Con una respuesta correcta
      • Con múltiples respuesta y se deben escoger dos.
    • Material permitido: el manual original y oficial del año 2017: “Éxito en la gestión de proyectos con Prince2
    • Son 80 preguntas. Se deben conseguir 44 aciertos
    • Renovación: cada 5 años
    • En 48 horas ya se proporciona la nota del examen

En este sitio web puedes encontrar unos excelentes Consejos para aprobar.

CONCLUSIÓN:

Lo que me ha gustado de Prince2:

  • El enfoque basado en el Business Case. Un proyecto debe tener una justificación comercial continua.  Esto significa que la razón para iniciar el proyecto debe tener sentido desde un punto de vista empresarial y debe haber un claro retorno de la inversión. El “Business Case” se debe revisar periódicamente durante toda la vida del proyecto para comprobar su continua justificación para el negocio. Si la justificación desaparece,  el proyecto debe cerrarse.
  • La gestión por excepción. Las tolerancias a los cambios están perfectamente definidas. Esto proporciona cierta independencia al director de proyectos para tomar decisiones, siempre que se esté dentro de las tolerancias establecidas dentros de las normas de gestión del proyecto.
  • Al ser una metodología (y no un conjunto de buenas prácticas como el PMBOK) si no se dispone de experiencia en proyectos, aporta una guía y un marco para gestionar el proyecto, que es aplicable desde el primer momento. Esto es una gran ayuda para los que se inician en la gestión de proyectos, pues Price2 les va a guiar punto por punto desde el principio hasta el final del proyecto.
  • Prince2 prefiere que el Project Manager se centre en el producto/proyecto y no se implique en la realización de tareas técnicas (se separan las capas técnica y de gestión).

Lo que veo mejorable:

  • El responsable del proyecto y del éxito del mismo es la Junta del Proyecto (Directivo, Usuario Principal y Proveedor Principal) . El Project Manager es responsable de dirigir el día a día del proyecto. Puede parecer un “secretario de lujo” de la Junta de Proyecto.
  • No incluye la administración o desarrollo de los Requerimientos. Estarían incluidos dentro de la temática de “Calidad”.
  • Da por sentado que se conocen conceptos que requieren tener conocimientos previos en materia de proyectos. Por ejemplo, el WBS (Work Breakdown Structure) o el PBS (Product Breakdown Structure)

RECURSOS:

 

 

 

 

 

 

 

 

 

¿QUÉ METODOLOGÍA ELEGIR PARA GESTIONAR UN PROYECTO?

En fin… ¿Qué metodología es más adecuada para gestionar un proyecto?

La respuesta más adecuada es que ninguna es mejor que otra. Dependerá del tipo de proyecto.

El cuestionario del interesante libro “Software Engineering” de Ian Sommerville, para valorar cuándo ser ágil o cuando usar métodos formales decía que, si se responde NO a estas cuestiones en su mayoría, conviene que la metodología sea iterativa o ágil y que si se responde SÍ, entonces conviene que sea predictiva o formal:

  • ¿Se requiere una especificación?
  • ¿Los clientes son inaccesibles?project-managemet
  • ¿El sistema a construir es muy grande?
  • ¿El sistema es muy complejo?
  • ¿Se trata de un producto con mucho tiempo de vida previsto?
  • ¿Tienes herramientas de desarrollo limitadas?
  • ¿El equipo está distribuido?
  • ¿El equipo viene de una cultura de la documentación?
  • ¿El equipo tiene conocimientos técnicos limitados?
  • ¿El sistema a construir está sometido a regulación legal?

Antes de escoger una metodología, es importante tener en cuenta el ciclo de vida por el cual va a transcurrir el proyecto:

  1. Predictivo o en cascada. Aquí el proyecto discurriría por fases secuenciales (unas tareas detrás de otras). Los requerimientos son fijados al inicio. Su objetivo fundamental es controlar el coste.
  2. Iterativo. Los requerimientos son dinámicos y las tareas se repiten hasta la corrección de los prototipos. Mejorar el producto a través de sucesivos prototipos o pruebas de concepto. Su objetivo es la corrección de lo entregado.
  3. Incremental. El proyecto se basará en varios desarrollos incrementales y solo se planificaría una fase, pues las siguientes se van definiendo conforme avanzan los trabajos de la fase actual. El cliente desea frecuentes entregas de pequeños entregables del producto. Su objetivo es la velocidad de entrega.
  4. Ágiles. Son proyectos donde no se conoce el alcance y se desarrollan pequeñas porciones del proyecto marcadas por los sprints, al final de las cuales el cliente puede ver lo que se ha desarrollado. Es ideal si no se conocen los requerimientos o si se sospecha que los mismos pueden cambiar, puesto que en cada sprint se descubren requerimientos ocultos o mal interpretados. Su objetivo es entregar valor de forma frecuente a los clientes. Para estos proyectos lo ideal es usar una metodología del tipo Scrum, kanban o XP.
Características de los ciclos de vida (Fuente PMBOK 6 Ed.)

Para los proyectos que se adivinan predictivos lo mejor es usar tanto la metodología del PMBOK como Prince2.

El PMBOK no está en absoluto en contra de desarrollos incrementales, es más, el PMBOK asume que en muchas ocasiones durante la gestión del proyecto no está disponible toda la información. Es lo que se llama “Rolling Wave Planning“, es decir, es planificar en detalle lo que se va a realizar en el corto plazo. También se la conoce por “Planificación continua con incremento de detalle”.

La cuestión del enfoque que se debe utilizar es importante y ha sido abordada por el PMI y por la Agile Alliance. En el libro “Guia Práctica de Ágil“, mencionado en este blog, en su apéndice X3 existe un interesante “Filtro de Idoneidad” que se puede utilizar para determinar en base a unas preguntas qué ciclo de vida es el más adecuado utilizar.  La clasificación se basa en tres categorías principales:

  • Cultura (con los factores aceptación, confianza y toma de decisiones)
  • Equipo (tamaño, experiencia, acceso)
  • Proyecto (cambios, criticidad y entrega)

En el excelente Blog de Sinnaps comentan con buen criterio que las metodologías ágiles potencian conversaciones directas frente a la comunicación basada en documentación escrita, los equipos de trabajo se auto-gestionan, dando libertad a los roles, según las necesidades de un proyecto que está en continua evolución. Además, su empleo supuso la optimización de sus recursos, al clasificar las tareas que tienen un mayor impacto en el proyecto, estableciendo un sistema de prioridades.

Sin embargo, este tipo de metodologías y herramientas de gestión no son aconsejables para proyectos en los que se precisa de una constante toma de decisiones técnicas por parte del Project Manager, donde la gestión de la incertidumbre ha de ser clave para enfrentarse a contratiempos de proyectos largos. Por eso, no todas las empresas han recibido con el mismo entusiasmo la llegada de metodologías ágiles. Y es que su uso requiere una fuerte dependencia y centralización del control continuo y toma de decisiones de la persona responsable del proyecto. Además, podría existir una falta de documentación importante del propio proyecto y las soluciones para etapas largas suelen ser, en la mayoría de las ocasiones, inadecuadas.

En este enlace, recomiendan hacerse cuatro preguntas antes de seleccionar una metodología para gestionar un proyecto

Las cuatro preguntas antes de seleccionar una metodología:

  • …¿Qué resultados debería obtener al finalizar el proyecto? Ejercicio de objetivos.
  • …¿Qué tipo de metodologías nos ha dado mejores resultados? Ejercicio de análisis.
  • …¿Cómo funciona mejor nuestro equipo de trabajo? Ejercicio de análisis.
  • ….¿Qué metodología combina mejor con las dos preguntas anteriores? Ejercicio de estudio e identificación.

Muy interesante es la visión de Juan Palacio, en su libro gratuito descargable aquí: Flexibilidad con Scrum. En el mismo se comenta que la gestión predictiva equivale a la persona que decide irse de viaje y planifica con exactitud que ciudades, vuelos y hoteles va a visitar o reservar. Por otra parte, la gestión ágil corresponde a project-manager-1una persona que sabe que quiere conocer un país y que empezará la visita por la capital, pero deja la decisión de que ruta seguir para cuando haya llegado.

No se trata de elegir un modelo como el mejor, simplemente habrá casos en los que convendrá una gestión predictiva (por ejemplo la construcción de un puente) y otros en los que la opción ágil puede ser más beneficiosa (p.ej. desarrollo de software). El software es mucho más maleable, adaptable y fácil de reconstruir. Sin embargo, en la construcción de un puente no se pueden destruir parte de los cimientos para volver a rehacer con un diseño diferente a mitad de proyecto.

Otro aspecto importante es identificar donde se encuentra el valor en el sector donde va a tener lugar el proyecto. Podemos considerar tres elementos fundamentales entre los cuales se reparte el valor:

  • Personas
  • Tecnología
  • Procesos

La gestión predictiva tiende a valorar más los procesos (p.ej. planes preestablecidos, modelos de comunicación y autorización estrictos, etc.), mientras que la gestión ágil da una mayor importancia a las personas (p.ej. dando libertad, confianza y autonomía al equipo, potenciando la motivación, participación y creatividad, etc.)

Es importante remarcar que una práctica que ha cobrado mucha fuerza por los buenos resultados que proporciona es la de utilizar un sistema mixto  gestionando el proyecto siguiendo las directrices del PMBOK pero usar otra metodología para gestionar partes específicas del proyecto. Un buen ejemplo de esto sería utilizar una metodología ágil exclusivamente para la parte correspondiente al desarrollo de software (si lo hubiere).

Además, PMBOK llega donde Agile no llega (ni quiere llegar) como es la gestión de las diez áreas de conocimiento  definidas para cada proyecto (interesados, integración , tiempo, costes, adquisiciones, calidad, etc).

De esta forma, el proyecto tiene un Project Manager que se ocupa de la gestión de todo el proyecto y un Scrum Master y un Product Owner que trabajan exclusivamente la parte de desarrollo de software a través de ciertas iteraciones acordadas.

Las ventajas de este sistema mixto son grandes, como es el poder controlar tanto el trabajo interno como el trabajo que está siendo gestionado externamente (por ejemplo, por proveedores). Además, se trata de evitar uno de los grandes riesgos de las metodologías ágiles como es la escalabilidad.

Resumiendo, no es necesario utilizar una sola aproximación para todo el proyecto. Los proyectos frecuentemente pueden combinar elementos de diferentes ciclos de vida para obtener sus ventajas. Una combinación de las aproximaciones predictivas, iterativas, incrementales o ágiles es lo que se llama un “sistema híbrido“.

Lo que nadie debería hacer es utilizar exclusivamente una sola metodología para gestionar todos sus proyectos. Lo más adecuado es estudiar primero las características inherentes al futuro proyecto para encontrar el ciclo de vida que mejor encaje.

Por último, hay que destacar que Google deja libertad a sus Project o Product Managers para escoger la metodología que por las características del proyecto puede ayudar a tener éxito en el mismo.