Categoría: Agilidad

MANUAL PARA LA DIRECCIÓN DE PROYECTOS

Título original: Manual para la Dirección de Proyectos

Autor: Antonio Nieto Rodríguez

Editorial: Profit Editorial

Idioma: español

ISBN: ‎978-8419212535

Páginas: 336

Palabras clave: Proyectos, metodologías de gestión, metodologías, libros, lecturas

INTRODUCCIÓN

Bajo la idea de que es “todo lo que necesitas saber para definir, dirigir y patrocinar proyectos de éxito”, no estamos ante un libro técnico solo para Project Managers, sino que está dirigido a todos los que participan de una forma u otra en un proyecto y enfocado a determinar lo que funciona para tener éxito y lo que no, en base a la experiencia de autor, Antonio Nieto Rodríguez.

Antonio nos explica que la economía global desde la pandemia de Covid-19 se ha convertido en una economía de proyectos, que busca crear cambios positivos para las empresas y para el mundo. Recordemos la diferencia entre operaciones y proyectos. La mejora continua típica de las operaciones no proporciona cambios disruptivos a las empresas, como sí lo hacen los proyectos. La productividad mundial se estancó porque los métodos de mejora de la eficiencia no generan grandes cambios, como sí lo hacen los proyectos. Por esto, la proyectificación del trabajo ha hecho que la gestión de proyectos no haya dejado de aumentar desde el año 2010 y no va a hacer más que acelerarse.

Muchas empresas dejarán de tener descripciones de roles en la empresa y pasarán a tener descripción de roles en proyectos. Las personas no se definirán por el departamento al que pertenecen sino por los proyectos en los que trabajan. La conclusión es que todos nos convertiremos, nos guste o no, en líderes de proyectos.

Es por eso por lo que el libro está dirigido a todos los stakeholders, interesados e implicados en los proyectos, no solo a los Project Managers, pues que los proyectos tengan éxito y cumplan sus objetivos es responsabilidad de todos.

PRIMERA PARTE: FUNDAMENTOS DE PROYECTOS PARA TODOS

Como es sabido, las operaciones hacen funcionar a la organización, pero los proyectos son los que cambian la organización. Y esto hace que la ambidestreza organizativa, es decir la capacidad de la empresa de explotar sus capacidades actuales y explorar nuevas competencias sea fundamental para que las organizaciones puedan sobrevivir en el mundo actual. La capacidad de hacer funcionar la organización depende del Departamento de Operaciones, en cambio, la capacidad de cambiar la organización es una competencia de los proyectos. El equilibro entre estos dos puntos es un gran reto.

En los siglos pasados, se primaron la eficiencia y la reducción de costes a través de las Operaciones, pero en el siglo presente y en el futuro, el mundo cambiará impulsado por los proyectos.

Antes de la pandemia, los proyectos tenían mala fama dentro de las organizaciones, era algo que se hacía junto con el trabajo habitual y la mayoría de los trabajadores lo veían como un esfuerzo extra que no estaba ni valorado ni renumerado adecuadamente. Todo esto cambió durante la pandemia, la situación exigió que proyectos que solían durar decenas de años (por ejemplo, el desarrollo de vacunas) se tuvieran que terminar en menos de un año. Y lo mismo sucedió en el sector de la construcción, de emplearse varios años para construir un hospital se pasó que tener que desarrollarlo en menos de seis meses. Una broma común en España en el año 2020 es que el Covid-19 había hecho más por la transformación digital de las empresas e instituciones que la mayoría de los CIO’S a cargo de los departamentos TIC de estas. Verdad verdadera.

El libro describe las definiciones básicas de la gestión de proyectos: qué es un proyecto, una operación, un programa, una PMO y los tipos de proyectos que existen. Además, habla de la gestión de proyectos y los diferentes métodos de gestión (en cascada o predictivos híbridos o agiles, ya adaptativos o iterativos) y cuando es adecuado utilizar cada uno de ellos, según las características de cada proyecto.

El autor del libro pide simplificar el complejo mundo de la gestión de los proyectos, poniendo un poco de sentido común, evitando el lenguaje demasiado técnico para acercarlo a todo el mundo y adecuándolo a los tiempos modernos.

SEGUNDA PARTE: EL PROJECT CANVAS

Esta parte referida al Project Canvas es muy interesante, pues Antonio Nieto tiene el objetivo en mente de hacer visibles los problemas más importantes que sufren los proyectos, que son, por ejemplo:

  • La ausencia de los sponsors de los proyectos
  • La ausencia de beneficios al final del proyecto
  • La ausencia de un equipo que pueda gestionar el proyecto

El Project Charter es una forma muy visual de comunicar y hacer públicos los puntos que se suelen revisar cuando se elabora el documento del “Acta de Constitución”, al inicio del proyecto, según dicta el PMBOK V6 del PMI. Antonio se enfrentó al reto de enseñar gestión de proyectos a grupos de ejecutivos y profesionales que no eran gestores de proyectos y que no tenían ningún conocimiento sobre la materia. Para hacer más sencillo el aprendizaje tomó prestada la idea del “Business Model  Canvas” desarrollada por Alex Osterwalder e Ives Pigneur y lo adaptó para poder enseñar sobre los elementos clave de un proyecto.

Los puntos tratados dentro del Project Canvas son los siguientes:

  • Dominio de los Cimientos:
    • Propósito. Por qué vamos a hacer el proyecto.
    • Inversión. Cuánto costará el proyecto.
    • Beneficios. Qué beneficios e impacto generará el proyecto y cómo sabremos que tiene éxito.
  • Dominio de las Personas:
    • Patrocinio. Quién es el responsable del proyecto.
    • Recursos. Quién gestionará el proyecto y qué competencias se necesitan para llevarlo a cabo.
    • Partes interesadas. Quienes se beneficiarán y se verán afectados por el proyecto.
  • Dominio de la Creación:
    • Entregables. Qué es lo que el proyecto producirá, construirá o entregará.
    • Plan. Como y cuando se realizará el trabajo.
    • Cambio. Como vamos a involucrar a las partes interesadas y a gestionar los riesgos

Este enfoque es un gran acierto y aquí se nota que Antonio analizó en profundidad las causas principales por las cuales los proyectos fracasan, pues muchas veces los proyecto no son exitosos porque algunos o varios de estos puntos no están lo suficientemente claros y no se trabaja sobre ellos.

Para facilitar la definición de cada uno de estos puntos, el autor propone una serie de herramientas y técnicas para poder determinarlos y solucionarlos con claridad. Creo que esta es la parte más útil y aprovechable del libro. Solo con esta parte (que consta de unas 180 páginas) el coste del libro ya estaría muy bien amortizado.

Incorpora el libro un ejemplo de cumplimentación de los diferentes puntos que componen el Project Canvas y un análisis para determinar si está correctamente o no completado cada apartado. El objetivo es comprobar que las características clave y los impulsores clave del proyecto se han definido adecuadamente y comunicado correctamente.

En mi experiencia profesional, muchas veces encontré problemas con sponsors que eran nombrados solo por el hecho de ser directores de departamento y que no estaban de algún modo involucrados en la gestión de los proyectos a los que habían sido asignados y mucho menos implicados. En un caso en concreto, recuerdo que un patrocinador cumplimentó una hoja Excel de solicitud de proyecto y comentó al Departamento de Proyectos que se marchaba un mes de vacaciones de verano y que esperaba que a su vuelta el proyecto estuviera ya desarrollado y perfectamente finalizado.

TERCERA PARTE: COMPETENCIAS INDIVIDUALES Y ORGANIZATIVAS DE LOS PROYECTOS

Esta tercera parte del libro examina las competencias necesarias para convertirse en un gestor o patrocinador de proyectos eficaz y se divide en tres apartados:

  • Liderazgo de proyectos
  • Seleccionar y priorizar proyectos
  • La organización ágil y orientada a proyectos

Dentro del punto referido al liderazgo de proyectos Antonio remarcó la diferencia entre un gestor de proyectos frente a un líder de proyectos que es quien siendo gestor o patrocinador de proyectos eficaces muestra cualidades de liderazgo.

Las cualidades o competencias del liderazgo de proyectos son las siguientes:

  1. Conocimientos técnicos de gestión de proyectos. Para ser eficaces, los patrocinadores, los ejecutivos y los altos cargos deben conocer los aspectos esenciales de los proyectos y de la gestión de estos.
  2. Desarrollo de productos y experiencia en el sector. Tanto os gestores como los patrocinadores deben tener conocimientos de desarrollo de producto y experiencia para dirigir proyectos de alto impacto.
  3. Estrategia y visión empresarial. Un gestor de proyectos debe conocer bien la organización, sus estrategias, sus principales competidores y el entorno en el que se ejecutará el proyecto.
  4. Capacidad de liderazgo y gestión del cambio. Los gestores y los patrocinadores deben desarrollar un fuerte liderazgo y solidas capacidades de gestión del cambio.
  5. Agilidad y adaptabilidad. En el mundo actual, los gestores de proyecto deben sentirse cómodos trabajando en situaciones de mucha incertidumbre.
  6. Ética y valores. Los profesionales de la gestión de proyectos se rigen por altos estándares éticos par que las decisiones y acciones sean siempre honestas.
  7. Actitud. Además de las seis competencias anteriores, es esencial una buena actitud.

