jueves, 20 de febrero de 2020

¿Porqué la definición de listo (DoR) no es prescriptiva en Scrum?

¿Incluir DoR o no? - cortesía de Pixabay
A través de la definición de listo (DoR - Definition of Ready) el Propietario del Producto puede marcar historias de usuario de la pila de producto como listas para trabajarse en un sprint. Trata de un conjunto de acuerdos que les permite a todos saber cuándo están listas para comenzarlas y por tanto poder incluirlas en un sprint. Una definición de listo adecuada puede mejorar las posibilidades del equipo para cumplir con éxito el objetivo del sprint, pero una definición de listo inadecuada puede llevarnos a prácticas no deseables.

Mike Cohn en su artículo "The Dangers of a Definition of Ready" nos advierte que la definición de listo puede llevarnos a prácticas de proyecto en cascada. Si en la definición de listo se incluye algo que deba de estar terminado al 100% antes de que una historia pueda entrar en un sprint, el proceso se acercará peligrosamente a un proceso secuencial en cascada. Imaginemos un escenario con una definición de listo que marque que una historia de usuario ha de estar completamente diseñada para entrar en un sprint, en ese ejemplo nos estaremos acercando peligrosamente a sprints de diseño seguidos de sprints de construcción...

Recordemos que la forma ágil de acometer sprints es que todo el equipo, compuesto por miembros con las habilidades necesarias para construir historias de principio a fin, esté focalizado de forma concurrente en una sola historia de usuario a la vez, y que trate de acabar la que esté en curso antes de empezar la siguiente. Cuando una cosa no puede comenzar hasta que se haga otra, el equipo ya no concurre sobre una historia y cada miembro probablemente emprenda tareas desconectadas.

Equipo refinando historias de usuario
dejándolas suficientemente listas
Otra disfunción puede llevar a que cuando los Propietarios del Producto dejen las historias de usuario en situación de listo, se considere que todo está hecho y se minimice la conversación y comunicación entre el equipo y estos. Hasta podría darse el caso de Phoenix Product Owners, el Propietario del Producto que deja todo listo, desaparece después de la planificación de sprint y no reaparece hasta la revisión de sprint.

Recordar que Scrum trata de comunicación diaria y trabajo concurrente incluido el Propietario del Producto. Una buena definición de listo es una parte integral de la actividad de refinamiento de la pila en forma de proceso continuo a lo largo del sprint, y no como una lista de verificación secuencial de lo que tenga que estar al 100% listo para entrar en un sprint. Es por todo ello que la Scrum Guide no incluye DoR (Definition of Ready) como parte de Scrum.

miércoles, 12 de febrero de 2020

¿SAFe® es prescriptivo o descriptivo?

SAFe es una brújula y un mapa - cortesía de Pixabay
Una de las críticas más usuales a SAFe® es que se le tacha de prescriptivo. Hasta en la matriz ASK (Agile Scaling Konwledge) Matrix puede leerse sobre SAFe "a customizable but prescriptive framework for most aspects of Agile at scale" y "seen as prescriptive; not Agile enough in its structures".

Scaled Agile define a SAFe como:

"SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles, practices, and competencies for achieving Business Agility by implementing Lean, Agile, and DevOps at scale".

Por tanto SAFe es una base de conocimiento de principios, prácticas y competencias integradas y comprobadas para lograr Business Agility mediante la implementación de Lean, Agile y DevOps a escala.

Base de conocimiento significa que SAFe viene a ser como una brújula y un mapa, provee de herramientas para que un guía-interprete en colaboración con las compañía pueda traducir en soluciones específicas para la misma.

En mis facilitaciones y clases todo tipo de asistentes preguntan por detalles y métodos prescriptivos, por métricas concretas y como integrar tal o cual cosa que está en su realidad. No se trata de eso, se trata de un camino de descubrimiento.

SAFe describe herramientas para que coaches ágiles, SPCs y RTEs descubran junto a su cliente las prácticas, métodos, métricas, etc. más adecuadas para la compañía asegurando que estén alineadas con los valores y principios ágiles.

Las claves de una transformación ágil exitosa son líderes comprometidos y una coalición de agentes del cambio, esos guías-interpretes formando en ocasiones una LACE (Lean Agile Center of Excellence), empoderada y energética. Deberíamos de enseñar/explicar a los líderes el Overview y preguntarles si es eso lo que quieren. Y si es que si, guiar y acompañar a la compañía en su propio camino hacia Business Agility.
El Overview con las 7 competencias para que una compañía adquiera Business Agility
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

