jueves, enero 16, 2020

Diatriba: "by the book" una frase que me produce escozor




Hola a todos

Como algunos de ustedes saben, la mayoría de post los escribo tienen como objeto de dejar registro de mis experiencias y luego remitir a mis compañeros, jefes, estudiantes, y amigos,  a mi blog con miras a hacer reutilización del conocimiento,  gastar menos energía y de paso hacer un aporte a la comunidad.

Hoy quiero desahogarme, hacer un poco de catarsis, respecto a esta frase "BY THE BOOK",que me he encontrado en varias latitudes en este ejercicio de acompañar equipos y organizaciones. Por lo general, sson variaciones de las frases que han antepuesto a "by de book", veamos:

  • tus scrum masters son "by the book"
  • los equipos de transformación de ustedes son"by the book"
  • lo que ustedes me estan proponiendo es"by the book"
  • ese aseguramiento o assessment es "by the book"
  • tus agile coaches son "by the book"
  • tus consultores son "by the book"
y en el sentido estricto de la palabra voy a indagar,  el comentario no tiene nada de constructivo ni realista, la mayoría de las veces:
  • su mensaje principal respecto a nostoros "no sabemos que estamos haciendo", o "sabemos muy poco" (ese mensaje por lo general lo da la competencia)
  • su intención de plano es destructiva
  • busca garantizar de que no se hagan cambios o el "statu quo" (sí, es sin la "s" al final de statu)
  • su intención en la mayoria de los casos es :
    • mostrar desconfianza, 
    • generar descofianza, 
    • destruir y desacreditar cualquier observación que se haga
    • atacarme o atacar a "mi gente" por parte de la competencia:
      • que no entiende el proceso 
      • o que si lo entiende pero no le conviene que se hagan observaciones sobre su trabajo

Hagamos precisiones

Respecto a “saber poco”: cuando esto ocurre, somos profesionales y se lo aclaramos al cliente y conjuntamente decidimos acoger el riesgo. En tecnología siempre hay conocimiento nuevo. Sin embargo, cuando se va a indagar o a validar algo relacionado con las prácticas ágiles que lleva un equipo interno o externo, cosa a todas luces necesaria pues siempre queremos saber qué tan “correcto” lo estamos haciendo, lo primero que se pregunta es:

¿qué marco de trabajo siguen?

o ¿qué marco le han dicho al cliente que siguen?

y desde esa luz que los equipos mismos dan, se comienza a identificar si realmente eso que dicen ejecutar lo están haciendo y en qué nivel de "shu-ha-ri"(ver imagen) se encuentran.


"
Un ejemplo del "ataque" que comunmente recibimos, son de las personas, equipos u organizaciones que hacen el "scrumbut"(3):
  • hacemos scrum pero no hacemos retrospectiva
  • hacemos scrum pero no tenemos definition of done
  • hacemos scrum pero no hacemos pruebas
  • hacemos scrum pero el sprint backlog no esta definido
  • hacemos scrum pero no hacemos planning
  • hacemos scrum pero no tenemos review
todos esos scrumbut, o scrum pero, realmente implica que NO se está haciendo haciendo scrum, con razon dice la frase, que aparece en la misma guía oficial:

"scrum es liviano, fácil de entender, dificil de dominar"(2)
para terminar los dejo con dos interesantes recursos:
  • la lista de chequeo de scrum elaborada por Henrik Kniberg (3) y traducida por migran amigo Lucho Salazar (4) (que justo comienza validando con lo esencial - validando si se está en nivel "ha" o "ri", que es entregar software de valor de manera frecuente y tener u proceso de mejora continua y luego se va a la validación de marco)

  • y la leyes de Compartamiento Organizacional de Larman(5) traducidas por Hiroshi Hiromoto(6)