Respecto al punto de seleccionar y priorizar proyectos, las organizaciones necesitan priorizar hoy los recursos, especialmente los escasos recursos de tiempo, dinero, gestión y atención de los empleados. Esto les permite equilibrar sus proyectos. Hoy una priorización eficaz establece la agenda de las organizaciones y refleja su estrategia a corto y largo plazo. La priorización aumenta la tasa de éxito de los proyectos más estratégicos de una organización y aumenta la alineación y el enfoque de los equipos de alta dirección en torno a los objetivos estratégicos.

Hoy cada organización debe desarrollar un marco de gestión de carteras que se adapte a sus necesidades. No obstante, ese marco debe de incluir obligatoriamente ciertos elementos:

  1. Una junta de supervisión, selección y priorización de proyectos
  2. La recopilación y el análisis estructurados y coherentes de nuevas ideas de proyectos
  3. Un método para priorizar y seleccionar nuevas ideas de proyectos
  4. Una hoja de ruta estratégica
  5. Un ciclo de vida con puertas de financiación
  6. Un método para supervisar la ejecución de la hoja de ruta estratégica
  7. Vínculos con el ciclo presupuestario y gestión de riesgo empresarial
  8. Seguimiento de los beneficios

Por último, acerca de la organización ágil y orientada a proyectos, Antonio Nieto menciona en el libro que la estructura, la cultura y la forma de trabajar de tu organización influirán en el éxito de tus proyectos. Las organizaciones tradicionales y verticalistas tendrán dificultades en la Nueva Economía de Proyectos.

El autor menciona los ocho desafíos más comunes en la implementación de proyectos desde una perspectiva cultural organizativa y de procesos de trabajo y cómo tú y tu equipo de liderazgo podéis superarlos:

  1. Escasa responsabilidad por parte de los altos cargos e inadecuada gobernanza. Aquí hablo desde la experiencia personal, es fundamental que cada ejecutivo y promotor sean responsables del proyecto asignado y que también sea responsable de la entrega de los beneficios planeados de su proyecto.
  2. Laxitud y falta de enfoque. Este problema debe evitarse teniendo claras las prioridades de la organización.
  3. Bajo compromiso de los empleados. Esto debería solucionarse comunicando cual es el objetivo de cada uno de los proyectos para que todos los empleados se sientan involucrados y comprometidos.
  4. Organizaciones decisivamente jerárquicas y basadas en silos. Todos conocemos organizaciones de tipo funcional, matricial y basadas en proyectos. Las organizaciones deben ser más planas y los proyectos estratégicos deberian de tener cierta autonomía para ser gestionados.
  5. Una oficina de gestión de proyectos que no es estratégica ni se hace responsable. Las PMO generadoras de documentación no valen para nada y terminan siendo canceladas, las PMO deben generar valor y deben implementar las estrategias que marque la organización. Es la única forma en la que generan verdadero valor a la organización que las soporta y se hacen útiles.
  6. Métodos inadecuados ejecución de proyectos y competencias. Es hora de ampliar y diversificar las herramientas de gestión de proyectos y de ampliar el enfoque con métodos predictivos, agiles y otros.
  7. Un modelo financiero que no refleja los costes y beneficios del proyecto. Los proyectos parecen estar fuera del presupuesto anual de las organizaciones. Esta situación debe resolverse incorporando las inversiones en proyectos al ciclo presupuestario y poniendo foco en los beneficios de cada proyecto.
  8. Inadecuación de los sistemas y herramientas de seguimiento de la ejecución de los proyectos. Hay que aprovechar la tecnología para hacer el seguimiento y control de los proyectos, es decir, no vale con tenerlo todo en decenas de hojas Excel, lo mismo que Microsoft Project ha quedado ampliamente superado como herramienta de gestión y seguimiento de proyectos. El valor que proporciona un Project Manager no es hacer un seguimiento administrativo de la documentación del proyecto sino dialogar con el equipo, entrenando a las personas y cultivando una cultura de alto rendimiento, manteniendo conversaciones periódicas con las principales partes interesadas.

CUARTA PARTE: UN FUTURO MEJOR A TRAVÉS DE LOS PROYECTOS

En este capítulo se trata el tema de cómo la gestión de los proyectos se cruza con cuatro grandes tendencias globales que están afectando a todas las organizaciones del mundo:

  1. La gestión de crisis es gestión de proyectos. Ya vimos lo que la crisis del Covid-19 nos enseñó cerca de los proyectos. En el futuro deberemos estar preparados para gestionar una serie continua de crisis, pues la crisis del Covid-19 seguramente no va a ser la última crisis global a la que nos enfrentemos (el cambio climático, por ejemplo, ya genera desafíos importantes)
  2. La diversidad (y la variedad de pensamiento) y el éxito de los proyectos. Hoy en día hoy en día ya nadie duda de la importancia de la diversidad cada vez más organizaciones reconocen que la diversidad e inclusión y la equidad son cuestiones éticas que no se pueden ignorar para los líderes de proyectos promueve la variedad de sus equipos es una responsabilidad profesional esencial también hay beneficios empresariales asociados a la práctica eficaz de la diversidad y la igualdad. En el futuro veremos que la diversidad de los proyectos conduce a la diversidad de la organización, pues todos los proyectos exitosos implican cambio. Por último, muchas voces sostienen que los grandes proyectos públicos son motores de cambio y mejora social.
  3. El papel de la tecnología. En el presente estamos viendo una falta de soluciones tecnológica dirigidos a la buena gestión de los proyectos. En el futuro hay que determinar qué es lo que la inteligencia artificial y otras tecnologías van a alterar y mejorar en materia de gestión de proyectos.
  4. La revolución de la sostenibilidad. La revolución de la sostenibilidad es otra transformación a gran escala que se llevará a cabo mediante proyectos exitosos y una gestión eficaz de los mismos. Actualmente y ya en las próximas décadas, los gestores de proyectos y los patrocinadores ejecutivos serán los principales responsables interesados en la noción de prácticas procesos y resultados sostenibles. En el futuro la gestión de sostenible de los proyectos va a ser un punto absolutamente obligatorio. No hay que perderlo de vista.

En conclusión, se trata de un libro diferente a los típicos libros de gestión de proyectos, muy recomendable, que tiene varias lecturas y que está orientado a varios públicos. Está dirigido a Project Managers experimentados, que se darán cuenta de lo que suele fallar en los proyectos por falta de comunicación y de preparación de ciertos puntos señalados en el Project Canvas y que hacer para solucionarlo. Y también está dirigido al resto de las personas implicadas en los proyectos (patrocinadores o sponsors, ejecutivos, técnicos, etc) que no conocen las metodologías de los proyectos pero que están de una forma y otra implicados en los mismos y que ese libro les explica (como no expertos) de forma clara y sencilla los puntos esenciales que se deben aclarar y completar para tener éxito en los proyectos, que es el objetivo final del autor del libro.

 

CERTIFICACIÓN AGILE HYBRID PROJECT PRO

Consciente de la importancia que está teniendo últimamente en materia de proyectos el movimiento de mezclar elementos de las metodologías predictivas o waterfall, agile, Six Sigma y otras, el PMI ha lanzado una nueva certificación orientada a cubrir esta necesidad formativa.

La micro-credencial ágil / híbrida se alinea con la Guía para el cuerpo de conocimiento de la gestión de proyectos, la Guía del PMBOK, (que ya está en su versión 7) y que es el estándar global preeminente para la gestión de proyectos y que proporciona las prácticas fundamentales de la profesión.

Según el PMI “Los poseedores de la certificación Agile Hybrid Project Pro Micro-Credential han demostrado su amplio conocimiento de conceptos, tareas y técnicas de gestión de proyectos ágiles / híbridos que son aplicables en prácticamente cualquier industria. Los poseedores pueden hablar y comprender el lenguaje global de la gestión de proyectos ágiles / híbridos. Los poseedores han demostrado el conocimiento y las habilidades necesarias para gestionar los planes, el alcance, las partes interesadas, los riesgos, los presupuestos, el cumplimiento, los recursos, la resolución de problemas y la entrega de valor del proyecto.”

La certificación  Project Pro Micro-Credential se está introduciendo para ayudar a los gerentes de proyectos tradicionales, titulares de la certificación PMP existentes, gerentes de proyectos con conocimientos ágiles / híbridos y / o experiencia, para alinearse con los últimos estándares de la industria.

Y es que, como ya vimos en la entrada correspondiente a la certificación Google de Project Management, es ya un hecho que, en lugar de seguir una sola metodología para la gestión de un proyecto, lo más adecuado es estudiar tanto las características del proyecto como las peculiaridades de la empresa y decidir qué es lo más adecuado para lograr el éxito.

Se trata de un movimiento imparable que se ha convertido en tendencia. Mal que le pese a los apóstoles del agilismo o del waterfall puros, muchos responsables de proyectos se han dado cuenta, a través de la experiencia, de que el éxito de un proyecto depende mucho de la cultura de la empresa y que el uso de prácticas o artefactos de las diferentes metodologías puede ayudar enormemente a llevar a buen fin un proyecto.

