ADKAR – El camino del cambio I

El día de hoy vamos a tratar las necesidades que se producen dentro de una organización cuando se quiere producir un cambio y que pasos se deberían de seguir para poder lógralo con éxito. Para ello os traigo un modelo de gestión de cambio focalizado en las personas que forman las organizaciones, dado que son ellas las lo ejecutan o crean la resistencia en contra. 

Lo primero que nos propone el modelo ADKAR es que el cambio se trata de un proceso complejo y hay que tratarlo como tal (no como si se tratara de un evento), siendo por ello necesario detectar todos los estados por los que debe de atravesar cada persona de la organización. Una vez detectados estos estados es necesario saber qué métricas utilizar y cómo impactar en cada persona en función del estado en que se encuentre para que el cambio se produzca con éxito.

Creo que como introducción esto sería lo básico, ya que no pretendo aburriros entrando a fondo, por lo que paso directamente a explicaros los pasos del modelo.

  1. Awareness (Consciencia)
    • Es muy importante no solo conocer las razones por que la una compañía quiere introducir un cambio, si no que es igual de importante que las personas en las que queremos impactar tengan un conocimiento pleno de las motivaciones y los beneficios que esto les brindará.
    • En este punto la empresa debe de ser plenamente transparente y comunicar al máximo nivel con personas que generen una alta confianza en los impactados. 
    • Es necesario hacerles participes de las finanzas o los datos de relevancia que nos motivan como empresa al cambio y que por norma general ignoran o no tienen acceso. Este punto no es trivial, ya que nos servirá para poder controlar rumores o la difusión de falsas motivaciones. Además, creará un ambiente de pertenencia y de importancia dentro del cambio generado.
  1. Desire (Deseo)
    • En este paso se tiene que abordar el interés que tiene las personas que pertenece a la organización motivándolo para querer y formar parte del cambio. Si las personas no sienten el cambio como una manera de mejora es muy probable que no encaje en el nuevo modelo, pero si muchas personas no desean este cambio es muy probable que estemos ejecutando mal nuestra tarea, por lo cual el cambio puede fracasar.
    •  Es necesario tener en cuenta los factores que pueden crear deseo en cada uno de las personas tales como: Obtención de beneficios, necesidad de formar parte de algo, confianza en un líder que promueve el cambio, comienzo de una situación futura, comprender que el resto de alternativas no aportan valor, comprender el valor que el cambio aporta, etc…
  1. Knowledge (Conocimiento)
    • Es el momento de formar a todos las personas que tienen que realizar los cambios dentro de la empresa. Un punto muy importarte dado que tienen que sentirse capacitadas y seguras de que pueden realizar sus nuevas funciones.
    • Si es posible siempre es positivo tener una persona guía que aconseje y resuelva dudas que muy probablemente surgirán una vez estén realizando las nuevas tareas.
  1. Ability (Habilidad)
    • Cada persona tiene una curva de aprendizaje diferente y esto debe de ser tenido en cuenta dado que las personas no aprenden solo por indicaciones o por recibir una formación, es necesario que interioricen toda la información y llevarla a la práctica.
    • Será importante que no se centre toda la formación en un inicio y después no vuelva a impartirse, esto puede llevar a malas ejecuciones o incluso que existan personas que no sean capaces de realizar el cambio.
  1. Reinforcement (Refuerzo)
    • Este ultimo punto es muy importante y se tiende a olvidar. Es necesario consolidar el cambio y es por ello que debemos de establecer una estrategia de recuerdo y de retroalimentación para poder adaptar el cambio y que este se produzca de manera correcta.

Como antes os comentaba quiero tratar este punto solo como introducción y podemos profundizar en un segundo post, donde también os mostraré la herramienta de control que ADKAR propone y como debe utilizarse. 

¡Cuidaros mucho y nunca dejéis de ser curiosos! 🙂

Scrum vs Kanban