1. Las organizaciones están implícitamente optimizadas para evitar el cambio del statu quo de las posiciones y estructuras de poder de los mandos medios y de primera línea y de “especialistas”.
2. Como corolario de (1), cualquier iniciativa de cambio será reducida a redefinir o sobrecargar la nueva terminología para que signifique básicamente lo mismo que el statu quo.
3. Como corolario de (1), cualquier iniciativa de cambio será ridiculizada como “purista”, “teórica”, “revolucionaria”, “religión”,"BY THE BOOK"(7), y “necesitada de una customización pragmática para preocupaciones locales” — que desvía de atender las debilidades y el statu quo del manager/especialista.
4. Como corolario de (1), si luego del cambiar el cambio algunos managers o especialistas son desplazados, ellos se convierten en “coaches/entrenadores” para el cambio, frecuentemente reforzando (2) y (3).
5. La cultura sigue a la estructura (Culture follows structure)


Por lo tanto, si eres cliente, o proveedor y alguien se te acerca con el 

"BY THE BOOK"

en su discurso, te sugiero revises:
  • si es un sesgo cognitivo (o prejuicio que llamábamos hace un tiempo)
  • realmente no se tiene conocimiento y es una primera aproximación (esto se resuelve validando experiencias previas en otras organizaciones y contextos)
  • realmente estan evaluando el nivel  "SHU" o aprendiz de algo o alguien, y lo primero que se valida es si sigue las reglas minimas
  • o es una maniobra de "alguien" para destruir la confianza en la estrategia o en una persona, equipo u empresa y salvar su propio pellejo.

Hasta aca esta diatriba, y desahogo

saludos ágiles
Jorge Abad

Notas, aclaraciones, comentarios

lunes, diciembre 30, 2019

Tabla Comparativa de la Triple Restricción (Alcance, Tiempo y Presupuesto) y su Compatibilidad para Contratos Ágiles

Hola a todos

Desde hace un tiempo tenía este pendiente, estas fichas técnicas y tabla comparativa de la triple restricción (alcance, tiempo y presupuesto) en un contrato y como esta puede ser usada para entornos de contratación ágil.


Tipo de contrato
Afinidad con Ágil
Alcance =fijo  
Tiempo= fijo
Presupuesto= fijo
baja

Ejemplos
Alcance= 70 funcionalidades
Tiempo= 3 meses
Presupuesto= 100.000 dólares
Alcance= 2000 funcionalidades
Tiempo= 18 meses
Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente)

- Contratar por tiempos máximos de 3 meses, ojalá menos.

- Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato

- Priorice* las funcionalidades al momento de construirlas.
Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el tiempo y presupuesto determinado.

Entre más grande el proyecto o iniciativa peor será este impacto.
- Un alcance fijo no es buena práctica en un mundo VUCA(1).

- Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato
Afinidad con Ágil
Alcance =fijo  
Tiempo= fijo
Presupuesto=Variable
Media-baja

Ejemplos
Alcance= 70 funcionalidades
Tiempo= 3 meses
Presupuesto= lo que cueste
Alcance= 2000 funcionalidades
Tiempo= 18 meses
Presupuesto= lo que cueste
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente)

- Contratar por tiempos máximos de 3 meses, ojalá menos

- Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato
- Priorice* las funcionalidades al momento de construirlas.

- Priorice* las funcionalidades al momento de construirlas.
Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, tiempo determinado

Entre más grande el proyecto o iniciativa peor será este impacto
- Un alcance fijo no es buena práctica en un mundo VUCA.

- Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

- Es posible que por contar con presupuesto ilimitado trate de cerrarse el proyecto o iniciativa por fuerza bruta, pero es probable que "ni todo el dinero del mundo" ni los recursos alcancen a cerrarlo en la fecha pactada

Tipo de contrato
Afinidad con Ágil
Alcance =fijo  
Tiempo=Variable
Presupuesto=fijo
Media-baja

Ejemplos
Alcance= 70 funcionalidades
Tiempo= lo que se demore
Presupuesto= 100.000 dólares
Alcance= 2000 funcionalidades
Tiempo= lo que se demore
Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente)

- Contratar por tiempos máximos de 3 meses, ojalá menos

- Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato

- Priorice* las funcionalidades al momento de construirlas.
Es muy probable que la estimación este mal hecha y no se logre a construir las funcionalidades pactadas, en el presupuesto pactado.

Entre más grande el proyecto o iniciativa peor será este impacto
- Un alcance fijo no es buena práctica en un mundo VUCA.

- Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato
Afinidad con Ágil
Alcance =fijo  
Tiempo= variable
Presupuesto=variable
Media-alta

Ejemplos
Alcance= 70 funcionalidades
Tiempo= lo que se demore
Presupuesto=lo que cueste
Alcance= 2000 funcionalidades
Tiempo= lo que se demore
Presupuesto=lo que cueste
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
- Realizar contratos pequeños (reducen riesgos de estimación y de insatisfacción del cliente)

- Contratar por tiempos máximos de 3 meses, ojalá menos.

- Lograr software funcionando y probado en el ambiente más cercano a producción en cada contrato

- Priorice* las funcionalidades al momento de construirlas.
-Posiblemente no se logre resolver el problema pues el alcance fijo no garantiza que se construya lo que resuelve el problema
'- Un alcance fijo no es buena práctica en un mundo VUCA.

- Si el alcance es fijo, es poco o nada compatible con ágil, debido a que no está abierto al cambio.

Tipo de contrato
Afinidad con Ágil
Alcance =variable  
Tiempo= fijo
Presupuesto=fijo
Alta-baja

Ejemplos
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= 3 meses
Presupuesto= 100.000 dólares
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= 18 meses
Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance.

- Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto

- Pacte releases de software funcionando.

- Ojalá esos releases sean máximo cada tres meses

- Lograr software funcionando y probado en el ambiente más cercano a producción en release

- Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el tiempo o el presupuesto, construyó lo de mayor valor primero
-Posiblemente no se logre resolver el problema con esas dos restricciones
-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios

- Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato
Afinidad con Ágil
Alcance = variable
Tiempo= variable
Presupuesto=fijo
Alta-media

Ejemplos
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= Lo que se demore
Presupuesto= 100.000 dólares
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= Lo que se demore
Presupuesto= 3.000.000 dólares
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solución para que valide constantemente la construcción del alcance.

- Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto

- Pacte releases de software funcionando.

- Ojalá esos releases sean máximo cada tres meses

- Lograr software funcionando y probado en el ambiente más cercano a producción en release

- Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el presupuesto, construyo lo de mayor valor primero
-Es posible que no se logre resolver el problema con esa restricción
-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios.

- Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato
Afinidad con Ágil
Alcance =variable
Tiempo= fijo
Presupuesto=variable
Alta-media

Ejemplos
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= 3 meses
Presupuesto= lo que cueste
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= 18 meses
Presupuesto= lo que cueste
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance.

- Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto

- Pacte releases de software funcionando.

- Ojalá esos releases sean máximo cada tres meses

- Lograr software funcionando y probado en el ambiente más cercano a producción en release

- Priorice* las funcionalidades al momento de construirlas, de forma que si se acaba el el tiempo, construyo lo de mayor valor primero
-Es posible que no se logre resolver el problema con esa restricción.

Es posible que como se cuentan con presupuesto sin restricciones, se trate de cerrar el proyecto o iniciativa en la fecha pactada, pero ni aun así se logre el objetivo
-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios.

- Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI

Tipo de contrato
Afinidad con Ágil
Alcance =variable  
Tiempo= variable
Presupuesto=variable
Alta-alta

Ejemplos
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= lo que se demore
Presupuesto= lo que cueste
Alcance=
- Lo de mayor valor
- Lo que resuelva el problema de negocio
Tiempo= lo que se demore
Presupuesto= lo que cueste
Recomendación para Ejecución Ágil
Riesgos
Notas Generales
-Se requiere involucramiento del area usuaria o del cliente que va a usar la solucion para que valide constantemente la construcción del alcance.

- Tenga una versión temprana del producto (MVP-Miínimo Producto Viable), con la minima cantidad de alcance,  lo antes posible que valide si vale la pena seguir construyendo el producto

- Pacte releases de software funcionando.

