Mostrando las entradas con la etiqueta reflexiones. Mostrar todas las entradas
Mostrando las entradas con la etiqueta reflexiones. Mostrar todas las entradas

domingo, septiembre 22, 2024

De la Era del Conocimiento a los Albores de la Era del Pensamiento Crítico. Como la GenAI nos Dividirá entre Consumidores y Pensadores.

Imagen generada por DALL-E

Imaginemos un mundo sin retroexcavadoras. La construcción de cualquier edificio requeriría horas, días o incluso semanas de trabajo manual para excavar las cimentaciones. La llegada de estas máquinas no solo transformó la manera en que construimos, sino que liberó a las personas para realizar trabajos de mayor valor. De manera similar, la aparición de las calculadoras y, más adelante, las computadoras, revolucionó nuestra capacidad para realizar cálculos complejos en segundos, desplazando la necesidad de realizar operaciones mentalmente o con herramientas rudimentarias. Internet, por su parte, ha conectado al mundo en una vasta red de servicios y conocimientos al alcance de un clic. Ahora, en esta línea de evolución tecnológica, surge la Generative AI (GenAI), prometiendo transformar no solo lo que hacemos, sino también cómo pensamos y tomamos decisiones.

La GenAI no es solo una herramienta más. Es un asistente capaz de procesar volúmenes masivos de datos, sintetizarlos y proporcionar información relevante en tiempo real. Para muchas personas, la respuesta a cualquier pregunta compleja estará a un simple “espera un momento, déjame preguntarle a la GenAI.” Esto crea un nuevo paradigma, donde la habilidad más valiosa será saber cómo interactuar eficazmente con estas herramientas, convirtiéndose en un maestro en el arte de formular preguntas y evaluar respuestas.

Sin embargo, hay un matiz importante que no debemos pasar por alto: el verdadero poder no radicará únicamente en el acceso a la información procesada por la GenAI, sino en la capacidad de contextualizarla, de interpretarla con criterio propio y de integrarla en un marco de pensamiento crítico. La GenAI será, en muchos sentidos, como una calculadora para el pensamiento; una herramienta poderosa para quienes ya poseen una sólida base de conocimientos y experiencia. Pero aquellos que se limiten a depender exclusivamente de ella, sin desarrollar su propio criterio, estarán delegando no solo el acto de pensar, sino también la capacidad de decidir con autonomía.

La humanidad se dividirá nuevamente en dos: quienes consuman la GenAI sin objeción, utilizándola para todas sus actividades, y quienes respondan en tiempo real a las preguntas del entorno, apoyándose en la GenAI para validar, complementar, rechazar o afirmar su punto de vista. ¿Quién te daría más certezas para producir resultados asombrosos? ¿Alguien que diga: "espera, le pregunto a la GenAI," o alguien que, sin titubear, responda tu pregunta y cuestione tus argumentos?

Existen grandes riesgos de que nos volvamos perezosos para tareas que impliquen análisis y un compromiso intelectual. El uso indiscriminado de la GenAI podría llevarnos a una dependencia que limite nuestra capacidad de pensar por nosotros mismos. La facilidad para obtener respuestas rápidas y precisas podría desincentivar el esfuerzo mental necesario para enfrentar problemas complejos, llevando a una sociedad que consume conocimiento sin digerirlo ni transformarlo.

Es aquí donde entra en juego la importancia de las habilidades humanas que la tecnología no puede reemplazar: la experiencia, el juicio y la capacidad de cuestionar y reflexionar. Así como las retroexcavadoras no convirtieron a los obreros en innecesarios, sino que los liberaron para trabajar en tareas más avanzadas, la GenAI puede liberar a las mentes humanas para enfocarse en problemas de mayor complejidad y creatividad. Aquellos que logren construir sus propios esquemas mentales, bebiendo de libros, experiencias y conocimientos disponibles, y que además se atrevan a desafiar sus propias convicciones en un entorno en constante cambio, serán quienes dominen este nuevo mundo.

Este amanecer tecnológico plantea una disyuntiva para la humanidad: ¿nos limitaremos a consumir información sin digerirla, sin cuestionarla, sin transformarla? ¿O asumiremos el reto de comprender realmente el mundo que nos rodea, usando la GenAI no como un sustituto del pensamiento, sino como un catalizador para llevar nuestro intelecto a nuevas alturas? La decisión está en nuestras manos, y lo que hagamos con este poder determinará no solo nuestro futuro, sino también el papel que desempeñaremos en esta nueva era que apenas comienza.