Hola de nuevo, volvemos otro día con una nueva píldora y hoy me voy a meter en un buen lío (yo solito). Voy a hablar de… Scrum vs Kanban a vista de pájaro (of course).

La intención que tengo no es explicar todo sobre ellos, ni mucho menos, pero sí intentaré que entiendas para qué se puede utilizar cada uno, ya que son para cosas muy distintas.


Como siempre ras i curt!


Scrum: 

Visualizamos cómo puede ser el producto y vamos entregando con control de tiempo y de manera iterativa un incremento utilizable (compuesto siempre de los elementos (pbi) del Product Backlog de más valor en ese momento). No estamos buscando entregar el producto final acabado al 100% si no que vamos aportando partes / funcionalidades que aportan valor en base al mercado (controlando PKIs de control) y siempre con el cliente final en el foco, lo cual puede hacer que nuestro producto sea muy diferente a lo proyectado pero que tenga siempre el mayor valor para el usuario final.

Podemos decir que Scrum abraza y acepta la incertidumbre y nos entrega reglas para poder ir despejándola aportando además control sobre cuándo y qué partes del producto van a ser entregadas. También como resumen os escribo los pilares de Scrum (lo que dicen mucho de él) Transparencia, Inspección y Adaptación (siempre desde el empirismo).

Kanban: 

Busca visualizar todos los estados por los que tiene que pasar el valor o producto, para poder visualizar la información de lo que se está realizando en todo momento.

La intención es tener una transparencia total del proceso y poder mejorarlo haciéndolo más fluido (bajar el Lead Time), siendo una herramienta muy buena de detección de “cuellos de botella” y de ajuste de los mismos.  

En este aspecto Kanban busca la mejora en la producción y no la mejora en el producto ya que este está definido de inicio. 

Es una herramienta muy pero que muy versátil y puedes establecer priorización de tareas introduciéndolas en carriles, saber estados de carga de trabajo de personas o de equipos, limitar el número de tareas que hay en un determinado punto del proceso (valores máximos o mínimos y definir reglas que se aplicarán cuando se llegue a estos valores), mezclar varias métricas, etc… Es por ello que Kanban es muy poderoso.


Be smart!

Por regla general y creo yo que de manera muy inteligente, dentro de los equipos de desarrollo de Scrum se utilizan los tableros Kanban durante el Sprint (aunque creo que Kanban es «ese gran desconocido») ya que uniendo estas dos poderosas herramientas obtienes un pack inmejorable de transparencia y mejora continua.

El equipo utilizando Kanban puede controlar de muy buena manera el estado del Sprint Backlog (el trabajo que tienen pendiente de acabar dentro de ese Sprint) además de saber todo lo que hay en proceso para poder controlar las dependencias.

Pues hasta aquí la chapa del día de hoy 🙂 y espero que os sea muy muy útil.

Saludos y ¡hasta muy pronto!

SCRUM – 2020 NEW GUIDE

¡Hola a todos!

Hoy os traigo novedades importantes en SCRUM dado que la nueva guía que salió a la luz en  Noviembre 2020 y que fue modificada por los cocreadores de SCRUM, Ken Schwaber y Jeff Sutherland, ya ha entrado en vigor para todas las nuevas certificaciones, invalidando de esta manera la guía del 2017. 

Os dejo aquí el link de descarga a la nueva guía para que podáis revisarla. (¡no seáis vagos!)

Vamos a ver los cambios más sustanciales que he podido encontrar en una primera lectura (os daré mas información cuando la revise a fondo) y más abajo los cambios que remarcan dentro de la propia guía como importantes (ojo que no son los únicos).

Ya sabéis que, como siempre, para las certificaciones debéis revisar además de la guía los blogs de scrum.org, que aparte de ser muy interesantes, también sé extrae de allí información muy válida que puede aparecer dentro de los exámenes de certificación.

Pues sin entreteneros más, os dejo con lo prometido.