- Ojalá esos releases sean máximo cada tres meses

- Lograr software funcionando y probado en el ambiente más cercano a producción en release

- Priorice* constantemente las funcionalidades al momento de construirlas, que se garantice el mayor impacto
 - No realizar una ejecución ágil del proyecto o iniciativa
-La priorización por valor y las entregas tempranas permitirán reducir el riesgo del producto por parte de los usuarios.

- Se sugiere tener mentalidad de inversionista y no de gestión de costos en este enfoque, de forma que se pueda finalizar o continuar invirtiendo en función de la generación de ROI


* Se sugiere emplear la técnica de WSJF - weighted shortest job first




Puedes descargar en formato PDF aquí


Como siempre, bienvenida la retroalimentación

Saludos Ágiles

Jorge Abad.


Notas, Aclaraciones, Comentarios, Referencias y  Observaciones.

  1. VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en  https://es.wikipedia.org/wiki/VUCA




Dos Errores Comunes en las Historias de Usuario




Hola a todos

Aunque a través de varios escritos y post (1) he compartido que el formato de las historias de usuario es un formato libre,  pues

"cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."
Pero, si un equipo se siente cómodo empleando la plantilla popularizada(2) por Mike Cohn,


Yo como _____ROL____
Deseo____UNA FUNCIONALIDAD___
Para_______BENEFICIO DE NEGOCIO__

La cual es ampliamente usada, ¡pues está bien!, ¡no hay lío con eso!.

Ahora, respecto a esta plantilla (la de Mike Cohn) quisiera compartirles dos errores frecuentes que he observado acompañando equipos de diferentes organizaciones:

El Primero, cuando se pone la historia de usuario en voz del Product Owner

Yo como _____PRODUCT OWNER____
Deseo____REGISTRAR LOS EGRESOS MENSUALES_  
Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____


Y El Segundo, cuando ponemos la historia de usuario en voz del área funcional que la solicita

Yo como __VICEPRESIDENCIA FINANCIERA__ Deseo____REGISTRAR LOS EGRESOS MENSUALES____ 
Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____



La Forma Correcta es escribirla en voz de la persona que hace clic en el sistema, es decir, de quien usa la funcionalidad, que en este caso sería el SOLICITANTE DEL PRÉSTAMO, quedando la historia de usuario "bien escrita" de la siguiente forma:

Yo como _____SOLICITANTE DE PRÉSTAMO__ 
De
seo____REGISTRAR LOS EGRESOS MENSUALES____ 
Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____
 

Hasta acá este compartir

Saludos Ágiles
Jorge Abad



Referencias, Notas, Aclaraciones y Comentarios

  1. Algunas referencias son:
  2. La plantilla fue desarrollada por Rachel Davies en la compañía Connextra de Inglaterra, en 2001, pero luego la popularizó Mike Cohn junto a otros entusiastas del modelo.

domingo, diciembre 22, 2019

Mis notas sobre la charla "El Corazón de la Agilidad" de Alistair Cockburn

Hola a todos

Hace poco mi gran amigo y líder técnico Daniel Ramirez, publicó las notas de la sesión que asistimos sobre el Corazon de la Agilidad de Alistair Cockburn - en Pragma el pasado mes de noviembre de 2019 -  https://contactosagiles.co/aoc-colombia-2019/el-corazon-de-la-agilidad/ -, yo también dejar un pequeño registro de ciertas frases contundentes que nos compartío Alistair en esta excelente sesión:








El corazón de la agilidad se basa en:
  • colaboración
  • entrega
  • reflexión
  • mejora

Combinando estas palabras se obtiene
  • colabora para entregar
  • entrega para reflexionar
  • reflexiona para mejorar
  • mejora la colaboración
  • colabora para mejorar
  • colaboramos para tener mejores ideas
  • entrega para aprender
  • la mejora reflexiva (es la inspección y adaptación de scrum)
  • pausa para reflexionar (obvio no es una combinación)
  • mejora para cambiar el mundo (obvio no es una combinación)
  • mejora el sistema de entrega