domingo, 9 de febrero de 2020

¿Porqué toda compañía debería de ser de software hoy en día?

Project to Product
de Mik Kersten
Recienemente Chris James, el CEO de SAFe®, dio una charla en el meetup oficial de SAFe en Madrid, y habló del libro de Mik Kersten "Project to Product" y de la transformación en compañías IT, que es la transformación de las organizaciones tradicionales que quieren ser consideradas compañías de software.
Chris James en el meetup de Madrid

Pero, ¿por qué las compañías quisieran transformarse en compañías de software?

Pues para sobrevivir a medio y largo plazo; para ello tienen que innovar en nuevos servicios y productos, y no solo en cómo ser más eficientes. Una forma de innovar para diferenciarse está en los servicios sobre los productos de la compañía.

Por ejemplo, si somos una compañía de materiales de construcción y vendemos vigas es difícil competir solo con la viga misma, estas están muy bien estandarizadas y las dimensiones, composición y calidad de diferentes proveedores son idénticas. Donde pueden innovar las compañías para diferenciarse es en nuevos servicios alrededor de esas vigas, y esos servicios se basan principalmente en software.

Veamos algunos ejemplos de compañías que innovan en servicios con software:
  • Dormakaba - originalmente se trataba de una compañía que vendía puertas de seguridad, ahora definen su producto como "soluciones de acceso inteligente y seguro". Por ejemplo, parte de su visión es que cuando una persona desembarque en un aeropuerto pueda utilizar la misma tarjeta para salir del recinto, acceder al metro o a un coche, a la habitación de su hotel, a la empresa que visite, etc. Esa visión incluye hardware, las puertas, y un servicio basado en software.
  • BMW - inicialmente una empresa automovilística, ahora su core-business se define como "soluciones de movilidad". BMW se ha planteado si su modelo de negocio para el futuro es seguir vendiendo coches o focalizarse en un servicio de suscripción de uso de coches a necesidad, como las bicicletas y patinetes que se usan en las ciudades a través de una app. BMW prevee que en el futuro más de la mitad del personal de I+D sean desarrolladores de software.
  • Siemens Gamesa - un empresa que nació con los molinos de viento, actualmente su propósito es "unidos para dibujar el futuro de las energías renovables". Actualmente los motores de la turbinas son equivalentes en prestaciones y calidad a lo largo de los diferentes proveedores. El modelo de negocio ahora incluye servicios de mantenimiento de las turbinas y de gestión de los parques eólicos. Estos servicios se basan en software, las turbinas tienen multitud de sensores cuyos datos se analizan en tiempo real para predecir cualquier situación y minimizar a cero los tiempos de parada. La gestión de parques eólicos, para equilibrar la generación de energía a demanda con los vientos, requieren de software cada vez más complejo e innovativo.
  • Lafarge Holcim - empresa que conocemos principalmente por su cemento, se definen como "líder del sector de los materiales y soluciones de construcción". Su modelo de negocio no solo se centra en la producción de cemento, los cementos de la competencia son de idénticas características y calidad, lo que les diferencia son los servicios y sobre todo los de logística. Entre otros servicios están los camiones cementera que preparan el cemento y este servicio se complemente con software que, a semejanza de Cabify, permite que los clientes puedan saber dónde está la camión y cuando llegará para tener todo preparado para recibir el cemento.
Miremos a la gran compañía que miremos su estrategia de supervivencia está un modelo de negocio que incluye servicios basados en software. Hay de añadir que probablemente la mayoría de las compañías produzcan o producirán mayoritariamente en China, lo que nos da a los países occidentales la oportunidad de diseñar y desarrollar esos servicios y construir el software que los gobierne. Y dado que esos servicios evolucionarán continuamente, necesitaremos de la Agilidad.

Nos dice Mik Kersten que las compañías que sean maestros en la entrega de software a gran escala serán las que definan el panorama económico de nuestro siglo, por tanto en el mundo actual no hay sitio para software de baja calidad que no se adapte continuamente a las oportunidades de mercado. Google, Microsoft y Amazon son maestros en el desarrollo de grandes sistemas, nos enseñan como hacerlo y sabemos lo que hemos de hacer (ingeniería de software ágil, calidad calidad calidad, acelerar nuestra pipeline con DevOps, organizarnos alrededor del valor...). Debemos de aprender de ellos, las compañías que no lo hagan probablemente acaben sirviéndoles con sus productos.

martes, 4 de febrero de 2020