Así, la era de la GenAI nos desafía a ser más humanos que nunca, a no delegar el pensar, sino a abrazar nuestra capacidad de razonar, de cuestionar y de decidir. Porque en este nuevo mundo, no será quien tenga acceso a más datos el más fuerte, sino quien sepa cómo usarlos, integrarlos y, sobre todo, quién se atreva a pensar por sí mismo.

Saludos ágiles,

Jorge Abad.


Enlace a Linkedin, por si deseas participar allí del debate: clic aquí.

sábado, agosto 24, 2024

Registro de una conversación reveladora: características de los equipos y culturas de alto desempeño

Esta es una pequeña nota, donde dejo registro de una conversación reveladora que tuve con mi gran amigo Juan Andrés Ochoa, algoque hemos ido construyendo mutuamente:

Los equipos de alto desempeño cuentan con cuatro características:

  • Personas idóneas, es decir, son apropiadas para hacer la misión que se les va a encomendar.
  • Propósito.
  • Métricas que les muestren si están en el alto desempeño. Estas pueden ser tempranas y rezagadas, o un indice que combine ambas, es decir, en el caso de los equipos ágiles, soy un equipo ágil si impacto al negocio, entonces cuáles son las métricas que determinan que tengo agilidad (incluida, obviamente la excelencia técnica) y cuáles son las métricas que determinan que sí estoy impactando el negocio.
  • Una narrativa de cultura que proporcione un marco de actuación, que le cuente al equipo:
    • Lo que NO se espera del equipo, ejemplos: 
      • que no se gestione la deuda técnica, 
      • que no se asista a los eventos,
      • que no se respete a las personas.
    • Lo BÁSICO que se espera del equipo, ejemplos:
      • que cumpla sus compromisos,
      • entregue trabajo con excelencia,
      • se den retroalimentación mutua,
      • que reciban sin problema retroalimentación externa.
    • Lo EXTRAORDINARIO que se espera del equipo, ejemplos:
      • Investigar nuevas formas de hacer las cosas,
      • hacer de la innovación una forma de trabajo,
      • traer nuevos negocios a la empresa.
Lo anterior, se puede extrapolar al resto de la empresa cuando la vemos como un gran equipo conformado de equipos.

domingo, febrero 06, 2022

Retorno a la inocencia. Una invitación a compartir conocimiento

Hace poco hablaba con un gran amigo y agile coach, Carlos Palacio, sobre la necesidad de ser inocentes e ingenuos a la hora de escribir, y observábamos lo importante de liberarse de la carga de satisfacer a todos cuando estamos compartiendo conocimiento.

Y en esa conversación recordé que una de mis motivaciones para tener este blog era así, sencilla e ingenua: "ayudar a otras personas con lo que yo he experimentado y devolver un poco de lo que he recibido al leer a otros".

Reconozco que he crecido como bloguero y referente por este acto, por estas ganas de retribuir lo que he ganado al leer (escuchar y ver) a otros en el mundo de la agilidad y los negocios y llevarlo a mi empirismo; y hoy quiero escribirte a ti, que de vez en cuando me lees o que por suerte te topaste con esto y tienes ganas de compartir conocimientos y experiencias, pero sientes miedo a ser criticado o cuestionado, pues bien, deseo animarte y decirte que estoy seguro de que has vivido cosas que a otros le van a servir, que tu punto de vista les enriquecerá, les hará crecer, y les darás ideas para muchas circunstancias, no importa que alguien más lo haya hecho antes, tu mirada es única, valiosa e irrepetible..

Todos ganamos con el conocimiento de todos, nos apoyamos y generamos una gran red que nos impulsa a llegar más lejos. Yo, estaré ansioso de leerte y agradecerte por también ayudarme en mi camino. Como lo escribió Newton:

"Si he visto más lejos ha sido porque he subido a hombros de gigantes" Atribuida a Newton (1)(2)

Saludos ágiles

Jorge Abad



Notas y Comentarios

  1. https://es.wikipedia.org/wiki/Pararse_sobre_hombros_de_gigantes
  2. Dos recomendaciones: usa referencias cuando emplees cosas de otros y revisa la ortografía, ambas prácticas darán profesionalismo y estructura a lo que compartes.

