jueves, 5 de septiembre de 2019

Transformación Digital - Caso de estudio: Magazine Luiza


Hay retailers que se abrazan al ladrillo y otros a la Transformación Digital 


Hay retailers que se abrazan al ladrillo, haciendo o no haciendo Transformación Digital. Se aferran a su modelo de negocio tradicional y solo ven a la tecnología apenas como una manera de apalancar el negocio o de modernizarse. Este tipo de empresas son las que vienen cerrando, operando en crisis o ralentizando sus proceso de Transformación Digital. Algunas hacen transformación cosmética sin resultados e incluso rechazan la posibilidad de correlacionar los esfuerzos de Transformación Digital con el éxito de la misma.

Sin embargo hay otras empresas que se transforman digitalmente y marcan la diferencia. Y sus indicadores de éxito son evidentes. Un ejemplo es el retailer brasilero Magazine Luiza que es un fuerte testimonio de los resultados que una empresa puede lograr en una Transformación Digital con visión y propósitos claros. Una empresa tradicional de ladrillo y cemento durante gran parte de su historia, que luego pasó por una verdadera transformación. La misma inició en 2016 con la llegada de Frederico Trajano como CEO de la compañía. Antes de que Trajano se convirtiera en CEO, la compañía era un minorista tradicional de ladrillo y cemento y estaba creciendo a tasas de un solo dígito saludables. A finales de 2017, después de la designación de Trajano para el puesto de CEO, más del 30 por ciento de sus ventas provino de canales en línea. Mientras Trajano se preparaba para el FOO, se debatió si debería reformular el negocio como una “empresa de tecnología” o mantener su estado de ‘retail’. Él optó por convertirlo en una “Empresa de Tecnología” apostando por el crecimiento sobre la rentabilidad. Para apoyar este cambio, el CFO de Magazine Luiza, Roberto Bellissimo, ayudó a ejecutar un plan de inversión para que el FOO atraiga a personas interesadas en tecnología. Estos inversores financieros valoraron en gran medida a la empresa en función de las tasas de crecimiento. Sin embargo eran algo reticentes. Cuando la empresa anunció resultados positivos en las ventas en línea y en el EBITDA, inversores compraron rápidamente las acciones de Magazine Luiza. El crecimiento ecommerce creció desde el 2014, donde las ventas de comercio electrónico representaron el 16 por ciento de las ventas totales, al 2017, con una cifra que había crecido hasta el 30 por ciento. Desde diciembre de 2013 hasta mediados de 2017, el precio por ganancia de Magazine Luiza (P / E) creció de 12,4 a 27,2. Sus indicadores evidencian sus resultados positivos.



Referencias:



viernes, 21 de junio de 2019

POWER Agile


Principle-Driven & Results-Oriented ---> (Refraseando) ---> POWER --->
POWER = Principle-Oriented With Enterprise Results    ---> (sumando principios ágiles Agile)
Agile POWER = Agile Principle-Oriented With Enterprise Results   ---> (cambiando orden)
POWER Agile

Un borrador del equipo de transformación descubriendo un framework de Transformación Digital:



Referencias bibliográficas:
  1. Marosin Diana, “Towards a Principle-Based Framework for Enterprise Architecture Rationalization”.
  2. Kim S. Cameron, Robert E. Quinn (2016), “Diagnosing and Changing Organizational Culture Based on the Competing Values Framework”, The Jossey-Bass Business & Management Series.




viernes, 24 de mayo de 2019

Agile Delivery: ¿Cómo podemos medir la productividad de nuestros equipos ágiles?