¿Cómo entender TDD con un ejemplo?

Ciclo TDD Green-Red-Refactor
Leyendo el libro Test-Driven Java Development de Viktor Farcic y Alex García publicado por Packt Publishing en 2015, he encontrado un ejemplo a modo de Kata (demostración sencilla de la técnica) que ilustra muy bien cuáles son las ventajas de esta forma de construir código.

Para comprender este post, es necesario tener conocimientos básicos de: qué es TDD, un lenguaje de programación orientado a objetos (aquí se usa java) y entender que es un marco de pruebas unitarias XUnit (aquí se usa JUnit).

Una de las piezas clave para hacer un buen desarrollo TDD es tener la capacidad de desgranar la funcionalidad a implementar en muy pequeñas partes. Esta capacidad de idear partes mínimas a programar en cada ciclo Green-Red-Refactor es imprescindible si queremos ciclos cortos, a ser posible de minutos, tal y como recomienda la técnica. En este texto los autores presentan el ejemplo que procedo a explicar y que según mi criterio muestra la técnica a la perfección.

Ejemplo: Tres en raya

Tres en raya es un juego en el que sobre un tablero de 3x3 casillas, 2 jugadores juegan por turnos rellenando una casilla cada vez. Gana el jugador que consigue tener 3 casillas rellenas alineadas en horizontal, en vertical o en diagonal. 

El objetivo del ejemplo es implementar el código necesario para jugar a 3 en raya. Este es el requisito que el programador recibe. El desarrollo debe comenzar por algún trozo de código que se pueda probar y desarrollar preferiblemente en minutos. En este ejemplo se propone empezar por:

1.    Primer ciclo red-green-refactor

Definir los límites que en horizontal no puede sobrepasar una pieza. Es decir la pieza solo puede estar en las casillas 1, 2 o 3.

Para empezar se hace un caso de prueba para comprobar que la pieza no se intenta colocar fuera del rango, provocando una excepción en este caso. Para detectar la excepción en la prueba con JUnit recurrimos a la anotación @Rule.

    @Rule
    public ExpectedException exception =
            ExpectedException.none();
    private TicTacToe ticTacToe;

    @Test
    public void whenXOutsideBoardThenRuntimeException()  {
        exception.expect(RuntimeException.class);
        ticTacToe = new Tictactoe();
        ticTacToe.play(5, 2);
    }


Esta es la fase red del ciclo TDD, puesto que la ejecución de la prueba no es satisfactoria ya que ni siquiera existe la clase Tic-tac-toe. Ahora se crea esta clase, para avanzar en la fase green.

    public class TicTacToe {

        public void play (int x, int y) {
            if (x < 1 || x > 3) {
                throw
                new RuntimeException("X is outside board");
            }
       }

   }


Ahora se concluye la fase green cuando la ejecución de la prueba es satisfactoria.

En la fase refactor modificamos la prueba introduciendo la anotación @Before para crear el objeto tic-tac-toe. Esto se hace porque van a existir más pruebas y estas también necesitarán crear un objeto de esta clase.

    @Rule
    public ExpectedException exception =
            ExpectedException.none();
    private TicTacToe ticTacToe;

    @Before
    public final void before() {
        ticTacToe = new TicTacToe();
    }

    @Test
    public void whenXOutsideBoardThenRuntimeException()  {
        exception.expect(RuntimeException.class);
        ticTacToe.play(5, 2);
    } 


De esta forma se ha completado un ciclo red-green-refactor. ¿Cuánto tiempo puede llevar este trabajo de codificación y pruebas? Seguramente no más allá de minutos.

2.    Segundo ciclo red-green-refactor

El siguiente ciclo red-green-refactor se dedica a la funcionalidad para las casillas verticales. Se siguen los mismos pasos, lo primero el caso de prueba.

        @Test
    public void whenYOutsideBoardThenRuntimeException() {
        exception.expect(RuntimeException.class);
        ticTacToe.play(2, 5);
    }


Estamos en fase red no hay tratamiento para el valor de Y. Importante la prueba de X sigue funcionando. Se añade el tratamiento para Y.

    public class TicTacToe {

        public void play (int x, int y) {
            if (x < 1 || x > 3) {
                throw
                new RuntimeException("X is outside board");
            } else if (y < 1 || y > 3) {
                throw
                new RuntimeException("Y is outside board");
            }
       }

       }

Estamos en fase green. En este momento se repasa el código y se decide no refactorizar nada. Es decir no hay nada que mejorar.