miércoles, septiembre 29, 2021

Ágil es - Agile is



    
   "Ágil es:
        Definición continua,
            Desarrollo continuo,
                Despliegue continuo y
                    Validación continua de valor"



    "Agile is:
             Continuous definition,
                 Continuous development,
                     Continuous deployment and
                         Continuous value validation" 



   

domingo, septiembre 27, 2020

Cita: Siempre que haya miedo, obtendrás los números equivocados - Deming



"Siempre que haya miedo, obtendrás los números equivocados" Deming

 

--
 cita de "Accelerate" 

"As Deming said, ’whenever there is fear, you get the wrong numbers’ "http://a.co/g8vh4FE


-----
De lo que también se puede inferir

"Donde hay miedo, no habrá transparencia"
----

Para la Reflexión 

  • ¿Te temen?
  • ¿Tu liderazgo es desde el temor?
  • ¿Qué tipo de liderazgo ejercen las personas que te reportan y tienen equipos a cargo?
  • ¿Tu jefe te produce temor? 
  • ¿En el área u organización en la que te encuentras, las relaciones son relaciones basadas en el temor?

Saludos ágiles
Jorge Abad

sábado, septiembre 05, 2020

Reflexión sobre la Agilidad

"La Agilidad requiere entornos de abundancia, donde se comparta, se confíe, se aprenda y se vea el fracaso como una oportunidad."

lunes, agosto 10, 2020

Dos Preguntas (Casi Tres)

Veo con frecuencia tantas implementaciones cojas de Agile y DevOps, que en vez de burlarme de ellas y de los implementadores - como lamentablemente lo observo en las redes - quiero hacerle estas dos preguntas a los que son clientes:


Pregunta 1: ¿Cuando #Agile y #DevOps sean el estado del arte en tu organización y de la industria, es decir un commodity, por fin te vas a decidir a innovar y a poner realmente al negocio liderando equipos agiles enfocados en generarle valor al cliente? ¿No crees que será muy tarde?


Pregunta 2: ¿Basado en lo anterior, para cuándo te vas a decidir a hacer #Agile y #DevOps en serio, o vas a dejar que tu competencia te tome ventaja en ello?


Abro la discusión, si lo deseas en la zona de comentarios, o en mis redes sociales:


domingo, mayo 17, 2020

En Qué Radica el Éxito de la Transformación Ágil: Un Pensamiento Sobre la Batalla de los Frameworks de Escalado de Ágil

Te recomiendo visitar la versión mejorada de este artículo: http://www.lecciones-aprendidas.info/2020/06/en-que-radica-el-exito-de-la-transformacion-agil.html

Tomado de (1)

Hola a todos

Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado, algunos temas recurrentes son:
  • organizaciones pagan millones de dolares a las consultoras top para que al final de tres meses que les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2)
  • discutimos sobre cuáles son los beneficios y falencias de cada uno, cuál es más prescriptivo y cuál es más adaptativo
  • comparamos sus estrategias de gestión del cambio
  • confrontamos cual framework es más exitoso, o que autor prominente lo creo, promulga o defiende, 
Pero luego de desgastarnos un rato en discusiones bizantinas, pues todos los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican orgullosos en sus páginas, pero que luego "despublican" cuando se vuelven fracasos, concluimos que son muchos los factores que compiten o colaboran entre sí, para lograr el éxito o el fracaso.

Factor
Hacia el éxito
 Hacia el fracaso
Compromiso del Top-Management
·       alto compromiso e involucramento
·         Delegación completa y desentendimiento
Gestion el cambio organizacional
·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.
·       Fija y predictiva
procesos y contratos
·       Modificados y en continua mejora hacia la agilidad
·       Sin modificar y orientados a la culpa en vez de la colaboración
Respecto a los líderes y al mindset
·        Capacitados y empoderados para compartir el mindset
·        La difusión del mindset es de lagada en los consultores y algunos roles 
Tolerancia al fracaso
·       Alta
·        Baja
Comunicación
·       Fuerte y constante comunicación de la estrategia de cambio
·        Comunicación de la estrategia de cambio
·        Poca o nula comunicación
Espacios de trabajo y herramientas de colaboración
·        Acondicionados para la colaboración (los espacios moldean el comportamiento)
·        Limitados y restringidos
Silos organizacionales
·         Colaborando en torno al valor
·        Enfocados en optimizar la agilidad en su área
Métricas de gestión
·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda, "como me midas me comporto")(4)
·        No sufren cambios
Agilidad Técnica
·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica. 
·        Adoptada como la compra de herramientas
Cultura
·        incentivar los nuevos comportamientos.
·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización
·        No intervenidos
Respecto a los frameworks ágiles
·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores
·        Adoptados con demasiadas adaptaciones, falencias y personalizaciones que terminan desfigurando y replicando el statu quo actual.
Mindset
·        Constante difusión y adopción del mindset lean - agile (5)
·        No intervenido
Respecto a los consultores (3)
·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento
·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio
Entre otros