Los tres estados del aprendizaje
  • Shu - seguir la técnica
  • Ha - agregar técnicas diferentes, romper la regla
  • Ri-  dejar el dojo

Concepto clave Kokoro:
  • esencia o corazón de algo
  • simplificación radical de conceptos

Al hacer una transformación en una organización se debe buscar:
  • no intentar cambiar la cultura
  • aumentar la confianza
  • reducir el miedo
  • mejorar la interacción
  • mejorar el sistema de entrega
  • mejorar la conversación entre las personas

Respecto a la gerencia de proyectos y a los errores
  • una empresa es una fábrica de ideas
  • una idea es precursora de una decisión
  • las decisiones son las molécula de lo que hacemos y entregamos al mundo
  • cada producto tiene mas de 100.000 decisiones
  • cada decisión es una posibilidad de error
  • El "ARTE" de la gerencia de proyectos se basa hoy en día en DESCUBRIR LOS ERRORES LO MÁS TEMPRANO POSIBLE
  • debido a lo anterior, entregamos lo antes posible para obtener feedback y evitar avanzar en la dirección equivocada


Preguntas para mejorar un equipo, un área, una organización:



Qué hacemos para:
- Mejorar nuestra colaboración
- Mejorar nuestra reflexión
- Mejorar nuestra reflexión
-Mejorar nuestra mejora




Notas y frases varias:
  • si mi mundo es de contratación tradicional, es decir, alcance tiempo y costo fijo, sugiere hacer contratos de tres meses para poder adaptarnos dentro de esas restricciones
  • Valor: el cliente sabe lo que es valor
  • Una empresa será más ágil entre más NATURAL le podas dar MALAS NOTICIAS AL JEFE
  • Debemos mejorar la conversación entre las personas
  • el corazón de la agilidad es un recordatorio, no un proceso
  • "Show me the feedback loops"
  • Una métrica importante: ¿cuántas veces por dia o semana se interrumpe el trabajo del desarrollador?
  • "Todo lo que se diga puede ser malinterpretado o malutilizado y no se puede escoger cual de ellos dos sucederá"
  • "El corazón de la agilidad está en descubrir los errores y dar las malas noticias"
  • SAFe que es nivel shu
  • La resistencia al cambio es normal
  • Cambia poco a poco


Otras imágenes de su pasada por Medellín

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272
"Nuestro trabajo en la Agilidad es dar las malas noticias temprano, simplemente porque es menos costoso"
---- 
"Agilidad es encontrar errores más rápido, y si no se los podes contar a tu jefe y virar, ¿para qué haces Agilidad?
---- 

Tomado de: https://twitter.com/claudytoscano/status/1198794111735734272

Tomado de: https://twitter.com/pablitux/status/1198710728707973121



Hasta acá este compartir


Saludos ágiles

Jorge Abad

Tweet: Más valor menos trabajo



#hormigasagilistas "EP16 — PMO Agile y Métricas con Jorge Abad"

Hola a todos

Les comparto esta interesante conversación sobre PMO Agile y Métricas que tuve la oportunidad de compartir con mis amigos de Hormingas Agilistas, Felipe Talavera y Rodrigo Burgos.


Estas son sus redes sociales
Facebook - https://www.facebook.com/HormigasAgilistas/
Linkedin - https://www.linkedin.com/feed/hashtag/?keywords=%23HormigasAgilistas
Twitter - https://twitter.com/HormigasPodcast

Espero la disfruten tanto como nosotros


Saludos ágiles
Jorge Abad

   





sábado, diciembre 14, 2019

El Agilismo en la Seguridad y Salud en el Trabajo - Jirafas en el Everest

Les comparto esta interesante conversación con mi gran amigo Hugo Londoño, director de innovación de Cultura Segura
Disfrútenla tanto como nosotros
Gracias Hugo y equipo de Cultura Segura. Fue un gran honor.


viernes, diciembre 13, 2019

Una herramienta para comparar culturas, basada en Reinventar Organizaciones de Laloux

Tomado de (1)