Ya nadie duda que las daylies que provienen del agilismo ayudan mucho a mejorar la comunicación del equipo y fomentan la transparencia.  Y lo mismo ocurre con las “Retrospectivas“, que proporcionan un feedback excelente acerca de lo que ha sucedido en una fase, iteración o proyecto. Por otra parte, el Business Case de la metodología Prince2 se ha demostrado que proporciona claridad en la definición de los objetivos del proyecto y la búsqueda de rentabilidad o de valor añadido. Es un hecho que muchos proyectos hacen un kickoff para iniciar sus proyectos y completan un Project Charter para definir lo que el proyecto debe cumplir.

A continuación, muestro un resumen de algunos de los enfoques de gestión de proyectos que pueden componer el enfoque híbrido:

  • Predictiva o Waterfall es una metodología tradicional en la que las tareas y fases se completan de manera lineal y secuencial, y cada etapa del proyecto debe completarse antes de que comience la siguiente. El Project Manager es responsable de priorizar y asignar tareas a los miembros del equipo. En el enfoque predictivo, los criterios utilizados para medir la calidad están claramente definidos al inicio del proyecto. Es ideal para proyectos en los que los requisitos están claros desde el principio (lo que no suele ser muy normal).
  • Agile implica fases cortas de trabajo colaborativo e iterativo con pruebas frecuentes y mejoras implementadas regularmente. Algunas fases y tareas ocurren al mismo tiempo que otras. En los proyectos ágiles, los equipos comparten la responsabilidad de gestionar su propio trabajo. Scrum y Kanban son ejemplos de marcos ágiles, que son enfoques de desarrollo específicos basados ​​en la filosofía Agile.
  • Scrum es un marco ágil que se enfoca en desarrollar, entregar y mantener proyectos y productos complejos a través de la colaboración, la responsabilidad y un proceso iterativo. El trabajo lo completan equipos pequeños y multifuncionales dirigidos por un Scrum Master y un Product Owner  y se divide en Sprints cortos con una lista seleccionada de entregables.
  • Kanban es tanto un enfoque ágil como una herramienta que proporciona retroalimentación visual sobre el estado del trabajo en progreso mediante el uso de tablas o gráficos Kanban. Con Kanban, los gerentes de proyecto usan notas adhesivas o tarjetas de notas en un tablero Kanban físico o digital para representar las tareas del equipo con categorías como “Por hacer”, “En progreso” y “Listo”.
  • Prince2 es una metodología de gestión de proyectos que se plantea sean realizados entre otras actividades considerando 7 temas: la Calidad, el Cambio, la estructura de roles del proyecto (Organización), los planes (Cuánto, Cómo, Cuando), el Riesgo y el Progreso del proyecto, justificado por un Business Case (o necesidad del negocio) que es la que evidencia la realización de ese proyecto.
  • Lean utiliza la herramienta de calidad 5S (clasificar, ordenar, limpiar, estandarizar, disciplina) para eliminar ocho áreas de desperdicio, ahorrar dinero, mejorar la calidad y agilizar los procesos. Los principios de Lean establecen que puede hacer más con menos al abordar las disfunciones que generan desperdicio. Lean implementa un sistema de programación Kanban para administrar la producción.
  • Six Sigma implica reducir las variaciones asegurando que los procesos de calidad se sigan en todo momento. El método Six Sigma sigue un enfoque de mejora de procesos llamado DMAIC, que significa definir, medir, analizar, mejorar y controlar.
  • Lean Six Sigma es una combinación de enfoques Lean y Six Sigma. A menudo se utiliza en proyectos que tienen como objetivo ahorrar dinero, mejorar la calidad y avanzar rápidamente en los procesos. Lean Six Sigma también es ideal para resolver problemas complejos o de alto riesgo. La herramienta de calidad 5S, el proceso DMAIC y el uso de tableros Kanban son todos componentes de este enfoque.

El examen de certificación se basa en la aplicación de los siguientes principios y conceptos: 

  • Manejar conflictos y liderar un equipo
  • Apoyar el desempeño del equipo, empoderar a los miembros del equipo y a las partes interesadas
  • Abordar y eliminar impedimentos, obstáculos y bloqueos para el equipo
  • Colaborar con las partes interesadas e involucrar a las partes interesadas
  • Desarrollar un entendimiento compartido, involucrar y apoyar a equipos virtuales
  • Ejecute el proyecto con la urgencia necesaria para ofrecer valor empresarial
  • Gestionar comunicaciones, evaluar y gestionar riesgos
  • Planificar y administrar el presupuesto, el cronograma, la calidad de los productos / entregables, el alcance, los cambios y los problemas del proyecto
  • Planificar y gestionar el cumplimiento del proyecto
  • Evaluar y entregar los beneficios y el valor del proyecto

Los dominios en  los que se basa el examen son los siguientes:

  1. People,
  2. Process
  3. Business Environement.

La siguiente tabla identifica la proporción de preguntas de cada dominio que aparecerán en el examen:

Por último comentar que el examen de certificación se puede realizar “on line” en modo “unproctored” y consta de 60 preguntas, que se deben completar en 75 minutos. Superar el examen proporciona 13 PDUs válidos para el mantenimiento de los poseedores de la certificación PMP.

Más información:

INICIACIÓN A KANBAN (II) – ENTENDER EL SISTEMA

Dejar un comentario

INTRODUCCIÓN

Tras el primer post donde os enseñé los conceptos básicos y la filosofía de Kanban, en este vamos a introducir algunos conceptos ya aplicados al trabajo diario y a entender como funciona un sistema Kanban. Vamos a focalizarnos en ver como trabajar con los famosos tableros Kanban, ver que significa cada elemento del tablero y una pequeña introducción a las métricas, donde veremos dos métricas muy sencillas y dos tipo de gráficas muy simples que nos permitirán hacernos una idea de las posibilidades que vamos a poder obtener.

Representación del “trabajo en curso” (WIP)

  • En primer lugar, cuando hablamos de “Kanbans”, estamos hablando de “huecos” que hay en un determinado espacio. Si trasladamos esto a un panel, donde tenemos identificadas las columnas como los diferentes estados en los que pasa una tarea, podemos decir que en nuestro sistema, en cada estado, tenemos una cantidad limitada de trabajo que podemos hacer, definido por los kanbans que tengo en cada estado. Es muy común confundir los tickets con “kanbans”, pero realmente los tickets son tareas y los kanbans son los huecos que hay para hacer estas tareas. Un hueco vacío en el panel esta emitiendo una señal “pull” para que se traiga una tarea desde el estado anterior.

  • Esta forma de mostrar la capacidad de trabajo por cada estado en forma de huecos resulta engorrosa, por lo que la forma de representar la capacidad de cada estado e incluyendo un número con la capacidad encima de cada columna. Esta capacidad es un concepto fundamental de Kanban y es el “Work In Progress” (WIP) y define los número de tickets que pueden estar a la vez en un determinado estado. En el próximo post veremos un poco más en detalle este concepto y porque debemos de tener este valor lo más bajo posible para que el trabajo fluya lo más rápido posible. Si indicamos un símbolo de infinito o un “-“, significa que no hay WIP en esas columnas.

 

Sistemas push vs sistemas pull

  • Kanban es un sistema basado en “pull”. Esto quiere decir que busca la máxima eficiencia y optimización, adaptando en tiempo real la producción a la demanda.  Mediante este sistema, sólo producimos los que sabemos que vamos a realizar. En un sistema de fabricación, no tendría un stock o tendría un stock mínimo y solo fabricaría aquellos pedidos que ya tengo confirmados (Just-In-Time). En este caso, solo voy cogiendo tickets cuando tengo huecos, de forma que el trabajo fluya más rápido.
  • Un sistema “push” consistiría en coger muchos tickets e ir pasándolos de estado a estado, de forma que pueda asegurarme que tengo tickets suficientes en el siguiente estado (tengo stock suficiente para abastecer a la siguiente fase). Esta forma de trabajar nos rompería completamente la filosofía Kanban, ya que no tendría un WIP limitado y el tiempo de finalización de cada tarea se ralentizaría.

 

Compromiso diferido y políticas

  • El compromiso sobre cuando vamos a hacer algo se retrasa (lo diferimos) hasta el punto de compromiso. En ese momento, ya podemos comprometernos a un determinado tiempo si sabemos como se comporta nuestro sistema Kanban.
  • Hasta que llegamos a ese punto de compromiso, las diferentes ideas que se tienen son opciones para realizar tareas, que deben de ser priorizadas (en Kanban se llama Upstream y en siguientes post hablaremos más en detalle de ello). Una vez se ha priorizado la idea, se pasa a un estado en el que empezamos a contar y del que no podemos tirar hacía atrás. Una vez pasamos al estado de compromiso, la tarea tiene que finalizarse o cancelarse (habría que evitar siempre la cancelación ya que suponemos que ha pasado todo los filtros necesarios para asegurarnos que hay que realizar dicha tarea)
  • Uno de los principios de Kanban es hacer las políticas explícitas. Podemos ayudarnos de esto en los paneles indicando las políticas que tenemos que aplicar en cada uno de los estados. Por ejemplo, las entregas listas, por política, siempre se grabará en un determinado registro, se almacenará en una determinada base de datos, etc. Otro ejemplo podría ser que para las pruebas de usuario solo tendremos 15 días, etc., pero si podemos indicarlas en el panel, será transparente para todo el mundo.