Yo me quedo con mi conclusión
"Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

Por lo tanto, el problema al parecer no radica tanto en los frameworks, el problema radica en las personas y su disposición a adoptar este cambio, que dada vez es menos opcional.

Saludos Ágiles

Jorge Abad.




Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
  2. Yo también puedo hacerlo por la mitad del precio y mejor resultado
  3. Sugerencias de mi amigo Lucho Salazar
  4. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
  5. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html

lunes, marzo 30, 2020

De colección: What’s the difference between Scrum and Agile? by Jeff Sutherland

Source: https://www.quora.com/What-s-the-difference-between-Scrum-and-Agile/answer/Jeff-Sutherland-1?srid=hJUg


At the Agile Manifeso Meeting in 2001 we wrote a set of 4 values backed up by a dozen principles. This is Agile.
There were 3 experts on Scrum present and 4 founders of eXtreme Programming. These were the only two widely deployed processes. They are related because the founders of both processes were communicating in the internet newsgroups as they were formed and reusing ideas from one another as early as 1994.
The other experts at the meeting had written books and papers on more adaptive and flexible development processes to replace the Rational Unified Process which was dominant at the time in software, but too heavyweight.
So Scrum and XP are the parents of Agile which is not a framework or an operational implementation. The operational implementation of Agile in over 80% of teams today is some variant of Scrum. The fastest teams implement XP practices inside the Scrum.
An extremely important XP practice implemented in the first Scrum teams is continuous integration and deployment at least once a sprint if not more often. The DevOps movement has evolved to promote this practice which was part of the original Scrum and XP teams.
Over 50% of “Agile” teams cannot deliver at the end of a sprint and are late, over budget, with unhappy customers according to Standish Group data on hundreds of thousands of projects. So beware of fake Agile.





Traducción



En la reunión del Manifiesto Ágil en 2001, escribimos un conjunto de 4 valores respaldados por una docena de principios. Esto es ágil

Hubo 3 expertos en Scrum presente y 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994.

Los otros expertos en la reunión habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Proceso Racional Unificado (Rational Unified Process - RUP) que era dominante en ese momento en software, pero demasiado pesado.

Entonces Scrum y XP son los padres de Agile, que no es un marco o una implementación operativa. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más rápidos implementan prácticas XP dentro del Scrum.

Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración y el despliegue continuos al menos una vez por sprint, si no con mayor frecuencia. El movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP.

Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto, con clientes insatisfechos según los datos del Grupo Standish en cientos de miles de proyectos. Así que ten cuidado con el falso Agile.


jueves, noviembre 07, 2019

Reflexión: La empatía y Jugar a Ganar

Una Reflexión


De las cosas que más me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR, incluso tu me lees o estás suscrito a este blog por que consideras que en alguna medida lo que publico te puede ayudar a ganar en tu contexto.

La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo, es simplemente otra). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más simpático y a generar mejores resultados, generar abundancia para todas las partes.


Saludos

Jorge Abad

sábado, octubre 26, 2019

La Cultura Organizacional del Miedo



Una Cultura Organizacional basada en el miedo:
  • No se permite fallar
  • Se inhibe la innovación
  • La mejora continua debe ser predecible y da poco lugar a experimentos
  • No asume riesgos (observación: "El mayor riesgo es no arriesgarse")
  • Es ególatra
  • La iniciativa es vista como insubordinación
  • Se pide permiso para avanzar, incluso para hacer lo correcto
  • Es compatible con la planeación predictiva
  • Es compatible con una mentalidad fija
  • Es compatible con estructuras fuertemente jerárquicas
  • Es compatible con el estilo de liderazgo "Comando y Control"
  • Conduce a la inmovilidad

Una Reflexión sobre Hacer Ágil y Ser Ágil