Hola a todos

Hace poco con la ayuda de mi compañera Ivonne Delgado, logramos tabular el mapa de https://www.facebook.com/groups/reinventing.organizations.map/ en donde se muestran los diferentes aspectos de las  culturas que caracterizó Frederic Laloux en su Libro Reinventar Organizaciones (2)(3), con el objetivo de poder usarlo en evaluaciones culturales.

Las culturas que agrupó Laloux en su libro son:

Impulsivo-Rojo
Bien adaptado a ambientes caóticos pero inadecuado para lograr resultados complejos en ambientes estables.

Valores:
  • Autoridad de comando, división del trabajo

Conformista-Ambar
Puede Planear a largo plazo y crear estructuras organizacionales que son estables y escalan.

Valores:
  • Perspectivas a largo plazo, tamaño y estabilidad, roles formales, procesos

Logro-Naranja
La eficacia reemplaza la moral. Cuanto mejor entiendo la forma de operar, más puedo lograr.

Valores:
  • Innovación, meritocracia, rendición de cuentas.

Pluralista-Verde
Busca justicia, igualdad, armonía, comunidad, cooperación y consenso. Insiste en que todas las perspectivas merecen igual respeto.

Valores:
  • Empoderamiento, cultura dirigida por valores, perspectivas de múltiples involucrados.


Evolutivo-Teal
Puede aceptar que hay una evolución de la consciencia, que hay un impulso en la evolución hacia formas más complejas de tratar el mundo.

Valores:
  • Propósito evolutivo, integridad, autoorganización.





Estas diferentes culturas conviven en una organización, pero una es más predominante que las otras. Justo para entender como estaba esa distribución actual y cual es la distribución deseada por un subconjunto o muestra de la organización,  se construyo este instrumento.

Para lograr esto, se armaron dos formularios de google docs, uno que pregunta sobre el estado actual de la cultura y otro que pregunta sobre el estado deseado.



Sobre 20 aspectos o rasgos de cultura:
  • conocimiento habilidades comportamiento        
    • estilo de liderazgo
    • toma de decisiones
    • desarrollo personal
    • resolución de conflictos
    • reuniones
  • productos procesos y estructuras            
    • estructura de la organización
    • proceso
    • flujo de información y comunicación
    • eficiencia de recursos
    • salario
    • productos y servicios
  • valores cultura y relaciones        
    • relación con involucrados
    • actitud hacia el trabajo
    • visión y valores centrales
    • clima de trabajo
    • lealtad
  • pensar sentir actitud      
    • miedo
    • actitud durante el contacto
    • motivación interior, impulso a manifestarla
    • conciencia de uno mismo

Estos formularios se pusieron a apuntar a un archivo de google docs, que los tabula y resume.

En el siguiente link puedes encontrar la carpeta de google docs donde hay una copia de los formularios y de la hoja de calculo


o descargar el excel que tambien contiene esta misma lógica
No dudo que jugando un poco logres entender como estan organizados los formularios y  la hoja de calculo de google y los resultados obtenidos.


Los Resultados

Con un grupo de amigos realizamos una pequeña simulación y de allí obtuvimos los siguientes resultados.





Lo cierto, es que las veces que he usado instrumentos similares los rasgos culturales actuales y deseados tienden a ser los mismos, pues la mayoría de nuestras organizaciones son jerárquicas, orientadas a procesos y al logro, y por lo general deseamos organizaciones dirigidas por el propósito con más autoorganización.


Cerrando

Aun falta perfeccionar la herramienta, si encuentras algún error no dudes en compartirlo. 

Y si la usan dejen su nota en los comentarios, hagan un post, o pongan un link con su análisis referenciando este post y este instrumento.


Bienvenido el feedback


Saludos ágiles

Jorge Abad



Comentarios, Referencias, Notas y Aclaraciones

  1. Photo on Visual Hunt
  2. https://www.reinventingorganizations.com/
  3. Libro que recomiendo ampliamente si estas interesado en colaborar o trabajar en procesos de cambio organizacional