Una vez que se ponen en marcha un conjunto de equipos ágiles de desarrollo de software algún Gerente TI o un Delivery Manager suele hacer la siguiente pregunta: ¿Cómo podemos medir la productividad de los equipos ágiles? Y la respuesta rápida que surge es con la velocidad. Y aquí se puede complicar todo. Permítame aclarar que tanto las palabras productividad como velocidad son riesgosas de malas interpretaciones. Antes de usar la palabra productividad es preferible usar la palabra rendimiento o prestancia: es decir “performance”. Y cuando hablamos de velocidad, es preferible no pensar en velocidad como cantidad de entrega (cantidad de historias o cantidad de story points), sino como la rapidez de entrega (tiempo de entrega). Un equipo ágil de alto rendimiento entrega software de calidad, funcionando en producción, de valor al cliente y a la compañía, en forma rápida. La velocidad está asociada a llegar rápido al cliente con funcionalidades de calidad y con valor. Aumentar la velocidad sirve para recibir feedback rápido del cliente y poder mejorar la propuesta de valor. El rendimiento de un equipo, desde la perspectiva técnica de TI o DevOps, incluye esto. Bien, dicho esto… ¿Qué medimos? ¿Qué métricas de rendimiento podemos usar? Nicole Forsgren, Jez Humble and Gene Kim nos ofrecen una buena respuesta en su libro Accelerate. Ofrecen una definición concreta y cuantificable del rendimiento de TI. Con cuatro métricas es posible comparar empíricamente, contrastar, clasificar y, posteriormente, mejorar el rendimiento de su equipo, de su tribu o área de desarrollo de software.
  • (Delivery) Lead Time: (tiempo de entrega) el tiempo que se tarda en pasar un ítem de requerimiento de cliente (historia de usuario) a inicio, hasta que está desarrollado y terminado (pasa el DoD). El reloj comienza cuando un elemento se mueve de la acumulación a cualquiera de los estados de "trabajo en progreso" y finaliza cuando el trabajo cumple con su definición interna de terminado DoD (por ejemplo, implementado y verificado en producción). 
  • Deployment Frequency: (frecuencia de despliegue) medir la frecuencia con que se despliega en producción conduce a que los lotes sean más pequeños (historias pequeñas), a hacer eficiente el pipeline de despliegue, mejorar el flujo de trabajo. Es probable que si la frecuencia aumenta entonces la performance también. 
  • Mean Time to Restore (MTTR): (tiempo medio de restauración o Time to Restore Service) tiene más sentido medir la rapidez con que los equipos se recuperan de la falla que la frecuencia con la que ocurren. Un equipo performante es ágil para recuperarse de fallos. Aquí el reloj comienza cuando se produce una interrupción del servicio en producción y el reloj termina cuando se resuelve la interrupción. 
  • Change Fail Percentage: (porcentaje de fallos de cambios o Change Failure Rate) una medida proxy de la calidad en todo el proceso es medir cuánto se falla en hacer cambios. Aquí se combinan dos contadores: uno para implementaciones y otro para fallas. El contador de KPI de Deployment Frequency se puede reutilizar para este caso. El segundo contador aumenta cada vez que se produce un fallo posterior (HOTFIX, OPCONS, roll back/forward, or patches, etc.). La tasa de fallas es la suma de fallas dividida por la suma de implementaciones en una ventana de tiempo dada. Mi consejo es que este KPI es reactivo, se correlaciona con la calidad pero a posteriori. Recomiendo usar además alguna métrica proactiva como: deuda técnica acumulada (Accumulated Technical Debt).
Por último, cabe aclarar que medir debería ser en función de mejorar y tener KPIs o métricas de rendimiento nos ayuda a eso, a mejorar. Sirve para mejorar el sistema de desarrollo de software o TI. Como dijo Jurgen Appelo: ¡Gestiona el Sistema y no a la gente! Por último hay que considerar que las métricas o KPIs se usan en función de metas, objetivos y propósitos. Los KPI solos y por si solos no sirve de mucho.

Referencias:

jueves, 23 de mayo de 2019

Agile Delivery: No es buena idea medir la productividad de los equipos con Velocity en Story Points