La brecha entre Hacer Ágil y Ser Ágil nunca será cubierta con entrenamientos, se requiere del cambio en el Mindset de los líderes y de la Cultura de la Organización. 

miércoles, julio 03, 2019

Un mal líder puede estropear la cultura y el sistema

Quisiera aprovechar el blog para compartir algo que he visto y que todos sabemos

"Un mal líder puede estropear la cultura y el sistema"

Me explico, en este trasegar acompañando organizaciones en su transformación hacia la agilidad he visto de todo, tal como:
  • organizaciones llenas de procesos con equipos muy dinámicos dando excelentes resultados
  • organizaciones sin procesos detallados con resultados lentos
  • organizaciones con procesos de adorno
  • organizaciones con líderes inspiradores y líderes desmotivadores
  • y toda clase de combinación pervesa, positiva y mediocre de las anteriores
Llevándonos a decir con Deming

Resultado de imagen para a bad system beats a good person

Resultado de imagen para un mal sistema deming

Y en esa misma dirección recordé ésto que publiqué hace un tiempo en linkedin.




Cosa cierta, pero cada vez creo que esto de culpar al sistema, la cultura, los incentivos, los procesos, las métricas, los kpi, etc. es una excusa frecuente, cuando muchas veces una de las causas raíces a muchos problemas sistémicos son:
  • el liderazgo
  • y la forma como interactuamos
Es por tanto clave intervenir tanto el liderazgo como la forma como interactuamos, pero primeramente el liderazgo, sino será muy poco lo que podamos mejorar en el sistema y la cultura.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

jueves, abril 04, 2019

Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles

A ratos veo tantos "modelos" ágiles, radares, métricas, modelos de madurez ágil para organizaciones, equipos, personas, roles, etc. que me da la sensación que terminamos pareciéndonos más CMMi, y a marcos tradicionales que a la agilidad que promulgamos. Tendemos a parametrizar todo, es nuestra inclinación innata, tratamos de generar fórmulas, y estandarizar y generar patrones.

Pero olvidamos que el "driver" principal es la generación de valor al cliente, llegarle con mejores servicios y de forma temprana y continua; los radares, las métricas, los modelos de madurez son secundarios.

Las únicas métricas importantes en todo esto son: si generamos valor y si estamos sobreviviendo en el mercado, el resto es informativo.

miércoles, noviembre 07, 2018

Todos estamos jugando a ganar.

Una Reflexión

De las cosas que mas me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR.

La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más empático y a generar mejores resultados donde hay más abundancia para las partes.

Esta habilidad me ha permitido ser mejor #influenciador y mejorar altamente la colaboración.

Saludos ágiles
Jorge Abad

martes, agosto 07, 2018

Dos ideas sobre Agile

viernes, octubre 27, 2017

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2)


Imagen de la película: ¿Dónde está el piloto? - Idea de mi amigo Wilmar Hincapie



Hola a todos

En el pasado Ágiles 2017 en Chile, hablando con Leonardo Agudelo (@sweepnoise) sobre los proyectos piloto, me hacía ver que no solo eran importantes los puntos del artículo anterior (mira la primera parte de este artículo - Clic aquí):
  • 3 a 4 meses de duración
  • Con 1 a 4 equpos de trabajo
  • Importante para la organizaicón
  • Patrocinio ejecutivo
  • La gente correcta
  • Dominio de la tecnología
Sino que era necesario revisar el manifiesto ágil buscando los elementos para cumplirlo y para generar el ambiente propicio para que germine la agilidad, a continuación les comparto este análisis y algo de mi experiencia:
  • Crear un contrato que permita la agilidad, seamos sensatos un contrato con todo fijo -alcance, tiempo y costo fijo- no nos permitirá tener éxito. (ver sobre contratos agiles - clic aquí- )
  • No usar las tipicas métricas de cascada (CPI, SPI) para medir el proyecto (es un desastre tratar de acomodar ágil a esto - se los digo por experiencia)
  • Permitir el cambio como parte natural del proceso (he observado que en proyectos que quieren hacer ágil, siguen con la política de control de cambios --¡¡OMG!! NO SE IMAGINAN EL DOLOR DE CABEZA. es necesario archivar este proceso para poder hacer el piloto)
  • Cambiar las métricas de la evaluación de desempeño de las personas que participaran (es decir, en cascada a un analista le daban una buena calificación si tenía pocos controles de cambio, si este analista se va para el piloto de ágil, las historias de usuario las grabará sobre piedra - y me ha pasado -)
  • Requerir que el negocio este involucrado y contar con su participación al 100% (con el ROL de Product Owner o de Interesado clave)
  • Que exista la comunicación cara a cara (todos en el mismo sitio , co-location)
  • Crear las excepciones - válidas a los procesos organizaciónales - que permitan la agilidad
    • Prioridad en los despliegues
    • Prioridad en los controles de cambio de ambiente
    • Prioridad en las autorizaciones
    • etc