¡Hasta pronto! 🙂

Cambios entre las versiones 2017 y 2020 en una primera revisión:

Introducción de LEAN con la nueva descripción de Scrum: Scrum se basa en el emprimo y en el pensamiento Lean. El emprimo afirma que el conocimiento proviene de la experiencia y la toma de decisiones basadas en lo que se observa. El pensamiento ajustado reduce los residuos y se centra en lo esencial.

Nuevos elementos dentro de SCRUM Compromisos: 

Se formalizan de la siguiente manera:
1. Para el trabajo pendiente del producto (Product backlog) es el objetivo del producto (Product Goal).
2. Para el Sprint Backlog es el Sprint Goal.
3. Para el Incremento es la Definición de Hecho.
Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el equipo de Scrum y sus partes interesadas.

Liberación del incremento:

Este puede ser entregado/liberado antes del final del Sprint.

Sprint Planing:

Tiene una guía de trabajo y añade un nuevo topic a la reunión.
1. * ¿Por qué este Sprint es valioso?
2. ¿Qué se puede hacer este Sprint?
3. ¿Cómo se realizará el trabajo elegido?

Sprint Review:

1. Desaparece el guión especificado en la guía 2017

Equipo Scrum: 

1. Muy importante, cambia de entre 3 – 9 personas a 10 personas o menos

Cambios entre las versiones 2017 y 2020 de la Guía Scrum:

Aún menos prescriptivo

Con los años, la Guía Scrum se volvió cada vez más prescriptiva. La versión 2020 pretende que Scrum sea un marco mínimamente válido y suficiente, eliminando o suavizando su lenguaje prescriptivo. Por ejemplo, las preguntas se han eliminado del Daily Scrum, se ha suavizado el idioma relacionado con los atributos del elemento de trabajo pendiente del producto (Product Backlog), se ha suavizado el lenguaje relacionado con los elementos de la Retrospectiva para añadirlo al trabajo pendiente de sprint (Sprint Backlog) y se ha acortado la sección de cancelación de sprint, entre otros.

Un equipo, centrado en un producto

El objetivo era eliminar el concepto de un equipo independiente, lo que ha dado lugar a comportamientos de «proxy» o «nosotros y ellos» entre el propietario del producto (Product Owner) y el equipo de desarrollo. Ahora solo hay un equipo de Scrum centrado en el mismo objetivo, con tres categorías de responsabilidades: Product Owner, Scrum Master y Development Team (Desarrolladores).

Presentación del objetivo del producto

La Guía Scrum 2020 introduce el concepto de Objetivo de Producto, con la finalidad de permitir que el Equipo de Scrum se centre en un objetivo más grande y con más valor. Cada Sprint debe acercar el producto al objetivo de este.

Un espacio para el objetivo de Sprint, la definición de hecho y el objetivo del producto

Las guías anteriores de Scrum describieron el propósito del producto y la definición de hecho, (Definition of Done) sin reconocer realmente su identidad. No eran artefactos, pero estaban asociados con él de alguna manera. Con la inclusión del objetivo del producto, la versión 2020 proporciona más claridad a este respecto. Cada uno de los tres artefactos ahora contiene «compromisos» asociados. Para el trabajo pendiente del producto (Product Backlog), existe el objetivo del producto. El Sprint Backlog tiene como objetivo el Sprint, y el incremento tiene la definición de hecho (ahora sin comillas). Todos ellos existen para proporcionar transparencia y centrarse en el progreso de cada artefacto.

Autogestión en lugar de auto-organización

Las Guías Scrum anteriores se referían a los equipos de desarrollo como autoorganizados, eligiendo quién hizo el trabajo y cómo se hizo. La versión de 2020 presta más atención al equipo de Scrum, y hace hincapié en un equipo autogestionado de Scrum, que selecciona quién, cómo y dónde trabajar.

Tres temas en la planificación del sprint