¿Cómo medimos la productividad TI de nuestros equipos ágiles? ¿Y si usamos Velocity? Y, como nuestros equipos trabajan con Scrum… ¿Si usamos Story Points? mmmmm... ¡NO! Usar puntos de historia o días ideales para medir la productividad es una muy mala idea (es como medir líneas de código). Claro que parece lo más fácil, pero será definitivamente una fórmula para el desastre. Vamos a hacer que los equipos bajen su rendimiento. ¿Por qué? Por lo siguiente: 

  1. Generará inflación y engaño: Hará que los equipos comiencen a inflar gradualmente el significado de un punto, perjudicando su estimación y degradando su trabajo. Recordemos que los puntos de historia son valores relativos, como una moneda, como el dólar. Si nos van a premiar por entregar más pesos, el equipo va a sentirse motivado y presionado para entregar los mismos dólares pero más pesos. Van a generar inflación. Quiere decir que un equipo inteligente, se dará cuenta de que si inflan gradualmente sus estimaciones en el transcurso de un año, alcanzarán su objetivo o incluso lo superarán, SIN entregar más valor a la organización. 
  2. Sacará el foco metodológico de Scrum: El aumento de la velocidad no es el objetivo de scrum, sino que es entregar software funcionando, valioso y de alta calidad al cliente de una manera sostenible. Querer entregar más puntos les saca el foco. Puede hacer también que comiencen a contabilizar puntos por cualquier cosas: por hotfix, por spikes, por trabajos de research, etc. 
  3. Disminuye la calidad: por la presión o necesidad de aumentar la velocidad los equipos harán concesiones para completar las historias adicionales necesarias para obtener los números más altos. Por entregar más dejarán de prestar atención a la calidad. Introducirán deuda técnica. Es decir que la calidad sufrirá inevitablemente cuando se toman este tipo de decisiones. Puede influenciar a bajar la vara de la definición de Terminado DoD para poder liberar puntos más fáciles. 
  4. Frena el aprendizaje: Si el equipo de scrum aprende algo nuevo sobre una historia, la velocidad puede subir o bajar dramáticamente. Los Story Points varían durante la madurez del equipo. El equipo no debe alterar el trabajo de aprendizaje hecho al estimar honestamente. Al motivar la velocidad por puntos de historia se penaliza el fallo, lo cual degrada el aprendizaje. El equipo no querrá fallar. Una estimación puede estar muy lejos de la realidad, es una ESTIMACIÓN. Fallar estimando sirve para aprender. Por otro lado el equipo no va a querer dejar tiempo para investigar o innovar, ya que ese tiempo lo pueden gastar en hacer puntos. 
  5. Generar competencia entre equipos en vez de colaboración: Cuando se miden puntos se suele caer en un intento de normalizar la velocidad entre varios equipos de scrum. Esto también es una muy mala idea. Esto puede hacer que los equipos se peleen por los puntos y a veces no quieran colaborar en puntos de otros equipos. Es una comparación sin sentido ya que los equipos de scrum tienen diferentes habilidades, objetivos, herramientas y enfoques para estimar el trabajo. Los Story Points son una métrica interna del equipo que le sirve para mejorar y autogestionar su trabajo. 
  6. Puede generar culto, miedos y odios a Scrum: hay equipos que podrían usar el Método Kanban en vez de Scrum y no usar Story Points y ellos se verían afectados. Y otros pueden llegar a odiar Scrum si lo ven como herramienta de presión y estrés.

Por último, recomiendo reflexionar acerca de... ¿Por qué queremos medir la productividad de los equipos? McGregor nos decía con su Teoría X que hay gerentes o subgerentes que piensan que: “a los empleados no les gusta el trabajo, hay que obligarlos, controlarlos, amenazarlos o incentivarlos para conseguir metas”. Esta idea puede llevar a medir y controlar a la gente. En cambio, en agilidad no es esa la idea. Jurgen Appelo nos dice en Management 3.0 que: debemos gestionar al sistema no a la gente. Sumando la Teoría Y (de McGregor) a gerentes, debemos asegurar las personas correctas, liderar, formar, desarrollar competencias, hacer crecer la estructura, facilitar el trabajo, generar condiciones, asegurar infraestructura y facilitar recursos para que los equipos desarrollen software de calidad y de valor. Las personas se dirigen y se autocontrolan si están comprometidas con los objetivos. Los desarrolladores se pueden convertir en personas que desarrollen productos extraordinarios, en equipos de alto rendimiento; si tienen la libertad de desarrollar su potencial y las condiciones necesarias para desarrollar un propósito.

O sea, finalizando, la premisa es: “gestionar el Sistema y no a la gente”. Y si gestionamos el sistema de desarrollo de software de los equipos, entonces necesitaremos medir rendimiento de nuestro sistema de desarrollo de software compuesto por nuestros equipos y su infraestructura. Para eso desde el punto de vista de NEGOCIO deberíamos usar KPIs de negocio que indique la entrega de valor; y para la perspectiva DELIVERY TI (tecnología) son recomendables otras métricas de Performance, no Velocity con Story Points.
En próximas notas recomendaré KPIs de Performance.