Cerrando

Ya hemos perdido mucho tiempo y dinero haciendo proyectos en cascada, démosle la oportunidad a ágil, pero bajo las condiciones para que este tenga éxito, sino no tiene sentido.



Alguna otra recomendación

No dudes en compartirla en la zona de comentarios.

Bienvenido el feedback




Saludos ágiles
Jorge Abad




miércoles, agosto 16, 2017

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.

Hola a todos

Hace poco leí un gran post de Mike Cohn relacionado con como elegir el proyecto piloto: (ver el post  aquí) en donde reforzaba 4 variables (más un bonus):

  • Duración: 3 a 4 meses
  • Tamaño: Entre 1 y 4 equipos de trabajo (un equipo de máximo 9 personas)
  • Importancia: Importante para la organización
  • Patrocinio y Compromiso Ejecutivo: Alto
  • y un Bonus: Contar con las personas correctas para hacer el proyecto (las que nos garanticen ganar esto funciona para cualquier escenario - agile o tradicional-).
El punto que quiero agregar (como fuente de mi experiencia) a esta lista de 5 puntos es:
  • La Tecnología: la tecnología debe ser dominada por el (los) equipo(s) de trabajo

y ahí es donde va aporte, no tiene sentido (adicional a los 5 puntos anteriores) hacer un piloto en agile, o Scrum donde:
  • la tecnología es nueva en el mercado, es decir, el proveedor nos están brindando la "valiosísima oportunidad" de ser de los primeros que la usan o implementan (¡OMG!),  o
  • el equipo de trabajo no conoce la tecnología, es decir:
    • no se domina la arquitectura
    • no se conocen los componentes
    • no se conocen los retos subyacentes, las características, 
    • las premisas y supuestos no se dominan, 
    • no se conoce como hacer el tunning del sistema, entre otros.
    • y aunque el equipo recibió una "muy buena capacitación" y les funcionaron "todos los laboratorios" sabemos que eso no los hace expertos en algo nuevo (que al menos requeriría seis meses de trabajo continuo para comenzar a tener cierto dominio)
Sabiendo que el propósito es generar una victoria temprana y un gran impacto en la organización, de forma que sea comparable con los proyectos en cascada de similares condiciones.

No recomiendo hacer el primer piloto en agile con tecnología desconocida (y para ser sincero tampoco en cascada), pues no se verían resultados en el mediano plazo ni de la tecnología nueva ni del método.

Mi recomendación general sería:
  • hagamos un proyecto piloto en agile con que cumpla las seis premisas:
    • 3 a 4 meses de duración
    • Con 1 a 4 equpos de trabajo
    • Importante para la organizaicón
    • Patrocinio ejecutivo
    • La gente correcta
    • Dominio de la tecnología


  • y si, aun así desean el proyecto de la tecnología nueva y retadora, pues que sea otro proyecto adicional al primero, pero:
    • que "este no sea el de mostrar" que Agile funciona (pero eso sí estoy seguro que si en este proyecto hacen correctamente Agile o Scrum les aseguro que avanzará más rápido que en cascada)
    • que tenga e alcance pequeño 
    • que cuente con alto acompañamiento al equipo de parte de expertos o personas conocedoras de la tecnología
    • que la organización tenga paciencia este proyecto y su presentación de resultados,  
    • y que los patrocinadores tengan alta tolerancia a la frustración pues este problema no corresponde a un escenario complejo (ni mucho menos predictivo) sino a una caótico donde es difícil tener victorias tempranas (1).
Hasta acá esta corta recomendación, reflexión y lección aprendida.


Saludos ágiles

Jorge Abad

Notas, aclaraciones, comentarios y referencias

  1.  Ver el framework de Cynefin para entender el contexto de esta afirmación (clic aquí)