Trabajo por lotes

  • Kanban también permite el trabajo por lotes (push). Estos se suele utilizar cuando realizamos tareas de priorización periódicas donde indicamos las tareas que están listas para desarrollarse. Por ejemplo, cada dos semanas se traspasa una carga de trabajo a la columna de listo con las tareas que ya están aprobadas para realizar. Es importante señalar que cuanto más largo en el tiempo sea esta carga de tareas, menos flexibilidad tendrá el sistema (ver el punto de replanificaciones y entregas frecuentes)

 

Descartes

  • Es importante tener en cuenta que debemos descartar ideas. Las ideas son opciones que tenemos para elegir y tenemos que seleccionar la que más valor aporta a la compañía. Si descartamos muchas y hacemos pocas, quiere decir que nuestra capacidad no es la adecuada ya que hay muchas necesidades pero poca capacidad. Un ratio muy bajo de descartes quieres decir que hacemos prácticamente todo lo que pedimos, sean ideas buenas o tal vez ideas que no aporten el beneficio esperado. Hay que tener en cuenta que el futuro es incierto, no sabemos si una idea va a acabar teniendo éxito o no. Un ratio equilibrado sería un 50% de descartes.

Replanificaciones y entregas frecuentes

  • Esta característica es una de las principales diferencias con respecto a Scrum. Mientras que en Scrum, tenemos un Sprint donde no se puede replanificar nada y no se entrega nada hasta el final del Sprint (normalmente 15 días), en Kanban tenemos más flexibilidad para gestionar las replanificaciones y las entregas. Lo ideal sería replanificar a demanda, es decir, en cuanto el sistema requiera una tarea, que en ese momento se pueda evaluar que tarea realizar y seleccionarla (planificación a demanda). Una mala idea es hacer una planificación a largo plazo (por ejemplo mensual) ya que en determinados sistemas, siempre surgen necesidades no planificadas que hacer que no se pueda cumplir dicha planificación. Kanban recomienda realizar reuniones de planificación semanales, para adecuar las tareas a las necesidades actuales.
  • El mismo criterio se aplica a las entregas. Si podemos realizar una entrega lo más rápido posible, antes se podrá aportar valor a la compañía. Una entrega a demanda es lo más ágil, aunque esto también tiene un coste, ya que no es lo mismo hacer 10 entregas en 10 días distintos que hacer una entrega un día de 10 tareas.
  • El concepto de agilidad consisten en entregar el trabajo correcto en el tiempo correcto, ni antes ni después.

Compromisos de entrega

  • Los compromisos de entrega se pueden retrasar hasta una fase posterior. Muchas veces, sobre todo si durante el proceso tenemos factores externos al sistema que no controlamos, no podremos tener un compromiso de entrega fiable. Por poner un ejemplo, en equipo de desarrollo de Software que una vez termine su desarrollo y sus pruebas, necesite otro equipo que realice pruebas de usuario. En este caso, Kanban permite crear compromisos de dos fases, con lo cual podremos medir el tiempo de nuestro sistema y su eficiencia por fases.

Métricas

En este punto vamos a ver dos tipos de métricas muy sencillas que podemos obtener de nuestro sistema, además de dos tipos de gráficas para medir, por ejemplo, las dos métricas que vamos a ver y poder estudiarlas.

Tiempo de espera del sistema y del cliente e Histogramas

  • Las primeras métricas que vamos a tener son los tiempos de espera del sistema y tiempo de espera del cliente. Mediante estas métricas, vamos a poder medir la velocidad de nuestro flujo de trabajo. Muy utilizadas para poder definir SLAs (acuerdos de niveles de servicio)
  • Tiempo de espera del sistema: Es el tiempo que transcurre desde que pasa el punto de compromiso hasta que pasa al primer estado con un WIP infinito. Con esto, podemos medir el tiempo que tarda una tarea desde que se empieza a trabajar en la tarea hasta que llegamos a un estado que no controlamos. Es importante avanzar que mediante el WIP de los estados vamos a poder controlar la velocidad del sistema y ajustarlo a nuestras necesidades, aunque lo veremos en el siguiente post.
  • Tiempo de espera del cliente: Es el tiempo desde el punto de compromiso hasta que ya lo tiene listo el cliente para utilizar. Con esta métrica, podemos indicar al cliente cuando tardará en tener disponible la petición.
  • Mediante un Histograma, vamos a poder visualizar de forma clara, por ejemplo, los días que tarda el cliente en tener la tarea disponible. En el siguiente ejemplo, podemos ver en primer lugar una tabla con todas las tareas realizadas y los días que hemos tardado en finalizarla. Si transformamos esta tabla desde el punto de vista de los días de espera, podemos ver la cantidad de tareas que se han realizado en unos determinados días. En este ejemplo, podemos ver que lo normal es que tardemos entre 3 y 4 días en realizar las tareas. Este estudio podemos ampliarlo añadiendo tipología de tareas para saber cuando tarda el sistema en realizar determinados tipos de tareas e ir dando aproximaciones de nuestra velocidad del flujo de trabajo.

Rendimiento y Run-Chart

  • En la métrica de rendimiento vamos a poder medir las tareas terminadas por unidad de tiempo, midiendo el ratio de tareas completadas.
  • Es una métrica muy útil para medir la productividad de un equipo. Por ejemplo, vamos a poder medir que un equipo hace, por ejemplo, 10 tareas a la semana o 30 tareas al mes y podremos ver como evoluciona el sistema.
  • Mediante un Run-Chart, podemos buscar tendencias o impactos en nuestro rendimiento. Por ejemplo, podemos incorporar nuevas acciones para mejorar nuestro sistema (mejora continua) y medir dicho impacto para saber si estamos mejorando por el contrario, estamos empeorando nuestro rendimiento.

Conclusiones

En este post hemos visto algunos conceptos claves de Kanban para poder diseñar los primeros paneles Kanban y un par de métricas muy sencillas de calcular para poder medir nuestro sistema. Recordar que no podemos mejorar lo que no medimos.

Próximo post

En el próximo post hablaremos de lo siguiente:

  • Diseño de los paneles: Algunas ideas para crear un buen panel Kanban
  • Diseño de tarjetas para ponerlas en el panel
  • La Ley de Little: Como mediante el WIP vamos a poder controlar nuestro flujo de trabajo
  • Métricas: Vamos a ver varias métricas más y entender un Diagrama Acumulativo de Flujo (CFD) para poder estudiar nuestro sistema.

 

 

INICIACIÓN A KANBAN (I) – CONCEPTOS PREVIOS

Dejar un comentario

¿Qué significa Kanban?

Si nos vamos a la definición estricta, podemos decir que Kanban es un método para definir, gestionar y mejorar servicios que entregan trabajo del conocimiento, tales como servicios profesionales, trabajos o actividades en las que interviene la creatividad y el diseño, tanto de productos de software como físicos.

Un sistema Kanban consiste realmente en una cantidad de “tarjetas señales” o “Kanbans” en circulación. Algunos ejemplos de un sistema Kanban son:

  • En el palacio imperial de Tokio, para entrar te dan un ticket para poder entrar y cuando se acaban los tickets, ya no pueden entrar hasta que sale alguien y devuelve el ticket.
  • En la atracción de feria de los famosos “coches de choque” (¡Quien no ha subido alguna vez!), hay un número limitado de coches que pueden estar circulando a la vez.  Se podría decir que es un sistema Kanban.

Imaginaros un sistema donde no se controle la cantidad de “entes” en curso. Por ejemplo, Madrid en Navidad, entrar a ciertos pubs sin control de acceso, subir al metro en hora punta….. ¿Es un sistema un poco caótico? ¿Quién esta más cerca del grupo en un concierto? ¿Quién entra antes al metro?

Pues esto pasa cada día en nuestra vida diaria y en nuestro trabajo. Vamos asumiendo tareas y más tareas mientras que no nos damos cuenta inconscientemente que tenemos una capacidad límite. Mediante un sistema Kanban, se pretende controlar la cantidad de tareas que ponemos estar haciendo a la vez, para mejorar la calidad de vida, que no se acumulen las cosas sin hacer o a medias y poder estimar cuando vas a terminar las tareas. En definitiva, adaptamos la demanda a la capacidad de producir. Seguro que a nadie le ha pasado esto, ¿verdad?.

Principios directores

Kanban tiene 3 principios directores:

  • Sostenibilidad. A nivel individual, evita sobrecarga, mejora la calidad y produce orgullo profesional y satisfacción en el cliente
  • Orientación al servicio. A nivel de gestión intermedia, se entrega valor de forma rápida, predecible y realista. Hacia un nivel superior, podremos responder a cuestiones complejas con confianza. Hacia un nivel inferior, podremos tomar decisiones difíciles con confianza
  • Supervivencia. A nivel de gestión senior: Realizar promesas que puedes cumplir y liderar el negocio, a nivel de estrategia y posicionamiento.

 

El método Kanban

El método Kanban consiste en una serie de valores y principios que rigen el sistema. En concreto, existen los valores de Kanban, los principios de entrega de servicio, los principios del cambio y las prácticas generales.

Valores Kanban