3.    Tercer Ciclo red-green-refactor

La casilla en la que se coloca la pieza no puede estar ocupada. La prueba.

    @Test
    public void whenOccupiedThenRuntimeException() {
        ticTacToe.play(2, 1);
        exception.expect(RuntimeException.class);
        ticTacToe.play(2, 1);
    }


Después la implementación.

    public class TicTacToe {

        private Character[][] board = {{'\0', '\0', '\0'},
                {'\0', '\0', '\0'}, {'\0', '\0', '\0'}};

        public void play (int x, int y) {
            if (x < 1 || x > 3) {
                throw
                new RuntimeException("X is outside board");
            } else if (y < 1 || y > 3) {
                throw
                new RuntimeException("X is outside board");
            }
            if (board[x - 1][y - 1] != '\0') {
               throw
               new RuntimeException("Box is occupied");
            } else {
               board[x - 1][y - 1] = 'X';
            }
        }

    }


Después la refactorización. En refactorización se decide reorganizar la clase para mejorar la legibilidad del código.

public class TicTacToe {

    public void play(int x, int y) {
        checkAxis(x);
        checkAxis(y);
        setBox(x, y);
    }

    private void checkAxis(int axis) {
        if (axis < 1 || axis > 3) {
            throw
                    new RuntimeException("X is outside board");
        }
    }

    private void setBox(int x, int y) {
        if (board[x - 1][y - 1] != '\0') {
            throw
                    new RuntimeException("Box is occupied");
        } else {
            board[x - 1][y - 1] = 'X';
        }
    }
}


Se comprueba que la prueba sigue terminando con éxito después de la refactorización. Todo preparado para continuar con el siguiente ciclo hasta que se termine de implementar el juego tres en raya al completo.

Conclusión

Este ejemplo muestra cómo mediante TDD vamos construyendo un código que además de tener pruebas unitarias automatizadas, está refactorizado no introduciendo deuda técnica. Esta forma de desarrollo también dota al código de un diseño poco acoplado y cohesivo.

domingo, 2 de febrero de 2020

¿Como se relaciona SAFe® con Business Agility?

El sistema operativo dual
Accelerate (XLR8) de John P.Kotter
John Kotter sostiene que para gestionar adecuadamente una gran compañía la mejor solución es una jerarquía bien organizada y bien desarrollada. Pero para crecer, evitar el colapso y competir y prosperar en la era digital, respondiendo rápidamente a los cambios del mercado y las oportunidades emergentes con soluciones empresariales innovadoras, necesitamos algo más.

En su libro Accelerate (XLR8) describe que las jerarquías dirigidas por la gestión "todavía son absolutamente necesarias para que las compañías funcionen", pero requiere que la jerarquía se convierta en una jerarquía de liderazgo, con líderes al servicio receptivos a comprender que su entorno es disruptivo y que está en constante cambio.

Lo que sugiere es crear un sistema operativo dual. El segundo sistema se organiza como una red que funciona en cooperación con la jerarquía existente. Y aquí es donde entra la nueva versión 5.0 de SAFe®, esta se convierte en un segundo sistema operativo, que al organizarse en torno a flujos de valor en lugar de departamentos, ofrece una forma para que las compañías se centren en sus clientes, sus productos, la innovación y el crecimiento. Resulta en un sistema operativo flexible que se basa en prácticas Lean, Agile y SAFe probadas que permite organizarse y reorganizarse rápidamente sin interrumpir por completo la jerarquía existente; justo lo que exige Business Agility.
SAFe como segundo sistema operativo organizacional para lograr Business Agility
Imagen del tema Business Agility cortesía de © Scaled Agile, Inc.
Kotter nos expone que el segundo sistema operativo debe de basarse en algunos principios básicos:
  • Muchas personas impulsan cambios importantes, y desde todas partes, no solo los nombrados habitualmente: este principio reconoce la posible contribución realizada por cualquier persona de la compañía. "Se necesitan más ojos para ver, más cerebro para pensar y más piernas para actuar y acelerar". Da a más personas la libertad para llevar a cabo iniciativas y es la base para el desarrollo de líderes.
  • Una mentalidad de "llegar a" y no una de "tener que": las personas dan pasos adelante pero solo si "se les da la opción y sienten que tienen permiso para dar un paso adelante y actuar".
  • Acciones dirigidas no solo por la cabeza sino también por el corazón: la lógica por sí sola no es suficiente, necesitamos personas motivadas que se sientan comprometidas para apoyar a los lideres y a la compañía, y esto ocurrirá si con ello consiguen dar un mayor significado y propósito a sus esfuerzos.
  • Mucho más liderazgo, no solo gestión: la gestión conecta y mueve la compañía, pero "el nombre del juego es liderazgo y no ejecutivo efectivo". Ambas prácticas son cruciales, pero la gestión por sí sola "no garantizará el éxito en un mundo VUCA".
  • Una asociación inseparable entre la jerarquía y la red, no solo una jerarquía mejorada: "Los dos sistemas, red y jerarquía, funcionan como uno solo, con un flujo constante de información y actividad entre ellos, un enfoque que tiene éxito en parte porque las personas que trabajan en la red ya tienen trabajos dentro de la jerarquía".
Las 7 competencias de SAFe
SAFe se alinea con los principios que menciona Kotter a través de sus siete competencias. La fundación o base es "Lean-Agile Leadership"; sin una jerarquía de líderes al servicio con mentalidad Lean-Agile, una transformación ágil con SAFe como marco con objetivo Business Agility, no va a funcionar.

Jerarquía se define como "organización de personas en una escala ordenada y subordinante según un criterio de mayor o menor importancia o relevancia dentro de la misma". Mayor o menor importancia o relevancia no significa necesariamente mando y control, ese es el sesgo que solemos tener los que hemos vivido compañías tradicionales, también puede significar comunicación y apoyo como es en el caso del liderazgo.

Enfocar una transformación ágil desde la perspectiva de un segundo sistema operativo puede ser interesante ya que de esta manera los mandos intermedios de la jerarquía, que son personas con sus miedos y preocupaciones, se pueden ver reflejados en la estructura nueva y dejar de considerarla una amenaza y abrirse a la red.

Quiero resaltar que una compañía ágil no tiene porqué tener una jerarquía y un segundo sistema operativo. La propuesta de SAFe es una solución punto de partida en la que a través de la mejora continua algunas compañías seguirán conviviendo con la jerarquía y otras evolucionarán hacia otros estructuras organizacionales como la holocracia por ejemplo.

Thanks to Michael McKinney and his article "Accelerate (XLR8)" and Scaled Agile, Inc. from whom SAFe and Scaled Agile Framework are registered trademarks.

viernes, 31 de enero de 2020

¿Es un Product Manager un gestor?

Como gestor o manager en este contexto se entiende a la persona que tiene la responsabilidad sobre el producto o servicio, sea para un cliente interno o externo, por tanto tiene autoridad y actúa en representación de otras personas.

A diferencia de Scrum de equipo único, en escalado una sola persona no puede manejar la estrategia de producto y de mercado mientras también se dedica a equipos; necesitamos dos roles diferenciados:
  • El Product Manager, cuyo foco es el mercado y el cliente para que identifique y comprenda sus necesidades
  • El Propietario del Producto, enfocado en la solución, la tecnología y en el equipo
Repasemos las diferentes responsabilidades en un marco de escalado:
Product Manager
Cortesía de Pixabay
Propietario del Producto
Cortesía de Pixabay
Equipo ágil
Cortesía de Pixabay
Un Product Manager se encarga de que se construya la cosa correcta, y Propietario del Producto y equipo lo construyen de la forma correcta, por tanto el Product Manager no participa en la ejecución de la construcción.

Eso nos lleva a que Product Manager es un gestor en forma de líder al servicio, lidera y colabora en la preparación de las features para soltarlas en planificación trimestral al Propietario del Producto y al equipo para que las construyan de forma autónoma. Estos dividirán cada feature en historias de usuario donde el Propietario del Producto tiene toda la autoridad sobre el "qué" y el equipo sobre el "cómo".

Lo que hay que entender aquí es que una vez la feature está en la pila del equipo el Product Manager ha perdido toda autoridad sobre esta, el Propietario del Producto adquiere toda autoridad y tiene absoluta libertad para materializar la feature en las historias de usuario que él considere, y ajustar la pila siempre que decida.

Como podemos ver no hay jerarquía de mando en un Product Manager, por supuesto hay colaboración, sobre todo con los Propietarios del Producto con los que forma un equipo que se alinea en las PO-Sync.

viernes, 24 de enero de 2020

¿Porqué hay gente que dice que "odia" SAFe?

Remove References To Scrum From SAFe!
Hay algo de revuelo últimamente en la comunidad Agile, algunos agilistas declaran con convencimiento en contra de SAFe®. Un ejemplo lo podemos encontrar en el artículo de Alex Kudinov "Extremists and the hate SAFe machine", y otro en la petición "Remove References To Scrum From SAFe!" para quitar los términos de Scrum de SAFe...