La Guía Scrum 2020 añade y enfatiza un tercer tema «Por qué» en referencia al Objetivo del Sprint, más allá de los «Qué» y «Cómo» existentes.

Simplificación general del lenguaje para un público más amplio

La Guía Scrum 2020 ha hecho hincapié en la eliminación de frases redundantes y complejas, así como en la supresión de las influencias restantes en el mundo de las TIC (por ejemplo, pruebas, sistemas, diseños, requisitos, etc.). La Guía de Scrum 2020 ahora tiene menos de 13 páginas.

Pista: ¿Has seguido el link musical? 😛

S.C.A.M.P.E.R

Hola a todos de nuevo, hoy regresamos con otra pequeña píldora.

En esta ocasión se trata de una píldora que os puede ayudar en la ideación cuando llegamos a ese estado en el que todo está tapado por una gran niebla y no hay manera de avanzar hacia ninguna dirección.

Es un método que nos ayuda a pensar “out of the box” dándonos una guía para la ideación. Recordad que idear es una metodología y no magia 🙂  

Al lío que quiero que sea cortito:

SCAMPER es el acrónimo de:

Substitute, Combine, Adapt, Modify, Putt in other uses, Eliminate y Reverse.

El método es bastante sencillo de aplicar, ya sea en grupo (preferible) o de manera individual, ya que se trata de ir aplicando al reto definido preguntas sobre los conceptos que nos aporta SCAMPER. 

Es muy importante tener siempre en cuenta la sencilla regla de NO poner limites a los planteamientos y nunca descartarlos de entrada por muy locos que parezcan. 

Recordad que en Desing Thinking primero hay que divergir para luego poder converger.

Os dejo a continuación unas preguntas a modo de ejemplo sobre diferentes temas:

Substitute: ¿Podemos sustituir una parte para reducir costes?, ¿Podemos sustituir el material para que sea más resistente?, ¿Podemos sustituir el método de comunicación con los clientes?, ¿Podemos sustituir la subcontrata? ¿Podemos sustituir el cliente?

Combine: ¿Podemos unificar productos para poder obtener mas valor para el cliente?, ¿Podemos combinar áreas de la empresa para aumentar la productividad?, ¿Podemos combinar equipos para ser mas eficientes?, ¿Puede mi producto integrarse con un tercero para ganar valor?

Adapt: ¿Cómo podemos adaptar el producto a un target concreto?, ¿El proceso actual de venta es el más eficiente o se puede llegar directo al cliente con publicidad?, ¿Qué canales de publicidad hay disponibles?, ¿Debo adaptarme a otro circuito de publicidad?, ¿Cómo puedo adaptar el framework que utiliza X empresa a la mía?, ¿Puedo adaptar mi producto para que cumpla X función? (Sustituya la X por lo que más le guste 😛 )

Modify: ¿Puede mi producto satisfacer otras necesidades?, ¿Puedo modificar mis canales de comunicación internos para que los equipos sean mas transparentes?, ¿Qué parte de mi producto puedo modificar para que tenga un mayor valor?

Putt in other uses: ¿En qué otro contexto mi producto puede aportar valor?

Eliminate: ¿Se pueden eliminar procesos en la creación del producto?, ¿Se pueden eliminar procesos en la gestión interna?, ¿Se puede eliminar una parte del producto sin que este pierda valor?, ¿Se puede eliminar una parte del producto en el que tiene bajo valor, pero alto coste? 

Reverse: ¿El proceso de creación es el correcto? ¿El espacio de los equipos es el correcto o se necesita otra distribución? ¿Nuestro producto está bien ordenado o debemos cambiar como se presenta? ¿Podemos cambiar el flujo de facturación?

Espero que os pueda ayudar y recordad que la práctica hace al maestro… No tengáis prisa ni os frutéis si en un principio os parece complicado.

¡Feliz año a todos y nunca dejéis de ser curiosos!