Hay un valor fundamental que engloba a todos que consiste en respetar a todos los individuos que contribuyen colaborativamente en una organización. Además, hay una serie de valores también que son necesarios para poder aplicar este método:

  • Transparencia: La creencia de que compartir información abiertamente mejora el flujo de valor de negocio. Utilizar un lenguaje claro y directo es parte del valor.
  • Equilibrio: El entendimiento de que los diferentes aspectos, puntos de vista y capacidades deben ser equilibrados para conseguir efectividad. Algunos aspectos (como demanda y capacidad) causarán colapso si no se encuentran equilibrados por un periodo prolongado.
  • Colaboración: Trabajar juntos. El Método Kanban fue formulado para mejorar la manera en que las personas trabajan juntas, por ello, la colaboración esta en su corazón.
  • Foco en el cliente: Conociendo el objetivo para el sistema. Cada sistema Kanban fluye a un punto de valor realizable — cuando los clientes reciben un elemento solicitado o servicio. Los clientes en este contexto son externos al servicio, pero pueden ser internos o externos a la organización como un todo. Los clientes y el valor que estos reciben es el foco natural en Kanban.
  • Flujo: La realización de ese trabajo es el flujo de valor, tanto si es continuo como puntual. Ver el flujo es un punto de partida esencial en el uso de Kanban.
  • Liderazgo: La habilidad de inspirar a otros a la acción a través del ejemplo, de las palabras y la reflexión. Muchas organizaciones tienen diferentes grados de jerarquía estructural, pero en Kanban, el liderazgo es necesario a todos los niveles para alcanzar la entrega de valor y la mejora.
  • Entendimiento: Principalmente conocimiento de si mismo (tanto individual como de la organización) para ir hacia adelante. Kanban es un método de mejora, por lo que conocer el punto de inicio es la base de todo.
  • Acuerdo: El compromiso de avanzar juntos hacia los objetivos, respetando — y donde sea posible, acomodando — las diferencias de opinión o aproximaciones. Esto no es gestión por consenso sino un co-compromiso dinámico para mejorar.
  • Respeto: Valorando, entendiendo y mostrando consideración por las personas. De manera apropiada al pie de esta lista se encuentra la base sobre la cual reposan el resto de valores.

Principio de entrega de servicios

¿Qué es un servicio?

Un cliente tiene una necesidad y el servicio responde a esa necesidad con una serie de actividades. El cliente acepta el resultado.

La organización es una red de servicios interdependientes con políticas que terminan su comportamiento:

  • Entiende y pon foco en las necesidades y expectativas del cliente
  • Gestiona el trabajo, deja que los trabajadores se gestionen alrededor de dicho trabajo
  • Revisa regularmente la red y sus políticas para mejorar los resultados

 

Principio de gestión del cambio

  1. Empieza por lo que haces
    1. Entiende los procesos actuales
    2. Respecta los roles actuales, responsabilidades y puestos
  2. Acordar en buscar mejoras a través del cambio evolutivo
  3. Fomentar el liderazgo en todos los niveles de la organización

El método Kanban usa ….

… tableros Kanban para visualizar el trabajo invisible, los flujos y los riesgos del negocio junto con sistemas Kanban para limitar el trabajo en curso.

El método Kanban entrega ….

… velocidad, entrega de servicios más predecibles y capacidades de adaptación que permite que puedas responder eficientemente a los cambios en las demandas de los clientes o de tu entorno de negocio.

Prácticas Generales

Visualizar:

  • Ver el trabajo y su flujo
  • Visualiza los riesgos
  • Construye un modelo visual que refleje tu trabajo

Limitar el WIP:

  • Para de empezar y empieza a terminar
  • De izquierda a derecha
  • Limita el trabajo a la capacidad

Gestionar el flujo de trabajo:

  • Flujo es el movimiento del trabajo
  • Gestiona el flujo de forma suave y predecible
  • Usa datos

Hacer explícitas las políticas:

  • Haced visibles las políticas a todos
  • Clases de servicio, límite WIP, criterio de siguiente tarea, dependencias, gestión de bloqueos …

Circuitos de retroalimentación:

  • Establecimiento de circuitos de retroalimentación mediante cadencias (reuniones periódicas)
  • Rapidez en la colaboración, aprendizaje y mejoras
  • Conducción por datos

Mejorar & evolucionar:

  • Usa el método científico
  • Cambio guiado por las hipótesis
  • Ejecuta experimentos seguros ante fallos

 

Conclusiones

  • “Kanbaniza” tus procesos existentes. No es necesario un cambio brusco. Empieza con los procesos que tienes y como funcionan ahora y verás como poco a poco vas cambiando cosas y detectando mejoras en tus procesos que hacen que sean más óptimos.
  • Provoca cambios para mejorar los procesos existentes. No tengas miedo a equivocarte. Todos nos equivocamos pero si no eres valiente e intentas provocar cambios, nunca podrás mejorar un proceso. Lo importante es saber rectificar a tiempo y aprender de dichos errores. Quien no se equivoca, no aprende.
  • Cada flujo engloba a una ventana de un proceso, dentro de su contexto. Kanbaniza primero una ventana de un proceso y esto hará que poco a poco vayas Kanbanizando todo el proceso de forma escalada. Pensemos que con Kanban optimizamos cada flujo. Más adelante, ya veremos como realizar Kanban Escalado para toda una organización.
  • Los clientes y empleados mejorarán su satisfacción. Menos sobrecarga de las personas, menos tareas que se eternizan y producen frustración, menos tiempo en terminar las tareas ( y antes están a disposición del cliente)

 

Próximos post:

  • Entender sistemas Kanban: ¡Empecemos a diseñar un sistema Kanban y a obtener algunas métricas sencillas !
  • Introducir Kanban en las organizaciones con el método STATIK
  • Cambio evolucionario: Protokanban
  • Kanban para la empresa: Orientación al servicio, Escalabilidad, Gestión de la demanda (Upstream) y Roles
  • Cadencias Kanban. ¿Los clientes están contentos? Circuitos de retroalimentación
  • Flujos de comunicación y técnicas de mejoras: Métricas avanzadas, interrupciones y dependencias, cuellos de botella y sobrecarga e ineficiencia

 

 

 

 

 

 

 

SESIÓN RETROSPECTIVA

Dejar un comentario

La pasada semana realizamos una sesión retrospectiva de cierre de un proyecto que, por sus especiales características, se gestionó de forma predictiva. Está muy claro que se obtienen mejores resultados estudiando el tipo de iniciativa de que se trate y aprovechando las mejores prácticas de cada metodología de gestión de proyectos.

Además, este proyecto tiene otra particularidad y es que es un proyecto que se repite todos los años (con un contenido muy diferente, pues entonces  sería un proceso).  Esto es especialmente relevante de cara al propio ejercicio de retrospectiva, ya que nos permite recoger las “lecciones aprendidas” como acciones de mejora continua, y así aplicarlas para el año siguiente.

Aún así, el año pasado ya habíamos hecho una sesión retrospectiva y todos los participantes salieron muy contentos de la experiencia.

El resultado fue interesante y enriquecedor. El equipo se siente más implicado porque es tenido en cuenta, como debe ser. Es más, las aportaciones más sorprendentes surgieron de quien menos se espera.

Comenzamos explicando antes de la reunión el enfoque que necesitábamos, pues es muy importante que todos los participantes conocieran su propósito:

No perdimos ni un minuto en el tema de las culpas, se trata de mantener una actitud de mejora, que se obtiene mirando al pasado para mejorar el presente. Todos los asistentes participaron activamente en la sesión y se abordaron todos los puntos, incluso los que pudieran ser más conflictivos.

“La sesión retrospectiva es una mirada al pasado para mejorar el presente”

Hay muchas formas de hacer una sesión retrospectiva. Escogimos el formato de  la “Estrella de mar” (Starfish) porque nos sentíamos cómodos con ella. Pero hay un montón de otras opciones. En este interesante sitio se pueden encontrar muchos recursos y artefactos: Funretrospectives

En concreto, tocamos los siguientes  puntos:

1. SEGUIR HACIENDO: Qué cosas nos han funcionado bien en este proyecto y otros años, para repetirlas.

2. HACER MÁS: Prácticas que aportan valor o bien “pilotos” que han obtenido resultados positivos (como acciones de mejora continua surgidas de la anterior retrospectiva).  Por lo tanto, las exprimiremos al máximo, les sacaremos todo el jugo posible, ya que son útiles y positivas en nuestro proyecto.

3. DEJAR DE HACER: Prácticas que consideramos que no son útiles o no agregan valor. Por lo tanto hemos decidido eliminarlas completamente.  Es importante enfocar estas acciones como espacios de mejora y no como fracaso de iniciativas, especialmente si se trataron de acciones surgidas de anteriores retrospectivas. Por ejemplo, si se decidió comenzar a hacer dailys que no han funcionado, quizás en lugar de simplemente dejar de hacerlas podemos buscar el por qué no han funcionado (asistentes, horario, falta de foco…).

4. HACER MENOS: Prácticas que no están ayudando tanto como se esperaba, o que simplemente no son útiles en nuestro escenario actual.

5. COMENZAR A HACER: Cosas nuevas a probar que nos gustaría poner en marcha pero entrañan riesgo por su novedad y nuestra inexperiencia. Constituyen una verdadera apuesta que puede salir bien o mal en nuestro proyecto.

LECCIONES APRENDIDAS:

En  realidad, de una sesión retrospectiva no se extraen exactamente lecciones aprendidas sino que sirven para aprender cómo han ido las cosas, junto con la implementación de planes de acción. En nuestro caso lo usamos para la preparación del nuevo proyecto anual.