Saludos.

Referencias:




lunes, 29 de abril de 2019

Retrospectiva: Retro Team Mood - Estado de ánimo del equipo



Aquí les paso una retro clásica sobre estado de ánimo del equipo.

A) Al comienzo de la retro, preparamos un canvas según las siguientes preguntas:
  1. ¿Cuán alegre estuviste en este sprint (período)?
  2. ¿Cuán satisfecho estás con tu rendimiento (prestancia) en este sprint?
  3. ¿Cómo evalúas en promedio tu habilidad, colaboración y esfuerzo?
  4. ¿Cuán satisfecho estas con el output o los resultados (outcome) de este sprint?

B) Dejamos que el equipo coloque post-it en las 3 columnas del canvas. Otra opción es que coloquen palitos o puntos.

C) Luego conversamos sobre los post-its (o sobre la votación).

D) Cerramos con acciones posibles de mejora.

Referencias:

Retrospectiva: Retro Team Morale

Sumando retros...
Hay una métrica de equipo que podemos usar para medir la moral del equipo, la "Team Morale".

"La moral es el entusiasmo y la persistencia con que un miembro de un equipo se involucra en las actividades prescritas de ese grupo" (Manning, 1991).


La podemos medir con valores de 1 a 5 (como encuesta) y podemos usar la instancia de retrospectiva para hacerlo. También podríamos usar una retrospectiva para tratar el tema de moral del equipo con las mismas preguntas, aunque de forma más visual y de manera de conversación. Podemos usar los tres estados de felicidad en relación a la moral (cara feliz, neutra y triste). Podemos hacer una tabla como sigue en un tablero o canvas:



Preguntas
1
¿Me siento bien (siento que encajo) y
me siento fortalecido en mi equipo?



2
¿Estoy orgulloso del trabajo que hago
para mi equipo?



3
¿Estoy entusiasmado con el trabajo que
hago para mi equipo?



4
¿Encuentro el trabajo que hago para mi
equipo de significado y con propósito?




El equipo puede votar (nominar) con puntitos, líneas opostits.

También podríamos usar algo más físico para sensar el estado. Por ejemplo que todo el equipo forme un círculo...
 y ante cada pregunta que avancen un paso dentro del círculo si responden en forma felíz la pregunta (o sea que sucede alrededor del 100% lo que indica la pregunta), que se queden inmóbiles si es "mas o menos" (neutro) o que retrocedan un paso si no se cumple o responden carita triste.
En este último caso el Scrum Master o facilitador anota los resultados de cada pregunta.

Luego hacemos una ronda de conversación por cada pregunta profundizando el tema según amerite el caso.

Recuerda que un equipo motivado es un equipo más productivo y que trabajar en la motivación del equipo ayuda a construir seguridad psicológica, construyendo sentido de equipo y cohesión; que, en en consecuencia, impacta positivamente en los resultados del equipo. Es bueno trabajar en la moral del equipo, principalmente cuando percibimos que el equipo esta desmotivado.

¡Espero que les sea de utilidad!

Referencias:









jueves, 25 de abril de 2019

Retrospectiva: Impacto vs. capacidad



Esta vez traigo otra dinámica muy simple. Esta retrospectiva es para proponer acciones de mejora o nuevas ideas, que el equipo puede realizar o concretar con poco esfuerzo, por tener las capacidades de hacerlo y generar gran impacto en su forma de trabajo o en sus resultados.

El equipo dibuja en una pizarra cuatro cuadrantes con ejes de coordenadas como sigue:

(*También puede hacerlo en una mesa)

Pasos:

  1. El equipo se toma un tiempo para reflexionar y escribir en post-its acciones de mejora.
  2. Cada integrante pega sus post-its en el cuadrante que crea conveniente. Pensar:
    • ¿Cuán positivamente impacta la acción? 
    • ¿Cuánta capacidad tiene el equipo de hacer la acción con poco esfuerzo?.
  3. Conversan sobre los post-its y si tienen que reubicar alguno lo hacen.
  4. Eligen las acciones prioritarias.
  5. Deciden quién le hará seguimiento a las acciones (un guardián de las acciones).



¡Con mi compañero Lautaro y un gran equipo en Cencosud 2019!