sábado, 18 de enero de 2020

¿Son necesarios managers en el modelo Spotify?

El rol del Chapter Lead
gracias a David Jiménez
Si nos referimos al documento original de 2012 "Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" de Henrik Kniberg y Anders Ivarsson podemos leer que:

"El Chapter Lead es el gerente de línea de los miembros de su chapter, con todas las responsabilidades tradicionales, como el desarrollo de personas, fijación de salarios, etc. Sin embargo, el Chapter Lead también es parte de un squad y está involucrado en el trabajo diario que le ayuda a mantenerse en contacto con la realidad".

Un gerente de línea tradicional supervisa las actividades que están directamente relacionadas con los productos y los servicios, y es el supervisor inmediato del empleado, cuyas funciones incluyen la supervisión, la dotación de personal y el garantizar la seguridad y la salud.

Esas responsabilidades tradicionales han llevado a disfunciones en alguna tribu en la realidad en la que me muevo en España: si eres un empleado ¿a quién haces caso si no hay alineamiento? ¿al Propietario del Producto? o ¿al Chapter Lead que es quien decide tu salario y aprueba tus vacaciones? Dependiendo de la madurez de la compañía, los Chapter Leads pueden enmascarar la jerarquía de mando y control anterior y anular la autoridad de los Propietarios del Producto que en definitiva llevan las prioridades de las historias de usuario a los squads a través de la pila de producto.

Además resulta que los empleados técnicos sienten más afinidad técnica con los Chapter Leads, y si la cultura de la compañía está en transformación esto representa un freno, el chapter nos vuelve a llevar a perspectiva de las tareas que representan actividades técnicas con las que los técnicos se sienten cómodos, frenando así la introducción de historias de usuario cuya perspectiva es la de funcionalidades de principio a fin para el cliente.

En 2017 Viktor Cessan lideró un experimento para distribuir las responsabilidades del Chapter Lead en la tribu y eliminar así todos los Chapter Leads de la tribu de IT. Su artículo "What we learned from removing all chapter leads (managers) in the IT tribe at Spotify" habla de como pensando que el modelo Spotify implica demasiados roles formales de liderazgo decidieron buscar un modelo organizacional que permitiera escalar sin añadir roles de management.

Algunas de las responsabilidades de gestión del Chapter Lead sucederían a través de la información de la empresa como las reuniones informativas, y las 4 tareas principales (fijar salarios, garantizar que se sigan los procesos correctos, aprobar costes y fichar y despedir a personas) las desplazarían a Tribe Leads.

Lo que debe de incorporar todo Chapter Lead, gracias Guino Henostroza
Nos cuenta Viktor que una vez eliminados los Chapter Leads, los Tribe Leads se vieron ahogados por parte de los miembros de la tribu con cuestiones "¿cómo hacemos esto ahora?, ¿qué significa esto para mí?", a la vez que el resto de la compañía comenzó a abordarlos cada vez más con todo lo relacionado con temas de recursos humanos. Los squads también se vieron sobrecargados, ahora tenían que hacer las tareas del ex-gerente: reclutamiento, desarrollo personal, etc.

El aprendizaje para Spotify fue que eliminar gerentes intermedios cuando estás escalando o creciendo es una mala idea. Ahora sí, es importantísmo que estos se conviertan en líderes al servicio y adopten la mentalidad ágil que subyace al modelo Spotify.

lunes, 6 de enero de 2020

¿Cómo es un líder al servicio?

El líder al servicio hace crecer a otros. cortesía de Pixabay
Robert K.Greenleaf acuñó el concepto del líder al servicio como "... aquel que pone atención en el desarrollo y crecimiento de sus equipos, desde sus compañeros hasta sus clientes. El líder al servicio ha de ser siervo primero. Comienza con el sentimiento natural de querer ser útil a los demás. Luego viene la decisión consciente de aspirar a liderar. La mejor prueba es: ¿crecen los que sirve como personas?, mientras son servidos ¿se vuelven más saludables?, ¿más sabios?, ¿más libres?, ¿más autónomos?, ¿más propensos a ser siervos?" menciona en su ensayo "El servidor como líder".

El líder al servicio se considera a sí mismo "el primero entre un grupo de iguales", está dispuesto a liderar a otros con el fin de alcanzar una meta común, pero no cree que siendo el líder lo hace mejor que ellos. Es un formador de equipos consumado que recurre a las fortalezas de sus seguidores y desarrolla el talento de éstos tratándolos con respeto y escuchando de forma activa todas sus voces, buscando ideas y opiniones, y se vuelve un seguidor cuando es conveniente.

Sus características son:
  • Capacidad de comunicar
  • Tiene habilidades sociales
  • Inspira confianza
  • Tiene coraje
  • Autoridad de contenido
  • Sensación de equilibrio
  • Visión de futuro
Sus tareas son:
  • Guía a las personas en la identificación de problemas y la toma de decisiones
  • Crea un ambiente de influencia mutua y una cultura de confianza
  • Empatiza con los demás
  • Fomenta el desarrollo personal de los equipos
  • Persuade en lugar de usar autoridad
  • Aplica system thinking y pone énfasis en el trabajo colaborativo
  • Apoya los compromisos asumidos por los equipos
  • Promueve una cultura de aprendizaje continuo
Robert K.Greenleaf: El líder al servicio ha de ser siervo primero

sábado, 4 de enero de 2020

¿Hay otro camino en la nueva revolución tecnológica que no sea la Agilidad?

Carlota Pérez
Hay otra respuesta a si la Agilidad es un moda que es mucho más clara y contundente, y que podemos comprender gracias a Carlota Pérez en su libro Revoluciones Tecnológicas y Cambios de Paradigmas, o a través de su charla en youtube.

En su libro Carlota Pérez traza la evolución de la sociedad, los negocios y el capital financiero en función de las revoluciones tecnológicas que se han producido en los últimos cientos de años. Ella opina que estas revoluciones tecnológicas disruptivas suceden cada generación más o menos, cada 40-60 años.

Concluye que estas revoluciones tecnológicas alteran radicalmente la sociedad, primero a través de un movimiento de masas en capital financiero (inversión), que luego da como resultado un nuevo capital de producción (bienes y servicios). Con cada nuevo paradigma se introducen cambios sociales masivos, disrupción, un nuevo orden económico y un nuevo sentido común.
Regularidad histórica y regularidad temporal de las revoluciones tecnológicas
del vídeo Revoluciones Tecnológicas y Cambios de Paradigmas de Carlota Pérez

Cada revolución tecnológica trae modernización, un salto cuántico en productividad en toda la economía. Estas disrupciones de revolución tecnológica ocurren en tres fases distintas:
  • Período de instalación: la nueva tecnología y el capital financiero se combinan para crear un big bang de gran innovación y ruptura tecnológica que abre todo un nuevo universo. La sociedad trata de aprender y asimilar esta nueva manera de producir, pensar y vivir, lo viejo se enfrenta a lo nuevo.
  • Punto de inflexión: los negocios existentes adquieren la nueva tecnología y la nueva forma de pensar, o disminuyen y se convierten en reliquias de la última era. Se trata de una época de recesión donde muchas empresas son destruidas para dar paso a lo nuevo, es un punto donde siempre ocurre una burbuja bursátil como fue Crack del 29 y el Nasdaq del 2007.
  • Período de despliegue: el capital de producción de los nuevos gigantes tecnológicos comienza a tomar el control y se produce una época de bonanza.
Las tres fases distintas en que ocurren las revoluciones tecnológicas
del vídeo Revoluciones Tecnológicas y Cambios de Paradigmas de Carlota Pérez

En los últimos 200 años ha habido cinco revoluciones tecnológicas:
  • 1771 - Revolución industrial: en esta se produjeron nuevos procesos de manufactura que liberaron al hombre del duro trabajo manual; inicio de la producción por máquinas en lugar de los métodos artesanales, fabricación de productos químicos, nuevos procesos de producción de hierro, mayor eficiencia de la energía del agua, etc.
  • 1829 - Hierro, máquina de vapor y ferrocarril: con la locomotora mejoró la comunicación entre diferentes ciudades y se pudo trasladar mayor cantidad de objetos y materiales con mayor velocidad, reduciendo los tiempos de producción y distribución.
  • 1875 - Acero, electricidad e ingeniería pesada: la producción masiva de acero desarrolla la industria pesada en USA y Alemania, fue la primera globalización donde se sustituyeron los barcos de vela por buques pesados que en dos semanas llevaban materias primas alrededor del mundo.
  • 1908 - Petróleo, automóvil y producción en masa: se caracteriza por el modo de vida americano con la producción en masa donde la industria marca lo que es bueno para la familia americana: qué casa, qué coche, qué frigorífico, etc. Ford produce el modelo T en cadena, se electrifican las carreteras, se construyen aeropuertos y la radio proporciona difusión y acceso a la información.
  • 1971 - Microprocesador, informática y telecomunicaciones: llega la era digital con internet gracias a la electrónica, la tecnología de la información y las telecomunicaciones.
Estamos en plena quinta revolución tecnológica
del vídeo Revoluciones Tecnológicas y Cambios de Paradigmas de Carlota Pérez
La revolución tecnológica actual es la informática, la que se inició en 1971 con el microprocesador y las telecomunicaciones. Podemos identificar sus tres fases:
  • Período de instalación: la explosión de los nuevos participantes se pueden identificar con el auge y la caída de las puntocom a principios de siglo.
  • Punto de inflexión: la recesión puede verse en la desaparición de empresas existentes que no fueron capaces de dominar la nuevas tecnología como Blockbuster, teléfonos Nokia, AOL y otros.
  • Periodo de despliegue: podríamos mirar las capitalizaciones de mercado de Google, Apple, Amazon, Baidu, Salesforce o Tesla, todo empresas que no existían 20-30 años atrás. Tenemos por delante un auge general si gobiernos y empresas saben establecer las políticas adecuadas para la generación de riqueza.

La revolución informática trae un nuevo sentido común, nuevos conocimientos y creencias compartidas consideradas como prudentes, lógicas o válidas, por ende una forma de pensar radicalmente diferente:
  • Estructura empresarial: las estructuras jerárquicas de mando y control no sirven para mantener competitivas a las empresas, las exitosas se basan en estructuras en redes abiertas como Agilidad Organizacional, Sociocracia, Holocracia, etc.
  • Productos: pasamos de utilizar materia prima a utilizar materia gris. El conocimiento es el que ahora produce valor.
  • Operaciones: pasamos de procedimientos óptimos a la mejora continua donde todos los empleados innovan y dan ideas sobre como mejorar la productividad.
  • Personal: el término "recurso" donde el personal es un coste a minimizar se vuelve obsoleto, las nuevas empresas entienden que es necesario invertir en los trabajadores de conocimiento, en su microaprendizaje continuo, y así impulsar la mejora continua, se acuña el término "people".
  • Proveedores: ya no funciona poner a competir a estos entre si, comprendemos que son nuestros partners y hemos de establecer alianzas win-win para crecer juntos.
  • Estrategia: pasamos de la planificación central rígida a estrategias flexibles y adaptables. Las compañías tienen una visión, un rumbo, pero todo el personal puede intervenir para modificar la estrategia en función del feedback para obtener mejores resultados y ser competitivos.
  • Mercados: en un mundo distribuido e hiperconectado las segmentaciones estándares como grande, mediano, pequeño, o la geográfica se convierten en una hipersegmentación con múltiples nichos a tratar de forma específica cada uno.
  • Medio ambiente: las empresas que no toman conciencia por el medio ambiente pueden no ser aceptadas por sus clientes potenciales.
El nuevo paradigma actual y el nuevo sentido común
del vídeo Revoluciones Tecnológicas y Cambios de Paradigmas de Carlota Pérez
Entendido el nuevo paradigma, que nos llevará a una época de bonanza, podemos identificar los valores de la Agilidad, los valores de Lean y a poner al cliente en el centro de la nueva forma de producir y pensar.

Esto lo conocemos hoy en día como Business Agility, que representa la capacidad de las organizaciones para adaptarse rápidamente a los cambios del mercado, tanto interna como externamente, respondiendo de forma rápida y flexible a las demandas de los clientes. Implica capacidad de adaptación y liderar esos cambios de manera productiva y económica, sin comprometer la calidad y buscando mantener una ventaja competitiva.

Business Agility no se limita a la tecnología de la información, implica una transformación de la organización, sea de cualquier tamaño, y debe ser orgánica e involucrar a toda la compañía y personal, áreas de recursos humanos, marketing, finanzas, compras, atención al cliente, entre otras.

Llegado este punto podemos entender que la Agilidad no es una moda, es una necesidad para aquellas compañías que quieran sobrevivir y florecer en el paradigma que ya se ha instalado.

Os quiero invitar a ver la charla de Carlota Pérez:


Otro recurso relacionado son las diapositivas de 2002 de Carlota Pérez Las fuerzas que producen las burbujas financieras y las "épocas de oro" / Corporación Andina de Fomento-EUREKA.

martes, 31 de diciembre de 2019

¿Qué técnica de team-building utilizar que ayude a las personas a comprender mejor su relación con ellos mismos y con los demás?

Recientemente un grupo de coaches ágiles que tenemos interés en el nuestro desarrollo profesional apoyando y enseñándonos unos a otros, practicamos una herramienta que ayuda mucho a conocernos tanto internamente como a nivel de equipo; La Ventana de Johari.

Se trata de una herramienta de psicología cognitiva creada por los psicólogos Joseph Luft y Harry Ingham para ilustrar los procesos de interacción humana. Es un modelo de análisis que ilustra el proceso de comunicación y analiza la dinámica de las relaciones personales. Intenta explicar el flujo de información desde dos puntos de vista, la exposición y la retroalimentación, lo cual ilustra la existencia de dos fuentes: los "otros", y el "yo".

La teoría se articula mediante el concepto del espacio interpersonal, que está dividido en cuatro áreas definidas por la información que se transmite:
  1. Área libre: lo que conozco sobre mi y los demás conocen de mi
  2. Área oculta: lo que conozco de mi y no cuento a los demás
  3. Área ciega: lo que los demás conocen de mi y yo no conozco
  4. Área desconocida: lo que ni yo ni los demás conocemos sobre mi
Estas áreas están permanentemente interactuando entre sí, por lo que, si se produce un cambio en un área este afectará a todos los demás.
Nuestro tablero con las cuatro áreas
Por consiguiente en función del grado de conocimiento existen:
  • 2 áreas que yo conozco, la 1 y la 2
  • 2 áreas que los demás conocen de mi, la 1 y la 3
  • 2 áreas que yo desconozco de mi mismo, la 3 y la 4
  • 2 áreas que los demás ignoran de mi, la 2 y la 4
  • 1 área que yo conozco de mi pero que los demás ignoran, la 2
  • 1 área que los demás conocen de mi pero que yo Ignoro, la 3
  • 1 área que ni yo conozco de mi ni os demás conocen de mi, la 4
Construyendo modelos durante la sesión
La dinámica que propongo en este post se basa en como hacer team-building de forma innovadora y creativa mediante Lego Serious Play para buscar ampliar el área abierta de la Ventana de Johari.

Lego Serious Play es una técnica de facilitación grupal que permite la reflexión, comunicación y resolución de problemas a través de una serie de retos diseñados por el facilitador y pensados para lograr el objetivo de la sesión.

Durante la sesión los participantes construyen modelos LEGO para dar respuesta a los retos planteados a través de un conjunto especial de piezas de LEGO, los Kits de LSP (Lego Serious Play), y estos modelos constituyen las bases para la discusión, compartir y generar ideas, la toma decisiones o la construcción de modelos compartidos.

En la caso de la sesión de la ventana de Johari, después de trabajar con unas preguntas o retos de calentamiento, que permiten a los participantes familiarizarse con el método, con las piezas y con la temática a tratar, se realizan las siguientes preguntas para trabajar las distintas áreas de la Ventana de Johari:

Para trabajar el área 1, la conocida por mi y por los demás, se pide a los participantes que construyan un modelo que refleje sus principales cualidades y valores que son esenciales para él. Cada participante comparte la historia asociada al modelo para describirlo y comenzar una rica discusión a través de los significados, metáforas y preguntas que van surgiendo sobre el modelo. Una vez que todos los participantes han descrito su modelo se reflexiona sobre los aprendizajes adquiridos. Para este punto los participantes dicen que les sirve para conocerse mucho mejor a ellos mismos, para identificar las prioridades que tienen en cuanto a sus valores esenciales y para conocer más profundamente a cada uno de sus compañeros.

Para trabajar el área 2, la conocida por mi y desconocida por los demás, se pide a los participantes que construyan un modelo que refleje algún aspecto que su personalidad o de su vida que piensen que sus compañeros no conocen. Se sigue la misma mecánica descrita en el punto anterior y para este punto cuando los participantes reflexionan sobre los aprendizajes adquiridos. En este punto suelen decir que les sirve para darse a conocer más profundamente a sus compañeros y los compañeros dicen que les permite acercarse mucho más y profundizar sus interrelaciones al conocerse más profundamente tanto personal como profesionalmente.
Ejemplo con modelos que construimos en la sesión
Y para trabajar el área 3, la desconocida por mi y conocida por los demás, se pide a los participantes que construyan un modelo que refleje cualidades que ven ellos de alguno de los compañeros y que sea probable que ellos mismos no sean conscientes de que las poseen. Se sigue la misma mecánica descrita en el punto anterior y para este punto cuando los participantes reflexionan sobre los aprendizajes adquiridos dicen que reciben una gran regalo de parte de su compañero y muchas veces lo que reflejan los modelos construidos son un gran descubrimiento para ellos.

El área 4, la que desconocen ambos no se trabaja, después de la sesión esta se habrá reducido.

Una vez superados todos los retos el ambiente generado en el equipo es espectacular. Ha sido una oportunidad para conocerse mejor, para desarrollar la confianza, descubriendo y compartiendo aspectos positivos desconocidos y fortaleciendo los lazos personales y profesionales entre los miembros del equipo.

Y ya para compartir mi experiencia mencionaros que en la sesión he descubierto como mis compañeros tienen un perspectiva de mi de la que no era consciente y que ¡por ello me valoran! También he tomado perspectiva emocional de mis compañeros y como ellos lidian con sus conflictos y emociones.

Este post se queda corto para transmitir lo que se puede aprender y descubrir en una sesión de Lego Serious Play, así es que os invitamos a participar en una y experimentarlo por vosotros mismos.

Descargas / Downloads
Mis agradecimientos a Miguel Ángel y a Ana por compartir su póster a través de mi blog y por ponerlo a disposición de toda la comunidad y todos aquellos que les pueda ser de interés.

miércoles, 18 de diciembre de 2019

¿Cómo nos ven los laicos a los coaches ágiles?

Informáticos para todo, de Taringa
Con este post quiero introducir un poco de humor, no todo tiene que ser serio :-D :-D

Los que tenéis un recorrido algo más largo en TI, sobre todo en microinformática, ¿os acordáis como os salían "clientes" no deseados por doquier? Te invitaban a su casa personas que casi no conocías a "arreglar la impresora" o a instalar un juego de ajedrez que se les resistía... Y luego todo lo que tenía que ver con botones se suponía que caía en tu área de conocimiento, como por ejemplo las centralitas telefónicas, de las que tengo conocimiento nulo y sobre las que más de una vez me pidieron ayuda. Ya el colmo fue cuando me pidieron arreglar una bandeja de esas que a modo de cajón corredero soportaba los teclados situados debajo de los escritorios.
Meme para el coach ágil

Pues bien, ya tenemos el primer caso documentado (en este blog) de como nos salen ese tipo de "clientes" a los coaches ágiles: a mi compañera Gertrudis le pidieron ¿nos puedes ayudar a pintar unos carteles?... hay coaches ágiles que tienen habilidades de facilitación gráfica, pero esta habilidad no es core para un coach ágil.

Humor aparte, situaciones como la última mencionada sirven para hacernos reflexionar sobre cuál es la visión que tienen de nosotros como coaches ágiles, y sobre qué podemos hacer para llegar a las personas en nuestro entorno para darles una visión real de lo que hacemos, de qué otras cosas sabemos hacer además de pintar carteles o facilitar reuniones.

Lo primero en situaciones como esta es tener una conversación amena para profundizar en las opiniones de nuestro interlocutor. Una cosa que funciona muy bien es trasladar la situación a la realidad del interlocutor. Si nos lo dice un abogado de civil, por ejemplo, le podemos decir ¿verdad que no eres experto en mercantil y si te llega algo de mercantil se lo pasas al departamento correspondiente?, y luego tratar de explicar el core de lo que hacemos, dónde aportamos valor y finalmente preguntarle en qué otras cosas podemos ayudarle.

La clave de un buen coach ágil es enseñar a pensar, a crear un entorno seguro donde todo el mundo pueda pensar.

Mis agradecimientos a Gertrudis por haber participado en este post, y a mi amigo Luís con el que he disfrutado mucho compartiendo estas batallitas.

lunes, 16 de diciembre de 2019

¿Cómo comprobar la salud de un sistema in extremis?

Crash test de AXA - cortesía de Pixabay
Cuando la industria de la automoción crea un coche nuevo, antes de ponerlo en el mercado, coloca un crash test dummy, un maniquí para ensayos de choque dentro, y estampa el coche contra la pared. Esta prueba extrema pone de manifiesto debilidades del coche, debilidades que han de corregirse antes de lanzar un coche seguro al mercado.

Como símil al crash test Netflix ha desarrollado la Simian Army, el ejército de simios que resulta en un conjunto de servicios o "monos" para comprobar la salud de sus sistemas y hacer ensayos de crisis provocando fallos en su software.

La construcción de software es un ingeniería compleja que implica bugs, no se puede garantizar al 100% que alguna parte no pueda fallar. Aún invirtiendo en el hardware más costoso y en las herramientas de software más modernas nada garantiza que en una situación crítica haya un fallo y tengamos un problema en el sistema. En Netflix son conscientes de ello y desarrollaron su arquitectura para que los componentes individuales puedan fallar sin afectar a la disponibilidad del resto del sistema.

Es necesario evaluar constantemente la capacidad del sistema para sobrevivir a todo tipo de fallos. Hemos de poner a prueba nuestro sistema, desenchufar el SAI, cortar el suministro, desconectar un servidor, para ver si de verdad el software está preparados para desplegarlo en producción. Esta es una de las premisas de un sistema resilente con capacidad para sobreponerse a imprevistos para minimizar o eliminar su impacto y no perjudicar a nuestros clientes.

José Luis Martínez nos habla en su post "El ejército de simios de Netflix" de los 8 monos:
Imagen de Wikipedia
  • Chaos Monkey: una herramienta que inhabilitaba de forma aleatoria servidores de producción para garantizar que el servicio se mantiene y no hay impacto para el cliente.
  • Latency Monkey: induce retrasos artificiales en la capa de comunicación cliente-servidor para simular la degradación del servicio y mide si los servicios responden adecuadamente.
  • Conformity Monkey: encuentra servidores que no se adhieren a las mejores prácticas y los apaga.
  • Doctor Monkey: aprovecha los controles de estado que se ejecutan en cada servidor y supervisa otros signos externos de salud (por ejemplo, la carga de la CPU) para detectar estados no saludables.
  • Janitor Monkey: asegura que el entorno se está ejecutando libre de basura y desperdicio. Busca los recursos no utilizados y los descarta.
  • Security Monkey: encuentra violaciones de seguridad o vulnerabilidades y finaliza las instancias ofensivas. También revisa los certificados SSL y DRM.
  • 10-18 Monkey: detecta problemas de configuración y tiempo de ejecución en instancias que atienden a clientes en múltiples regiones geográficas, utilizando diferentes idiomas y conjuntos de caracteres.
  • Chaos Gorilla: es similar a Chaos Monkey, pero simula una interrupción de toda una zona de disponibilidad.
La Simian Army está disponible como Open Source en GitHub, en la descripción se puede leer: "Simian Army consiste en servicios (monos) en la nube para generar varios tipos de fallos, detectar condiciones anormales y probar nuestra capacidad para sobrevivir. El objetivo es mantener nuestra nube segura, protegida y altamente disponible".

Actualización de Netflix

"Todo el software tiene un ciclo de vida y llegó el momento de desarrollar las ideas centrales de Simian Army para satisfacer las necesidades cambiantes del entorno de Netflix. El primer paso más obvio fue separar los servicios para que pudieran evolucionar de forma independiente. Al separarlos, también permitió que cada uno utilizara diferentes tecnologías y modelos de implementación, por ejemplo, integrar la funcionalidad de Conformity Monkey directamente en Spinnaker proporciona a los equipos comentarios en la misma interfaz de usuario que realizan las implementaciones, lo que aumenta la visibilidad de las violaciones y permite la capacidad de mostrar acciones correctivas".
  • Chaos Monkey ahora es standalone
  • Janitor Monkey ha sido reemplazado por Swabbie
  • Conformity Monkey y los servicios de auditoria se han movido a Spinnaker

domingo, 15 de diciembre de 2019

¿Existe un mapa de metodologías y métodos?

Juan Palacio de Scrum Manager creó un mapa de metodologías que me parece interesantísimo y quiero compartir en este post, pone de relieve las dimensiones que son clave para entender las diferentes formas de afrontar un proyecto.

Desde los 80 se han desarrollado tantos modelos de procesos, marcos y prácticas de trabajo para mejorar la calidad y eficiencia en los proyectos de software, que resulta útil trascender las etiquetas y llegar a la base de los principios que subyacen, y las estrategias con las que los desarrollan; de forma que usando como coordenadas tres conceptos: “desarrollo, trabajo y conocimiento”, y dos modelos de gestión: “predictiva y evolutiva” se despeja y simplifica el aparente laberinto de modelos de procesos, marcos o prácticas de trabajo a los que nos referimos: CMM-SW, CMMI, PMBOK, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, Lean, Kanban, TDD, etc..

Las diferentes prácticas y metodologías responden a combinaciones de tres conceptos y dos patrones de gestión de proyectos.
Diagrama de conceptos de la gestión de proyectos - cortesía de Scrum Manager
Conceptos

1.- Desarrollo

Completo: La descripción de lo que se desea obtener está disponible al inicio del proyecto, es completa y detallada, sirve de base para estimar el plan del proyecto: tareas, recursos y agenda de trabajo. Durante la ejecución se gestiona su cumplimiento.

Incremental: La descripción de lo que se desea obtener no está disponible de forma completa y detallada al inicio: se complementa y evoluciona en paralelo al desarrollo, que genera el resultado de forma incremental y que se puede gestionar con dos tácticas diferentes:
  • Desarrollo incremental continuo: Empleando técnicas para lograr un flujo continuo de desarrollo de las funcionalidades o partes del producto, que se entregan de forma continua al cliente.
  • Desarrollo incremental iterativo: Empleando técnicas de tiempo prefijado o timeboxing para mantener la producción de incrementos del producto de forma cíclica y continua. Este es el marco de producción empleado al aplicar el marco estándar de Scrum, que define como sprint a cada iteración de desarrollo, al final de la cual se produce un incremento del producto.
2.- Trabajo

Secuencial (cascada): Divide el trabajo en fases, que comienzan al terminar la anterior. El ejemplo más habitual es el ciclo de cascada definido en Ingeniería del software con las fases de requisitos, análisis, diseño, codificación, pruebas e implementación.

Concurrente: Solapa en el tiempo las diferentes fases. Siguiendo con el ejemplo de ingeniería de software, la definición de requisitos, el análisis, la codificación y el despliegue del resultado se realiza y revisa de forma simultánea y continua.

3.- Conocimiento

¿Dónde se encuentra el principal conocimiento empleado, en la correcta ejecución del proceso o en el saber hacer de la persona que lo realiza?

Producción basada en procesos: El conocimiento o know-how, responsable de la calidad del resultado se encuentra en mayor medida en los procesos y la tecnología empleada: “La calidad del resultado depende de la calidad de los procesos empleados“.

Producción basada en personas: El conocimiento o know-how responsable de la calidad del resultado se encuentra en mayor medida en el “saber hacer” tácito de las personas que lo construyen.

Patrones de gestión del proyecto

Gestión predictiva

Modelo de gestión cuyo objetivo es ofrecer resultados predecibles: desarrollo del producto previsto, en el tiempo previsto, e invirtiendo los recursos previstos. Emplea una estrategia de desarrollo completo con prácticas de planificación tradicional. Los principales referentes en el desarrollo de conocimiento para este tipo de gestión son PMI e IPMA y los modelos de procesos CMMI, ISO 15504, SPICE, entre otros, que emplean ingeniería secuencial y producción basada en procesos.

Gestión evolutiva

Modelo de gestión cuyo objetivo es entregar lo antes posible un Mínimo Producto Viable, e incrementar su valor de forma continua. Emplea una estrategia de solapamiento de las fases de trabajo, y desarrollo incremental, que se puede obtener manteniendo un ritmo de iteraciones breves y cíclicas o un flujo de desarrollo constante. Puede llevarse a cabo con producción basada en procesos (ingeniería concurrente) o con producción basada en personas (Agilidad).

Es importante esta distinción porque sin ella se generan situaciones confusas que llegan a considerar Agilidad a la simple aplicación de las reglas estándar de Scrum (ciclo de incremento iterativo con roles y artefactos definidos), o al simple uso de técnicas de gestión visual Kanban para mantener un flujo continuo de tareas.

Extraído del guía de estudio de Scrum Manager