Observamos ya de otras sesiones la pelea por descifrar las letras. Curiosamente, cuando algún participante sale a exponer al tablero físico las notas algunas veces no puede entender  lo que el mismo escribió (la letra de “médico” ya es común entre nosotros).   😉

Es muy importante destacar que si hay niveles de autoridad dentro de los participantes, se debe dar la opción de hablar primero a los de menor nivel de autoridad, para que no se puedan sentir coaccionados por las opiniones que manifiesten los participantes  de mayor nivel de autoridad.  Es importante recordar que la utilidad de las retrospectivas es que todos puedan aportar su visión y opinión, lo que puede suponer un auténtico reto cuando se realizan en entornos jerarquizados.

El uso de vídeo conferencia hace perder un poco de fuerza a una sesión de este tipo, aunque era eso o renunciar a  las valiosas aportaciones de compañeros que no podían asistir presencialmente y esto no era una opción, claro está. Con el uso de la vídeo conferencia salimos ganando, ampliando perspectivas y obteniendo más puntos de vista.

Otra idea interesante es utilizar una herramienta “on line” de gestión de los tableros. Por ejemplo, nosotros usamos la herramienta GOREFLECT (aunque se puede utilizar también la aplicación Trello) y fue útil para trasladar el tablero físico final a un tablero virtual. De esta forma pudimos tirar las notas de otras sesiones retrospectivas (antes de que pierdan los colores por el polvo que acumulan)  y empezar la sesión recordando el tablero virtual del anterior proyecto. Esto es particularmente útil para evitar pensamientos pesimistas del tipo de que estas prácticas no valen para nada, pues, analizando las pasadas notas, se pudo comprobar que  una buena cantidad de ellas si que se habrían llevado  a la práctica. Una prestación genial que tiene esta herramienta es la de exportar  las notas a un archivo excel, lo que permite trabajar con detalle las notas.

Muchas gracias a todos los compañeros que participaron en la sesión y en especial a Jorge Cruañes por sus acertados consejos y  aportaciones a esta entrada.

 

 

 

 

 

 

 

 

 

 

CONFERENCIA AGILE SPAIN 2018 (CAS 2018) SEGUNDA JORNADA

Dejar un comentario

SEGUNDA JORNADA:

1 DYNAMIC RETEAMING AT FAST GROWING COMPANIES – HEIDI HELFLAND

Heidi Helfand trabaja en la empresa Procore y es la autora del libro: “Dynamic Reteaming: The Art and Wisdom of Changing Teams“.

Antes de comenzar con su charla, Heidi pidió levantarse a las personas en cuyos equipos se incorporó alguna persona nueva durante el pasado mes. Y también pidió levantarse a los que sufrieron la marcha de alguna persona en su equipo. ¿Para qué esta encuesta sobre el terreno?. Porque en contra de la opinión mayoritaria, Heidi piensa que los cambios en los equipos no son necesariamente negativos y además son inevitables. Esto enlaza con el pensamiento ágil de abrazar el cambio, aunque va en contra de buscar la estabilidad del equipo.

Esta idea es multi nivel, puede referirse tanto a una compañía como a un departamento como a una tribu o a un equipo.

Hacer “Dynamic Reteaming” es aplicar unos ciertos esquemas a los problemas detectados para poder solucionarlos.

Existen cinco tipos de problemas y sus correspondientes patrones de solución:

Problema Nº 1: Emergencias.  En este caso, el patrón más adecuado de resolución es proporcionar aislamiento al equipo para que pueda afrontar los problemas urgentes. Se debe formar al equipo, aislarlo, darle libertad y posteriormente disolverlo (si procede).

Problema Nº 2: Obligación de crecer. Si llega este caso, se deberían de usar técnicas de mentorización o de pairing para lograr la asimilación uno a uno de los nuevos integrantes del equipo. Si son muchos los que llegan, habría que mezclarlos entre los equipos o  usar los bootcamps (entrenamientos de alta dedicación) para formarlos.

Problema Nº 3: Equipo demasiado grande. Es necesario en este caso, crecer y dividir. Eso si, Heidi avisa de los peligros de tratar de compartir recursos, algo que se debería de evitar a toda costa. Tampoco se deberían crear dependencias. Es positivo resetear a los equipos.

Problema Nº 4: Silos de conocimiento. Cuando se produce una situación en la cual el conocimiento no está documentado y reside solo en ciertos técnicos, en cuyo caso se debería proceder a intercambiar y a mezclar a personas de los diferentes equipos para que este conocimiento se comparta. Esta situación siempre debería prevenirse, por el peligro de dependencia que conlleva.

Problema  Nº 5: Estancamiento. Se puede llegar a esta situación si un equipo está junto durante demasiado tiempo y ya no aprenden nada ni hacen cosas nuevas, Ya no obtienen satisfacción en su trabajo y en el mejor de los casos se aburren y en el peor sufren en su trabajo. En el Modelo de Tuckman de Desarrollo de Equipos esta fase de estancamiento no fue tenida en cuenta. El modelo a utilizar aquí es cualquiera de los anteriores. Para evitar llegar a esta situación se deberían entender las necesidades de las personas y dar nuevas oportunidades de desarrollo profesional.

En resumen, ha sido una charla muy interesante, por lo que tiene de romper mitos, (reconozco que siempre pensé que los equipos deben ser estables y que ganan con el tiempo).

El vídeo de esta misma presentación (realizado en otra ocasión)  se puede ver aquí:

 

2 THE DEMOCRATIZATION OF LEADERSHIP – GUSTAVO RAZETTI

Gustavo inició su charla declarando que las empresas no preparan a las personas ante el cambio. Adaptarse significa tener una importante ventaja competitiva.

El ponente sufrió una experiencia muy adversa practicando trekking en la Patagonia. De este incidente  aprendió tres lecciones:

  • En las decisiones extremas las personas están solas.
  • Las situaciones críticas, el único que las puede resolver somos nosotros
  • Podemos hacer muchas más cosas de las que pensamos que somos capaces

Las empresas se esfuerzan en publicitar la cultura de su empresas para hacerlas apetecibles. Pero la realidad es que solo el 13 % de  los empleados están comprometidos con su empresa.

Las empresas han evolucionado, pero los conceptos se han acomodado y no han evolucionado. Nadie habla del temor de los jefes, de su miedo de perder su trabajo y su rol, si progresan las organizaciones más dinámicas y flexibles. Gustavo se preguntó cómo podemos implementar agilidad si todavía hay batallas por los silos de poder. Es evidente que existe un GAP entre lo que ve la empresa y lo que ven sus empleados. Y no es suficiente con empoderar a los empleados, porque muchas veces los empleados ven cosas pero no hacen nada por remediarlas.

Sobre la autonomía, el ponente mencionó que todo ser vivo tiende a la autonomía, pero se necesita un poco de tutela para que esa autonomía sea efectiva.

Sobre la motivación de los empleados , el modelo vigente dictamina que la motivación debe ser externa a la persona, ejemplo, ofrecer más dinero.  La motivación 3.0 indica que esta debe ser intrínseca, es decir, debe nacer dentro de la persona. Y se refiere a Daniel Pink (ya visto en otras ponencias) donde define la motivación moderna. Todos quieren ser mejor de lo que son. Lo que hizo Google es cambiar de equipo a los empleados que deben mejorar su desempeño, porque el contexto y la cultura nos afectan mucho. Y quieren autonomía para poder tomar decisiones.

Llegados a este punto de la ponencia, Gustavo propuso escribir nuestro nombre y título en un papel y romper la parte correspondiente al  título. ?Por qué? Porque los títulos limitan.

Para finalizar, disfrutamos de un vídeo de la serie “Juego de Tronos” en el cual Tyrion Lannister y Lord Varys discuten filosóficamente acerca del poder. El poder es una ilusión, el poder se asume y reside en los ojos del que lo ve. Es la capacidad de hacer cosas. Pero implica responsabilidades.

En el mundo animal, por ejemplo los pájaros, se van rotando en el liderazgo. Porque el liderazgo cansa y además es útil que haya varios posibles lideres. Y la gente  piensa que los  líderes son súper héroes. Y este paradigma  no existe. Son humanos y por lo tanto, se equivocan. Y así se debe romper el GAP entre líder y seguidor.

Los lideres deben tener tres capacidades:

  • Debe ser un líder “helpful”. Está para ayudar y sumar, no para restar.
  • Debe estar dotado de sabiduría
  • Debe generar una cultura basada en la abundancia, en proporcionar posibilidades para todos los empleados.

Dicen las estadísticas que el 90 % de los ejecutivos creen que se conocen bien como personas. Pero realmente solo se conocen bien un 15 % de ellos.

Un líder debe actuar, y debe tratar de remover los impedimentos que amenazan a  su equipo. Un líder también debe ser capaz de romper reglas para ser mas eficaz.

Hablando de la cultura de la empresa, se debe hacer notar que los lideres no manejan la cultura. Es un sistema que premia y que castiga. Y que condiciona la vida de los empleados.

Los equipos más productivos son los que obtienen”seguridad psicológica” dentro de los mismos. Es decir, son libres de expresarse sin miedo a la censura de los demás.

Y es interesante ver el enfoque de la empresa respecto a los errores. Es significativo determinar si existe una política  o no acerca de lo que piensa la empresa de los errores.