Pero ese no es el objeto de este post... como agilista y como coach ágil me preocupan las personas, aquellos que hacen el trabajo, los que forman los equipos ágiles. El Manifiesto Ágil empieza con "estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros", por tanto la Agilidad busca como mejorar las formas de trabajar, focalizándose sobre todo en personas sobre procesos.

Desde mi perspectiva y entendido esto, no importa tanto el proceso sino como este mejora la forma de trabajar y la vida de las personas. Lo que ha de preocuparnos es como las personas que hacen el trabajo y generan valor sufren implementaciones de SAFe disfuncionales, esos desarrolladores y programadores que en diversas situaciones me dicen que "odian" a SAFe. Les pregunto sobre el porqué y me cuentan sus historias completamente disfuncionales:
  • Trenes de entre 300 y hasta de 600 personas con equipos de 15 y hasta 40 personas, trenes en cuyo diseño se ha ignorado absolutamente la dinámica de grupos y la sociología imposibilitando así una autoorganización adecuada.
  • PI Plannings en las que se planifican las tareas de todas las personas a tres meses vista... una chica programadora me comentaba que es como hacer encaje de bolillos, el equipo crea tareas para cada miembro del equipo de manera que cuadren con la "pila del alcance fijo" y carguen a cada persona al 100% de trabajo... algo en lo que nadie cree y anula todo sentimiento de compromiso.
  • Votaciones de confianza donde los managers recomiendan previamente no votar menos de 3... y si alguien vota un 2 el manager directo tiene una charla privada con la persona y a la vuelta la persona vota 3... con el resultado de que todo el tren vote 3. Otra historia cuenta que en una votación predominó el 2, los desarrolladores fueron a comer y a la vuelta los "Scrum Masters" dieron instrucciones a todos, se volvió a votar y el resultado fue 3 para arriba. La votación de confianza trata de averiguar si todos los participantes están convencidos de los planes que ellos mismos han elaborado en la PI Planning, deberían de ser 4 y 5.
  • Retrospectivas en la que los managers están presentes y no emerge nada, por tanto se niega todo beneficio de la mejora continua.
Razones como estas son las que nos deben de preocupar y mover a los coaches ágiles.

En mis cursos de SAFe veo que los managers suelen tener una perspectiva muy distinta de la de los programadores, donde el manager ha adaptado SAFe y declara que va bien, los equipos hablan de verdaderas aberraciones. Hay una gran desconexion sobre todo entre mandos intermedios y equipos. A veces me pregunto ¿como empresas/managers que lidian dificultosamente con su producto en el mercado pretenden diseñar una metodología?

Una implementación correcta es responsabilidad tanto de estos managers como nuestra, los coaches ágiles. Como coaches ágiles debemos de concentrarnos en generar entornos motivantes en los que los managers lideren y apoyen a los equipos para que puedan construir adecuadamente y entregar valor de forma iterativa y sostenible... y para eso SAFe es un excelente punto de partida si aplicamos sus valores y principios.

Dean y Jeff, from Scruminc. blog
Me encanta la fotografía en la que se ve a Dean Leffingwell, el creador de SAFe, y a Jeff Sutherland juntos; creo que podemos aprender de esa foto. Esta se puede ver en un artículo de Jeff "Scaling Scrum – What People Are Not Talking About!" en el que habla como junto a Alex Brown presentaron una forma de pensar sobre el escalado que se podría aplicar a cualquier marco (o falta de él).

Lo podemos leer en su artículo "Scaling Scrum using Object Oriented Architecture" donde concluyen entre otras que: "Un marco empresarial universal debe permitir que la organización inspeccione y adapte gradualmente su propia estructura sin causar consecuencias en todo el sistema. La comunidad Agile necesita un marco de acoplamiento lento para escalar Scrum que pueda actuar como el "esqueleto" de funciones, conexiones, entradas y salidas a las que se puede conectar el "músculo" de diferentes prácticas exitosas".

Y para cerrar un poco de humor; FATE el marco de Michael Küsters para compañías condenadas. "FATE NO ES SAFe: FATE es una advertencia para cualquiera que piense que puede obtener beneficios al incorporar una nueva estructura en una organización existente sin aplicar habilidades de pensamiento crítico".
Fake Agile Transformactions for Enterprises,  thanks to Agilecartoons

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