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

Como dice Michele "SAFe ha sabido pasar la experiencia a limpio".

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.

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

Hoy en día cualquier compañía implica una experiencia digital para sus clientes, como los canales de comunicación y de relación cliente-proveedor a través de apps y la web, y si esta experiencia no es buena estos se irán al siguiente proveedor. Por tanto es para 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 digitales sobre los productos de la compañía.

Chris James en el meetup de Madrid
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 complementa 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.