Respecto al proceso formal  de toma de decisiones, las empresas mas innovadoras proporcionan autonomía para decidir, pero dando ciertos criterios mínimos que se deben respetar.

Como punto final, el ponente afirmó que hay que darse a uno mismo el permiso para liderar.

 

3 MINDFUL AGILITY: EL PODER DE LA ATENCIÓN EN LOS EQUIPOS ÁGILES –  MIQUEL BLANCH

Miquel es Coach Sistémico en la empresa Grifols. Dividió en tres puntos esta charla:

  • Qué es y que no es Mindfulness
  • Experiencia en Grifols
  • Elementos comunes entre Agile y Mindfulness

El ponente adelantó, como conclusión, que el Mindfulness proporciona un set perfecto para trabajar en Agile.

El mindfulness actualmente está de moda.

Empezó hablando de dos porqués:

  • Por qué se ha popularizado el Mindfulness. Por el daño que ha hecho la multitarea. Pero no es nada nuevo que la multitarea está matando la productividad en las empresas. Es muy conocido el estudio de la bajada de productividad cuando se gestionan múltiples proyectos, debido al coste que implica el cambio de contexto (Gerald Weinberger, libro Quality Software Management Volume 1 Systems Thinking). Nos hemos hecho todos adictos a la acción y evitamos la reflexión.
  • Por qué creemos que los demás nos van a entender. Actuamos como si la comunicación fuese fluida pero esto no es así. Y el Mindfulness está en la empatía, en mejorar la relación con los demás. Puede ser una gran ayuda y así lo entiende la gente.

Qué es Mindfulness, según John Kabat Zinn: “Mindfulness is awareness that arises through paying attention, on purpose, in the present moment, non-judgementally”

John Kabat  creó un programa de siete semanas para reducir el stress, dentro de un entorno clínico.

Qué no es Mindfulness:

  • No es una religión
  • No es mirarse el ombligo
  • No es vaciar la mente de pensamientos
  • No es solo enfocar la atención
  • No es una técnica de relajación

A lo largo de la ponencia, pudimos experimentar dos prácticas:

  • Práctica de atención enfocada: Visualización de una imagen o pensamiento durante 45 segundos.
  • Práctica de atención abierta: usada para notar sensaciones corporales, emociones o pensamientos.

Por qué se hizo famoso el mindfulness: Porque se demostró que la atención es como un músculo y se puede entrenar. Y que la mente es como un laboratorio. Yendo más allá, esto está comprobado científicamente  por medio de resonancias magnéticas. Se producen cambios funcionales en la estructura del cerebro.

Experiencia en Grifols. Miquel preparó un programa basado en el programa de Google del año 2005 y Stanford y que combinó:

  1. Mindfullness
  2. Inteligencia emocional
  3. Neorociencia

El Mindfulnes aporta prácticas que ayudan  a mejorar basadas en la neurociencia. Se usa el Mindfulness para trabajar la inteligencia emocional, a su vez basada en la neurociencia.

El programa que Joan implantó en Grifols se basó en estos elementos:

  1. Auto conocimiento
  2. Auto regulación
  3. Empatía
  4. Liderazgo compasivo
  5. Motivación

El programa estaba planificado para tener una duración de 6 semanas, una por bloque, doblando el bloque de liderazgo.

Qué tiene que ver Mindfulness con Agile:

  • En las Retrospectivas y en los Sprints Reviews,  se debe hacer un ejercicio reflexión acerca de cómo ha ido todo.
  • Se produce una reducción del stress utilizando la limitación del WIP (work in progress)
  • Se produce foco en las dos semanas que suele durar un sprint en Scrum.
  • Agile se puede beneficiar del autoconocimiento, de la autoregulación, de la empatía
  • Dentro de los conflictos con los equipos, es interesante determinar que hay de uno mismo en ese conflicto. Esto puede hacer mejorar la auto organización.
  • Diferencia entre consenso y consentimiento. Esto puede ayudar a un equipo a auto regularse. La aceptación de las cosas como son, sin tener que estar de acuerdo.

Solo son unas pinceladas, comentó Miquel, para al que le resuene todo esto que profundice un poco más en este interesante campo.

 

4 EL CAMBIO COMO PROTAGONISTA DEL CAMBIO ORGANIZACIONAL – DIEGO ROJAS

Diego nos pidió que nos reuniéramos en grupos de tres o cuatro personas y discutiéramos entre  nosotros qué significaba para nosotros el cambio,  en 4 o 4 minutos. Como decía Heráclito, estamos en constante cambio.

Tienen claro que los cambios  organizacionales son un proceso, pero no un hito, pues se pueden dividir en una serie de pasos.

Y es importante saber ver las diferencias, pues lo que no se detecta, no existe, es importante detectar las diferencias.

Todos necesitamos seguridad y por eso el cambio genera incomodidad, peor por otro lado, todos tenernos esperanzas y expectativas, pues esto es progreso. Existe una permanente tensión entre la estabilidad y el cambio. peo es difícil tener todo bajo control

Sobre cómo reducir la resistencia al cambio, hay que determinar en qué estado están las personas y  lo que tratan de buscar.  El cambio no es lineal, está vivo. Y es sistémico, porque hay elementos que influyen en otros a su vez.

¿Cómo actuar ante un cambio? le parece muy adecuada la frase acuñada dentro de la PNL “El mapa no es el territorio”, es decir, cada uno tiene su propia verdad es decir, su propio mapa mental y que es diferente al resto Lo ideal sería entender primero nuestro mapa y luego tratar de entender los del resto.

A Diego le funciona hacer un mapa del cambio, compuesto de los siguientes elementos:

  • Personas
  • Relaciones
  • Contextos
  • Sistemas

Y también le ayuda conocer qué tipos de cambios existen. Por un lado están los cambios:

  • Remediativos
  • Generativos
  • De mantenimiento

Y por otro lado están los cambios:

  • De tipo uno. Son los que no hacen que el sistema cambie
  • De tipo dos. son los que hacen que el sistema cambie.

Esto enfocado al Agile, implica que personas de fuera del sistema con nuevas ideas pueden hacer más fácil que se produzcan los cambios dentro de un grupo.

Como conseguir el cambio. Las personas se comprometen con lo que hacen suyo. Hay una gran diferencia entre el cambio impuesto y el cambio orgánico. La gran diferencia es que el cambio impuesto requiere energía externa para que se mantenga, pues de lo contrario el cambio se paraliza.  Por otra parte, el cambio orgánico es el cambio por contagio y poco a poco las personas se van sumando y es sostenible

¿Cambiar la cultura de la empresa para cambiar las conductas o al revés?. Se requieren las dos, el cambio no es secuencial sino sistémico

¿Y cómo avanzar en el cambio?. Considera importante determinar por dónde estamos empezando a cambiar, pues a veces poner el foco en una parte  nos hace que nos perdamos otras cosas. El cambio emergente es lo que aparece una vez que se hay producido el cambio y que no nos esperabamos. Y hay que saber aprovecharse de este cambio emergente, hay que ser un oportunista de estos cambios emergentes.

Por ultimo, nos pidió que conectáramos con un cambio organizacional que hayamos vivido y que lo compartiéramos con los compañeros de al lado en unos 2 o 3 minutos.

 

5 ¿METODOLOGÍAS ÁGILES EN RETAIL? – EL CASO DE DÍA –  FERNANDO BARRIENTOS, DAVID GÓMEZ

Qué es grupo DIA. Fundada en 1979, cuenta  con 42.000 trabajadores repartidos en cuatro países: Portugal, Argentina, Brasil y España. Sector retail (alimentación). Con 7.400 tiendas. Sector muy desafiante y ccon nuevos players (por ejemplo, Amazon)

En DIA se comenzó con Agile en áreas eminentemente técnicas. Con acompañamiento externo.

Y se quiso dar un paso más, creando nuevos equipos desconectados con la estructura existente, orientados a producto. Se lanzó en:

  • APP de tiendas
  • APP de ffranquicias
  • APP de Clientes
  • Se amplió al equipo de E-Commerce
  • Y posteriormente al equipo B2B, CCA y MDA

Se preguntaron cómo llegar al “core”, que es el área comercial y así poder aprovecharse de las ventajas que aporta Agile: foco en cliente, comunicación. adaptabilidad, aprendizaje, entrega continua de valor y agilidad en la toma de decisiones.

Todo esto necesita negociación e implicación de las personas. Y se temían la sensación de la falta de control, de eficiencia y de dirección que se podría producir. Esto se se decidió afrontarlo con un enfoque alternativo a la resistencia al cambio, poniendo encima de la mesa objetivos comunes, haciendo así que todos remaran en la misma dirección. Se buscaron los cambios orgánicos o naturales, en lugar de los impuestos.

Cómo empezaron: con un equipo piloto para aprender. Comprobaron que el equipo con mayor libertad era el de Droguería. Una primera barrera fue que los directores eran reacios a aportar personal a este equipo.  Se añadió un “Comité de Apoyo” formado por Directores. Las métricas fueron nuevas y más cercanas a negocio: número de ventas, margen comercial, etc.

En el trabajo diario se notaron mejoras en materia de transparencia, pues Compras y Ventas estaban enfrentados y no compartian datos.

Se deben buscar los objetivos comunes, que se dividieron así:

  • NPS
  • Rentabilidad
  • Adopción de metodologías ágiles

Aprendizajes:

  • La multi modalidad es agotadora, pero merece la pena
  • El equipo directivo también tiene que ser equipo.
  • Necesarios objetivos comunes
  • Combinar resultados cualitativos y cuantitativos
  • la confianza en el equipo es crucial
  • El Comité de Apoyo no debe ser decisor, pero sí tener capacidad  de tracción
  • REvisar si es mejor la involucración a directivos a tiempo que el equipo o un poco después
  • Alejarse de dedicación parcial de miembros del equipo

El futuro: todo esto si puede ser aprovechado para la parte de cliente y negocio, así como con el departamento comercial. Sin embargo con departamentos de tipo staff no se aprovecha su potencial.

 

 

6 AGILIZANDO UN DEPARTAMENTO IT EN LA ADMINISTRACIÓN PUBLICA – IVÁN TEJERA

Una sorpresa. Lo que parecía ser una ponencia rutinaria se convirtió en una interesante explicación de cómo implantar agilidad en una Administración Pública.  Después de la sorpresa inicial, comprobé que Iván forma parte de la consultora Proiectus, conocidos por su interesante revista digital.

Aterrizaron en la Administración Pública de una forma no idílica.

La primera urgencia fue organizar el trabajo del día a día: Dividieron las aplicaciones en Gestiones y en Sistemas de información

De esta forma ya podían asociar las peticiones de servicio y las incidencias a las aplicaciones.

Comenzaron a trabajar en proyectos y en  metodologías. Y en la gestión de las  incidencias y de peticiones de servicio.

Había: proyectos, incidencias y peticiones.

Plantearon trabajar con Agilidad, en concreto, utilizando kanban y con Scrum, en sprints de 15 a 30 días.

Descompusieron el trabajo en historias de usuario y en tareas de desarrollo.

Y establecieron equipos por sistemas de información, y por peticiones/incidencias.

Había dos posibilidades:

  • Tener equipos separados para soporte y desarrollo
  • Tener equipos conjuntos, pero reservando un porcentaje de capacidad para soporte/desarrollo (70/30). Esto es lo que finalmente se aceptó.

Se definió una metodología de gestión de proyectos agile, compuesta de:

  • Backlog de producto  inicial
  • Historias de usuario
  • Story Maps
  • Product Roadmap

Personas. Son clave. La Administración tiene una estructura piramidal. En la organización había responsables funcionales, coordinadores de aplicaciones, analistas, jefes de desarrollo, jefes de proyecto y  equipos de desarrollo internos y externos.

El esquema que plantearon fue:

  • Los responsables funcionales pasaron a ser Product Owners
  • Los jefes de proyecto pasaron a ser Scrum Masters
  • Los analistas de aplicaciones pasaron a ser Proxy Product Owner

Se dieron cuenta de que había product owners que eran proveedores externos (por estar en ellos el conocimiento técnicos). esto es algo que se debe solucionar.

Herramientas. Constataron que era muy difícil obtener informes consolidados, debido a la cantidad de herramientas que convivían. Decidieron cambiar esto y poner dos en funcionamiento:

  • De gestión
  • Peticiones de servicio, de incidencias y de mantenimiento de aplicaciones. basada en web

También necesitaron instalar un complemento para poder realizar iteracciones con sprints y releases.

Y así empezaron a lanzar sprints. Como había equipos que daban servicio a 20 aplicaciones, decidieron lanzar sprints mensuales añadiendo tickets de esas 20 aplicaciones. Esto dificultó tener claro el objetivo del sprint.

Oficina de proyectos (PMO). Es la entidad que utilizaron para definir las métricas, la gestión de la Demanda, de proyectos, para gestionar el cambio y llevar el día a día. Es una ayuda para mejorar la madurez de la organización en materia de proyectos.  Y en hacer que se llegara al nivel repetible.

Se dieron cuenta de que para gestionar el cambio es necesario que haya agentes comprometidos con el cambio. Y se toparon con diferentes perfiles. Tomaron el modelo de John Kotter de Ocho pasos para gestionar el cambio. Las personas son reticentes al cambio impuesto, se debe involucrar a las personas afectadas por el cambio. Y vieron importante obtener triunfos a corto plazo.

Ya definido el modelo, se buscó extender el cambio a toda la organización. Se logró obtener información unificada y normalizada. Se dieron cuenta de que estaban más orientados a servicios que a proyectos.

Y dando una vuelta de tuerca, la capa directiva les pidió una planificación estratégica de cuatro meses. Esto significaba escalar las prácticas ágiles a la organización. Tomaron como referencia y ayuda el patrón SAFe y lo adoptaron a su modelo. Así obtuvieron ese roadmap a corto y medio  plazo, por cuatrimestres.

A nivel operativo, tienen cuatro niveles de peticiones:

  1. Proyectos (se corresponde con Épicas)
  2. Peticiones de Servicio (se corresponde con Features)
  3. Historias de Usuario
  4. Tareas

Nivel optimizado. Aquí  se buscó aplicar la mejora continua. Hay todo un procedimiento, un marco inicial.

Iván destacó una idea clave, lo que no se puede medir no se puede mejorar, como bien decía Peter Drucker. Todo se puede poder medir. Han conseguido bajar las peticiones abiertas y se han implantado un ANS (Acuerdo Nivel Servicio).

La Administración encaja bien con la agilidad porque trabajan en el día a día y es difícil que tengan proyectos cerrados. Y han visto un cambio positivo en materia de sinergias entre compañeros y un aumento de la transparencia.

Es una maravilla ver como la agilidad entra dentro de la Administración Pública. Olé, olé y olé.

 

7 INNOVANDO EN PERSONAS: CÓMO CREAR FELICIDAD EN EL TRABAJO – ANTONIO FONTANINI

Antonio mencionó a Dan Pink y su teoría de la motivación. Este video sobre lo que nos motiva es muy famoso.

Propuso que el desafío de las  empresas que deseen tener éxito son las que adapten su cultura a los nuevos modelos de negocio. Deben funcionar en modo dual adoptando, en algunos casos, un enfoque de startup y generando un impacto positivo en la sociedad en la que sirven. Se trata de la “Economía del Sentido”, es decir, un modelo económico basado en experiencias interactivas

Y en este contexto, es esencial que las empresas busquen el compromiso de sus empleados. Un empleado implicado no solo es más feliz, es hasta 2,7 veces más rentable.

A las empresas les debe importar crear un entorno donde los empleados puedan desarrollar todo su potencial  y disfruten con su trabajo. Para crear esto existen cuatro palancas de actuación:

  1. Seleccionar el talento, comenzando por las actitudes y trabajar las aptitudes necesarias, acompañando al colaborador  durante su carrera profesional
  2. Disponer de espacios de trabajo inspiradores, que fomenten el trabajo en equipo
  3. Construir una organización agile que permita aplicar el “Positive Leadership”
  4. Utilizar la “Positive Psycology” para maximizar la eficiencia y la motivación

Cerró su participación afirmando que innovar en personas es muy rentable.

 

OTRAS CUESTIONES

Quiero hacer una mención especial para dos ponencias a las que no pude asistir, pero varios compañeros de empresa que si asistieron a las mismas me comentaron sus positivas impresiones:

  • De 0 a 100. Mitos y Leyendas – Adolfo Menéndez: De lo más interesante por las experiencias aportadas. Por cierto, no es primo mío.
  • Gestión con Scrumban de proyectos de alta incertidumbre en el sector aeronáutico –  Mario Coquillat:
    • Tuve la fortuna de conocer a Mario en varios eventos relacionados con la gestión de proyectos y ya había disfrutado en parte de su ponencia. Una experiencia muy enriquecedora y recomendable, pues no es sencillo adaptar la agilidad dentro del sector industrial. Mario, ademas de disponer de sólidos conocimientos en materia de proyectos, es un excelente comunicador.

Y me despido con algunas apreciaciones:

  • Bastantes ponencias han sido enfocadas a negocio y sus experiencias adaptando la agilidad. Me parece un acierto.  Si las personas de negocio no entienden o no “compran” la agilidad, poco se puede hacer.
  • Había ideas o modelos que se repetían en varias charlas: el Modelo de Laloux, el modelo Toyota, el modelo de Tuckman, la teoria de la Motivación de Daniel Pink o el omnipresente modelo organizativo de Spotify, por mencionar algunos.
  • Cada vez son más las ponencias que se dedican a enfocar la agilidad fuera de software. Otro gran acierto. La agilidad es perfectamente exportable a proyectos o iniciativas fuera del mundo de software.
  • Cada día resulta más evidente que en esta profesión es obligatorio estar formándose continuamente para obtener una gran extensión de conocimientos y conocer la mayor cantidad de técnicas o de estrategias disponibles, pues estas se podrán emplear en función de los problemas o patrones que se detecten.

Este es el documento, actualizado en tiempo real, con el material compartido de los ponentes:

Acceso al Video Resumen Oficial de la CAS 2018 KeepItReal!

 

Hasta el próximo CAS 2019

NOTA: Fotos de Ángel de la Iglesia

CONFERENCIA AGILE SPAIN 2018 (CAS 2018) PRIMERA JORNADA

Dejar un comentario

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)

LIBRO PEOPLEWARE Y EQUIPOS ÁGILES

Dejar un comentario

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 AGILE PRACTICE GUIDE

Dejar un comentario

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: