Principios Agiles

Diplomatura en Metodologías
Ágiles de Gestión de
Proyectos y Productos
Módulo 1: Principios Ágiles
Ana Bardoneschi abardoneschi@itba.edu.ar
Paula Elisa Kvedaras pkvedaras@itba.edu.ar

MetodologíaÁgiles de Gestión de Proyectos y Productos
Índice de Contenido
Introducción a la Metodología 3
Proyectos, Productos y Operaciones 4
El cambio de pensar en Proyectos a enfocarse en Productos Agiles 5
Scrum y Lean 6
Los Tres Documentos Básicos de Agile 7
Línea de Tiempo de la Gestión de Proyectos Agiles y Tradicionales 9
Lo que tienen en común las Metodologías Agiles 9
Ciclo de Vida del Proyecto y del Producto 11
Lo que tienen en común las Metodologías Tradicionales y las Agiles 12
Del concepto de Bimodal de Gartner a Multimodal 13
Algunas publicaciones interesantes sobre el cambio de mindset 17
2
Metodología Ágiles de Gestión de Proyectos y Productos
Introducción a la Metodología
Vamos a comenzar acordando el significado que vamos a darle a algunos términos en esta
asignatura porque algunas, como metodologías, métodos, enfoques, procedimientos, marcos
teóricos, procesos, reglas, cuerpo de conocimientos o buenas prácticas suelen confundirse y generar
estériles disputas.
La palabra metodología proviene del griego (“metá” = más allá, “odós” = camino, y “logos” = estudio)
y significa “conjunto de métodos utilizados para alcanzar ciertos objetivos que requieren
habilidades y conocimientos específicos”.
Elegir la metodología es una de las primeras tareas de un proyecto, y nos va a permitir seleccionar los
métodos para realizar las tareas vinculadas con él. Lo que tienen en común todos los métodos es la
posibilidad de ser usados y aplicados "ροr cualquiera", a diferencia de los mal llamados "métodos
individuales" que no son métodos sino simplemente "costumbres" o “procedimientos”.
En cambio un cuerpo de conocimientos o de “buenas prácticas” es lo que una asociación de

profesionales dice que son el conjunto completo de los conceptos, términos y actividades que
conforman ese dominio profesional.
Como estos conceptos muchas veces se confunden vamos a acordar en llamar metodologías a todas
las que cumplan con la definición, independientemente de lo que digan sus seguidores o detractores
sobre lo que son o no son.
Siempre el peor escenario para una organización es no contar con ninguna metodología de
gestión de proyectos. Una metodología es como la estrategia de juego de un equipo profesional:
Nos dice como realizar un conjunto de procesos y prácticas de una manera determinada y el porqué
para poder cumplir un objetivo, en este caso realizar un proyecto.
Por eso las organizaciones suelen tener un conjunto de procedimientos para realizar proyectos
estableciendo determinadas reuniones, circuitos de aprobaciones, checklists, políticas, etc. y hasta
algunas han desarrollado o adoptado realmente una metodología específica para realizar proyectos.
Esto es muy importante porque cuando una organización tiene una metodología madura, efectiva y
repetible tiene una gran ventaja sobre los competidores que no han llegado a tener este nivel de
madurez.
Tradicionalmente los profesionales que se dedican a esta disciplina son los Directores de Proyecto. El
Project Management Institute (PMI) es una organización sin fines de lucro y una de las asociaciones
profesionales más grandes del mundo que cuenta con más de medio millón de miembros titulares de
sus certificaciones en 180 países.
El PMI expone su metodología en el PMBoK® Guide Project Management Body of Knowledge, que
contiene una descripción general de los conocimientos y prácticas consensuadas como aplicables a
la mayoría de los proyectos la mayor parte del tiempo. Es el conjunto de buenas prácticas aplicables
a los procesos de dirección de proyectos de la manera tradicional. Su correcta aplicación puede
aumentar las posibilidades de éxito de muchos proyectos tradicionales, nos proporciona un
vocabulario común, y nos informa a medida que se logra consenso de lo nuevo en la profesión de
Dirección de Proyectos.
Es así que en el 2017, en la sexta edición del PMBoK® se incorporan en cada área de conocimiento
las “Consideraciones para Entornos Agiles Adaptativos”, y un Apéndice de Entornos de proyectos
3
ágiles, iterativos, adaptativos e híbridos. Y también en el 2017 el PMI publica un nuevo documento
denominado Agile Practice Guide reconociendo la aparición de otra manera de gestionar proyectos...
Proyectos, Productos y Operaciones

Definido a la manera tradicional un proyecto es un esfuerzo temporal que se lleva a cabo para
crear un producto, servicio o resultado único. Puede crearse por una demanda del mercado, una
necesidad de la organización, una solicitud de un cliente, por un avance tecnológico, por un requisito
legal, etc. pero a diferencia de los trabajos operativos que las organizaciones realizan en forma
continuada y repetitiva para dar respaldo al negocio, los proyectos permiten lograr objetivos únicos y
aparecen como respuesta a una necesidad estratégica de organizar actividades no tratables dentro
de los límites operativos normales de la organización.
Como en todas las profesiones, los conocimientos de la profesión de Dirección de proyectos residen
en los profesionales que los aplican y desarrollan, y como estos evolucionan constantemente incluyen
prácticas tanto tradicionales como innovadoras. Para las metodologías tradicionales el Director del
Proyecto es la persona responsable de alcanzar los objetivos del proyecto, lo cual incluye identificar
los requisitos; establecer objetivos claros y posibles de realizar; y adaptar las especificaciones, los
planes, y las expectativas de los Stakeholders1.
Para las metodologías tradicionales un

proyecto se considera exitoso si logra los
objetivos en los plazos estipulados,
dentro de los costos previstos y con las
especificaciones requeridas en el alcance.
Seguramente muchos hemos visto versiones

de este “chiste” sobre los proyectos
informáticos tradicionales, pero más allá del
chiste, The Standish Group2 en una
investigación encontró que alrededor de un
tercio de los proyectos tradicionales se
cancelan, más de la mitad cuesta casi el
doble del presupuesto acordado, demorando
más y con menos funcionalidades de las
especificadas, y que solo aproximadamente
un sexto de los proyectos se completa en tiempo y dentro del presupuesto.
Porque si bien es una tarea clave del Director de Proyecto manejar las necesidades y expectativas de
los stakeholders para asegurar el éxito del proyecto, no es la satisfacción de los mismos (a diferencia
de un proyecto Agile) lo que define el éxito de un proyecto tradicional.
La evolución fue el resultado de un cambio que se empezó a vivir a nivel mundial a mediados de los
´90 en el sector informático tanto en el pensamiento como en la práctica en las metodologías que se
usaban en la gestión de proyectos como resultado de los inconvenientes que nos encontrábamos.
1
Se denomina Stakeholders a los individuos y organizaciones activamente involucrados en el proyecto; o cuyos
intereses pueden ser afectados como resultado de su ejecución.
2
The Standish Group es una consultora especializada en proyectos de software reconocida mundialmente por
su informe bianual "Chaos Report" con los resultados de miles de proyectos en los principales segmentos de la
industria, incluyendo la banca, valores, fabricación, ventas, salud, seguros y servicios.
4
El cambio de pensar en Proyectos a enfocarse en Productos Agiles

Para adaptarnos a las necesidades que cambiaban cada vez a un ritmo más vertiginoso empezamos
a crear nuevos procedimientos para realizar los nuevos proyectos sin tener que requerir heroicos
esfuerzos para cumplir los compromisos quemando a los miembros del equipo, y así necesitamos
incluir en la metodología la manera de capitalizar en el proyecto en curso las “lecciones aprendidas”.
Tuvimos que enfocarnos más que en los proyectos como hacíamos antes, en los productos
que había que entregar cada vez más rápido y con la última tecnología que demandaba el
mercado, necesitábamos adaptar la metodología de trabajo para ganar velocidad y no “llegar tarde” al
mercado…
Pero enfocarse en el resultado final siendo flexible y adaptable a la situación es algo sumamente
difícil de explicar a quienes quieren mantener un “status quo” y no salirse de su “zona de confort” para
enfrentar los desafíos de la revolución digital, por lo que las grandes empresas tardaron en enfrentar
el desafío del cambio y las startups empezaron a liderar el cambio, porque para cambiar de tipo de
metodología se requiere no solo cambiar los procesos, prácticas y técnicas, sino hacer un
cambio de mentalidad, y cambiar la cultura de una organización es una tarea muy difícil, sobre
todo cuanto mayor es la organización.
El problema de las metodologías tradicionales de gestión de proyectos es que pierden flexibilidad

para realizar cambios porque se enfocan más en los procesos que en los productos. Se centran más
en el “cómo” que en “porqué” se hace algo, al necesitar el análisis previo se comprometen soluciones
técnicas antes de tiempo, por lo que luego hay que reevaluarlas o quedarse con soluciones que ya no
son las mejores, pierden el feedback de los clientes durante el desarrollo, los obligan a firmar
requisitos que ni entienden completamente y encima a esperar meses para probarlo y darse cuenta
que no era lo que pidieron o que no pidieron lo que querían o necesitaban. Así que empezaron a
coexistir dos corrientes metodológicas, la de quienes seguían desarrollando Proyectos Tradicionales y
la de quienes desarrollaban Proyectos Agiles.
La aparición de las metodologías Agiles fue el primer cambio significativo en la gestión de

proyectos en la historia reciente. y fue un cambio tanto en el pensamiento como en la práctica
de los que gestionaban los proyectos.
5
Scrum y Lean
Scrum es una metodología utilizada mundialmente por la mayoría de
las compañías de la industria del software y tiene el mismo origen que
Lean, la teoría de los Sistemas adaptativos complejos. Ambas
metodologías son implementaciones complementarias para poder
manejar la realidad física, donde muchas veces las cosas no son
lineales, ni simples, ni predecibles.
Lean significa lo magro, que tiene poca grasa, que es lo innecesario. La idea
principal es maximizar el valor dado al cliente eliminando el desperdicio.
Si no hay confianza entre el líder y su equipo o si la silla es incómoda da lo mismo,
es “grasa”, el proyecto se hace innecesariamente más complejo. Lean habla del
desperdicio, que es el esfuerzo que no aporta para resolver el problema en sí
mismo.
Una de las utilidades de Scrum es que permite detectar esa grasa, hace que emerjan las
disfuncionalidades organizacionales, aunque lo que no hace ni pretende hacer es resolverlas.
Ambas actualmente se aplican muchas veces juntas en muchas industrias y ya no solo en la de

Software. Esto comenzó con quienes empezaron por aceptar que el proceso de desarrollo de
software es impredecible, y decidieron tratarlo como a una "caja negra" controlada, en vez de
manejarlo como un proceso definido por completo desde el inicio. Scrum facilitó así al principio solo
resolver problemas que aparecen como la falta de comprensión de los requerimientos al inicio, el
cambio en los requerimientos durante el proceso, o la dificultad para prever los resultados del uso de
nuevas herramientas y tecnologías, y actualmente ya sabemos que detecta muchos más problemas y
al exponerlos posibilita al menos su tratamiento …
Si quieren conocer más sobre como empezó la historia, es recomendable leer el artículo “The Secret
History of Agile Innovation” escrito por Darrell K. Rigby, Jeff Sutherland e Hirotaka Takeuchi en abril
del 2016, pero lo que es imprescindible conocer tres breves documentos: el Manifiesto por el
Desarrollo Ágil, los Principios del Manifesto Agile y la Declaración de Interdependencia.
6
Los Tres Documentos Básicos de Agile

En el ámbito del desarrollo de software al menos casi todos saben que en el 2001 se reunieron
diecisiete representantes de Extreme Programming, SCRUM, DSDM, Desarrollo de Software
adaptativo, Crystal, Feature-Driven Development, y Programación Pragmática, etc. todos
competidores entre sí, para tratar de resolver los problemas típicos de los procesos tradicionales de
desarrollo de software: planes que no se cumplen o se retrasan, documentación que exige demasiado
trabajo de elaboración y no refleja la realidad del producto final, contratos que terminan perjudicando
a una de las dos partes (desarrollador o cliente) o a ambas, etc. y decidieron firmar el Manifiesto por
el Desarrollo Ágil de Software que dice:
stamos descubriendo formas mejores de desarrollar software tanto por

“ E
nuestra propia experiencia como ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
o Individuos e interacciones sobre procesos y herramientas
o Software funcionando sobre documentación extensiva
o Colaboración con el cliente sobre negociación contractual
o Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los
de la izquierda.”
Estas frases implican que acordaban en que:
❏ Los proyectos los llevan adelante y los problemas los resuelven las personas. Aunque las
herramientas y técnicas son necesarias el foco debe estar en ellas.
❏ Enfatiza la importancia de la entrega de un producto utilizable. La documentación por sí

misma o a expensas de un software funcional no es útil.
❏ Hay que tener una actitud flexible, cooperativa y acomodarse a los cambios, y no rígida y
cerrada.
❏ Los planes se realizan cuando menos se conoce de un proyecto.
7
Por el contrario, muchos menos conocen los Principios del Manifiesto Agile:
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software
con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Agiles
aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al
periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el
proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
Y finalmente lo que muy pocos conocen es que en el año 2005 se firmó La Declaración de
Interdependencia por un grupo de líderes de proyecto (incluyendo dos de los autores originales del
manifiesto) ya enfocada en la gestión del proyecto, que afirma:
● Nosotros aumentamos el retorno sobre la inversión enfocándonos en el aporte

continuo de valor.
● Nosotros entregamos resultados fiables involucrando al cliente frecuentemente y

compartiendo la propiedad del proyecto.
● Nosotros esperamos la incertidumbre y la gestionamos a través de iteraciones, con

anticipación y con adaptación.
● Nosotros damos rienda suelta a la creatividad y a la innovación reconociendo que las

personas son la última fuente de valor, y creamos un ambiente donde puedan hacer la
diferencia.
● Nosotros potenciamos el rendimiento a través de la orientación del grupo a los

resultados y la responsabilidad compartida para la efectividad del equipo.
● Nosotros mejoramos la eficacia y fiabilidad a través de estrategias situacionalmente

específicas, procesos y prácticas.
8
Vamos a intentar dar un pantallazo a la evolución de la profesión de gestión de proyectos con una
Línea de Tiempo de la Gestión de Proyectos Agiles y Tradicionales
Lo que tienen en común las Metodologías Agiles

Aunque cada uno de los enfoques ágiles tiene aspectos que los diferencian, todos tienen en común
los siguientes cambios:
● Se cambió la noción de equipo tradicional por la de equipos empoderados,

obteniéndose equipos de alta perfomance;
● Se cambió el enfoque jerárquico verticalista por equipos auto-organizados, con lo cual

el trabajo se distribuye por consenso del equipo en lugar de por una autoridad;
● Se publica constantemente actualizada la información del progreso del proyecto en

“boards” visibles para toda la organización;
● Se da la bienvenida al cambio;
● Se le da participación al cliente durante todo el proyecto, se lo incluye en el equipo;
● Se entrega el producto del trabajo en versiones; entregas pequeñas y frecuentes;
● Se prueba rápidamente en la realidad, obteniendo realimentación rápida.
● Se puede experimentar si aparece algún tema donde el equipo necesita información para
decidir informado qué camino tomar, puede investigar en un Spike.
● Se puede implementar la mejora continua porque al final de cada iteración el equipo

encuentra una oportunidad de mejora.
● Se cambió el ciclo de vida del proyecto por el ciclo de vida del producto incremental, o
sea se cambió la tradicional manera en que se piensa un proyecto, donde primero se
planifica, luego se ejecuta y finalmente se prueba, para seguir el modelo de
conceptualización, evolución y adaptación, por lo que se habla de un crecimiento
orgánico del producto.
9
Entonces una de las principales diferencias es que mientras el modelo tradicional favorece la
anticipación, el modelo ágil favorece la adaptación. Se trata de un cambio significativo en la
manera de hacer las cosas, teniendo en cuenta que la mitad de los procesos de la Guía PMBoK® son
procesos de planificación, con muchos centrados en la producción de documentación antes de
ejecutar los paquetes de trabajo.
Una de las ideas en la que se basan todas las metodologías Agiles es que
como la realidad es constantemente cambiante, el contexto para cada
proyecto es diferente y por lo tanto no es posible la planificación de todo el
recorrido del proyecto sino solo del pequeño siguiente paso en el recorrido del
mismo.
Al dar sólo pequeños pasos, obteniendo la información del cliente lo más rápidamente posible
y evaluando no sólo la calidad del producto, sino la calidad del proceso global, aunque el
trabajo está siendo planeado en cada paso, al ser los pasos más pequeños se reduce el riesgo y la
oportunidad de error.
El modelo iterativo incremental de Agile nos ofrece la mejor forma de trabajar en el entorno
VUCA3 (por sus siglas en inglés: volatile, uncertain, complex y ambiguous).
Las empresas vienen utilizando hace muchos años el concepto de VUCA

para analizar su entorno con una matriz, como podemos leer en este
artículo del 2014, y así, de acuerdo al escenario y la característica que
obtienen en ella, abordar su situación de una forma distinta. Inclusive hay
expertos que dicen que hay empresas que perdieron mercado por no poder
identificar el estado en el que se encontraban en un mundo VUCA.
En este mundo donde aparecen "incógnitas desconocidas" que ponen a los equipos en un terreno
que los modelos no pueden predecir - como los eventos de COVID-19 que sorprenden
constantemente desde a los especialistas en salud hasta a los funcionarios gubernamentales - el
proceso de toma de decisiones que responda al cambio rápido es tan importante como la decisión
misma.
Los líderes ágiles basan sus programas de cambio en la preparación de equipos para
funcionar en un mundo VUCA, donde las necesidades de clientes, competidores y stakeholders
cambian rápidamente. Esto significa pasar de tener miedo a VUCA a adoptar lo que Euvin Naidoo
llama VUCAgility, el cambio de mindset respaldado por la acción, que permite superar el miedo.en el
artículo 7 Successful Battle Strategies To Beat Covid-19.
Y para eso, como en la pandemia, hay que utilizar métricas e indicadores para saber si se
alcanzaron determinados criterios y no tratar de predecir y cumplir fechas de etapas.
3
El término VUCA se originó en el US War College para describir situaciones que son Volátiles,
Inciertas, Complejas y Ambiguas.
10
Ciclo de Vida del Proyecto y del Producto

Mientras en las Metodologías tradicionales tenemos un plan de proyecto con todos los pasos para
hacer un producto preformulado al principio y recién cuando termina el proyecto comienza a existir el
producto, en Agile el driver principal es el Ciclo de Vida del Producto, donde lo que existen son
iteraciones que permiten su crecimiento orgánico y los distintos proyectos tienen ciclos de vida de
acuerdo al roadmap que se va construyendo del producto a medida que se incrementa.
En los métodos tradicionales típicamente el cliente está implicado al principio del proceso, pero se
tiende a mantenerlo excluido una vez que el equipo del proyecto comienza a ejecutar los paquetes de
trabajo, mientras que en los proyectos ágiles el cliente está estrechamente integrado en el momento
que el trabajo está siendo realizado.
En las metodologías tradicionales tanto el costo como la

cantidad de personal aumentan durante las fases
intermedias de ejecución.
Y a lo largo del tiempo observamos que la influencia de

los stakeholders disminuye mientras el costo de los
cambios aumenta…
A diferencia de lo que ocurre en Agile que el

involucramiento de los stakeholders se mantiene a lo
largo de todo del tiempo e inclusive aumenta a medida que perciben los beneficios de invertir su
tiempo en resultados concretos, y no hay costo adicional por cambios dado que se basa en la
constante adaptación.
Por eso en el capítulo Gestión de los costos de la 6ª Edición de la Guía PMBoK® plantea que los
proyectos con altos grados de incertidumbre o en los que el alcance no está completamente definido
no se obtienen beneficios de los cálculos de costos detallados debido a los cambios frecuentes.
En su lugar, recomienda utilizar métodos de estimación simple para generar un pronóstico rápido de
alto nivel de los costos laborales del Proyecto (PxQ) e irlos reajustando constantemente, reservando
las estimaciones detalladas para el corto plazo (sprints) en una modalidad “Just in Time”, y en los
proyectos de alta variabilidad, pero sujetos a presupuestos estrictos, ir reajustando constantemente el
alcance y el cronograma para permanecer dentro de las restricciones de costos.
Con respecto al significado de “Just in Time” hay que diferenciarlo del término “Just on Time”. Aunque
la traducción al español de ambos es “Justo a tiempo”, el concepto de “Just in Time” se refiere a la
oportunidad de un evento, y “Just on time” se refiere a la puntualidad respecto de ese evento. No es
lo mismo llegar “puntual” a una reunión que llegar “a tiempo” para desactivar una bomba.
A partir de la segunda guerra mundial, el concepto de “Just in Time” fue desarrollado en el modelo de
producción de Toyota, para resolver desperdicios como la sobreproducción, costos de
almacenamiento, etc. que al producir sólo las partes necesarias, en el momento necesario, en las
cantidades necesarias (JIT) se aumenta la calidad y la velocidad de producción. Este modelo
posteriormente fue adoptado por diversas industrias, incluyendo la de desarrollo de software.
11
Lo que tienen en común las Metodologías Tradicionales y las Agiles

La manera en que se gestionan los proyectos tradicionalmente es conocida
como "de cascada" por la forma lineal en el que las actividades fluyen del alto
al bajo nivel, siguen el Ciclo de Deming de Planificar-Hacer-Verificar-Actuar,
por lo que requieren mucho análisis previo y mucha documentación de las
necesidades, los problemas y la solución propuesta. Luego, al ir comparando
la solución real que están pudiendo construir contra el plan que formularon, se
van haciendo correcciones.
Hay varias metodologías de cascada pero lo que todas tienen en común es que tienen definidos
procesos a seguir que luego se cumplen, y que se controla el seguimiento del proyecto en cuestión de
acuerdo con el cumplimiento de la línea base y los procesos que se formularon como resultado de
haber adoptado una metodología o de haber desarrollado una propia.
Las dos corrientes metodológicas, las de los Proyectos Agiles

y las de los Proyectos Tradicionales, tienen similitudes como
que hay que definir las necesidades transformandolas en
objetivos a cumplir, traducir estos objetivos a características o
funcionalidades, descomponerlos en tareas para crear
productos, probarlos y entregarlos al cliente interno o externo.
Hay distintas metodologías tradicionales basadas en procesos como PRINCE2® o IPMA, pero la
más utilizada y famosa es la del PMI cuyas bases están sentadas en el PMBoK®.
El PMI inclusive ha participado en la redacción de la única norma internacional sobre Dirección de

Proyectos, la Norma ISO 21500 - Guidance en Project Management de la organización internacional
de normalización y publicada en el 2012 basada en procesos, pero como las metodologías Agiles
consiguieron demostrar que ganan tiempo sin perder calidad ni control, en el 2017 las incorporó en el
en el PMBoK® y en la Agile Practice Guide.
Lo que hay que entender es que las metodologías tradicionales - aunque muchos profesionales
piensen que el PMBoK® es difícil de manejar, lento para adaptarse al cambio y que la planificación
que encara es muy pesada - siguen siendo las más adecuadas cuando se trata de realizar proyectos
poco innovadores, donde previamente se saben la mayoría de los detalles y los temas están cerca de
un acuerdo.
Pero en caso contrario conviene utilizar metodologías agiles, como en los proyectos digitales en los
cuales raras veces ocurre que se sepa de antemano exactamente lo que se desea hacer o cómo
hacerlo y la velocidad de cambio actual hace que en general haya que hacer muchos cambios
durante el camino para adaptarse a los nuevos requerimientos del mercado debido por un lado a la
velocidad de incremento tecnológico y por el otro al incremento de la velocidad de demanda actual.
Aunque hay muchas metodologías ágiles reconocidas para desarrollar

software como Extreme Programming, Feature Driven Development
(FDD), Dynamic System Development Method (DSDM), Crystal, Lean
Software Development y Kanban Development, la más famosa y
utilizada es Scrum. Scrum y Lean están relacionadas desde su origen,
ambas se complementan y frecuentemente se implementan en
conjunto al igual que algunas herramientas como Kanban boards,
User stories, Burn up charts, Risk Burn down graph y Refinement.
12
Del concepto de Bimodal de Gartner a Multimodal

Como todos sabemos Gartner propuso Bimodal TI para trabajar con metodologías tradicionales y
ágiles en la misma organización, tradicionales para gestionar proyectos cumpliendo con los requisitos
de seguridad, estabilidad y legales, y los de agilidad para permitir la innovación que proporciona valor
al negocio lo antes posible.
Esta propuesta consiste en administrar y coordinar paralelamente dos métodos de entrega de

sistemas y servicios de tecnología, lo que hoy llamaríamos dos ciclos de vida de proyectos: uno
centrado en la estabilidad (lineal con hincapié en la seguridad y precisión) y el otro en la agilidad
(iterativo exploratorio centrado en la velocidad), explicando ambos modos con una metáfora de las
capacidades atléticas del corredor de maratón y las del velocista.
En el “Modo 1” del corredor de maratón se priorizan la fiabilidad y la eficiencia en los proyectos a

largo plazo, previstos y aprobados de acuerdo con la planificación clásica y los procesos
convencionales.
Mientras el “Modo 2” es el del velocista, con foco en la agilidad y la flexibilidad de las operaciones, la
experiencia del cliente y los resultados de negocio con opciones más empíricas y estrategias
diferentes, nuevos proyectos, modelos de negocio inciertos, y centrados en el cliente.
El Modo 1 trata de controlar lo desconocido y el Modo 2 trata de interactuar con el contexto y

responder a los cambios. No trata de predecir el futuro sino de crearlo. Al limitar las predicciones y
trabajar con iteraciones más cortas, da una mayor agilidad y una mayor capacidad adaptativa frente a
la incertidumbre actual. Lo plantea más adecuado para objetivos con menos definición previa como el
lanzamiento de nuevos productos, nuevas aplicaciones de front-end, etc.
Ambos modelos son esenciales, aunque requieren actitudes, cultura, recursos, socios tecnológicos,
liderazgo y gestión del riesgo diferentes.
Gartner recomienda crear equipos y estructuras separadas para cada modelo de operación para
proteger a los recursos que trabajan en el Modo 2 de las formas tradicionales que siguen operando en
el Modo 1. Pero como todas las grandes consultoras, explica lo que ya es un éxito probado, cuando
en realidad ya existen opciones para hacer convivir ambos modos en la misma estructura siempre y
cuando se realicen las adaptaciones adecuadas.
Como todos los consultores de TI reconocidos hace mucho hincapié en la necesidad de

entrenamiento y tutoría, y de comenzar la transformación cuanto antes, sin esperar a sentirse
completamente preparado.
La transformación tiene muchas aristas, es difícil y requiere un fuerte compromiso por parte del
management y la adquisición de una predisposición cultural para explorar los nuevos territorios,
asumir riesgos razonables y aceptar los errores iniciales como parte del proceso de aprendizaje.
Gartner recomienda dar los primeros pasos con proyectos en modo Bimodal, para luego extender las
nuevas capacidades al resto de la organización. Su receta para el éxito se centra en:
● La búsqueda de personas (y un socio tecnológico) con una mentalidad Modo 2
(colaborativa, abierta a los cambios, flexible y capaz de soportar la
ambigüedad).
● Mantener al principio la distancia organizativa entre los dos modos.
● Liderazgo adaptativo, equipos comprometidos, procesos iterativos y mejora continua.
● Adopción de metodologías ágiles y enfoque de desarrollo ágil, no en cascada.
● Búsqueda de gerentes de proyecto que actúen como gestores de la innovación.
13
Cuando pensemos en la velocidad del cambio recordemos que sólo han pasado 6 años desde el 2014
en que Gartner acuña el término Bimodal IT para describir la gestión separada y coherente de dos
ciclos de vida de proyectos en el sector de IT de una organización a hoy que el PMI publica la Agile
Practice Guide que define 4 ciclos de vida de proyecto, donde lo que los diferencia no es si se planifica
o no, sino cuánto se planifica y cuando, con tres ciclos de vida desde el predictivo tradicional, pasando
por modelos intermedios hasta el último que es el adaptativo.
Esta Guía plantea que más allá de en la industria informática, Agile se ha expandido a industrias
como la financiera, manufacturera, de educación, de salud y otras industrias en diversos grados, y por
eso aborda la selección del ciclo de vida del proyecto.
Ciclo de vida predictivo: Enfoque tradicional, la planificación se realiza por adelantado con
requisitos identificados con el mayor detalle posible, seguido por la ejecución siguiendo un proceso
secuencial y buscando controlar el costo del proyecto.
Ciclo de vida iterativo: Permite tener retroalimentación del trabajo sin terminar para mejorarlo y
modificarlo. Se planifican prototipos o pruebas de concepto y revisiones de los mismos, pero los
resultados están destinados a modificar los planes creados al principio. Busca involucrar al cliente
durante la planificación, previa a la ejecución del proyecto. Los proyectos que siguen este ciclo suelen
llevar más tiempo porque favorecen el aprendizaje en lugar de la velocidad de entrega.
Ciclo de vida incremental: Proporciona entregables intermedios que el cliente puede utilizar. El plan
está delineado para entregar subconjuntos sucesivos del proyecto total. Pero la entrega de cada uno
de estos entregables requiere del ciclo completo, como análisis, diseño, desarrollo, testing, entrega.
Busca ganar velocidad de entrega utilizando una metodología tradicional.
Ciclo de vida Agile: Un enfoque iterativo e incremental que permite entregar un producto funcional
en cada iteración e ir refinando los ítems a incluir en el producto. El equipo espera que los
requerimientos cambien y se van descubriendo requisitos ocultos, cambios o malentendidos. Busca
agregar el mayor valor posible mediante entregas frecuentes con feedback continuo para adaptarse a
altos grados de cambio y entregar valor al negocio con mayor frecuencia.
El PMI denomina enfoque híbrido a una combinación de enfoques predictivos, iterativos,

incrementales y/o Agile, y dice que no es necesario utilizar un solo enfoque para un proyecto
completo y que se pueden combinar elementos de diferentes ciclos de vida.

Dice que por ejemplo se puede comenzar un proyecto utilizando un ciclo de vida Agile, que luego es
seguido por una fase de lanzamiento predictivo. Este enfoque se puede usar cuando hay
incertidumbre, complejidad y riesgo en la parte de desarrollo del proyecto que se beneficiaría de un
enfoque Agile, seguido de una fase de implementación repetible que es apropiado emprender de
manera predictiva, usualmente por un equipo diferente y pone un par de ejemplos, como el desarrollo
de un nuevo producto de alta tecnología seguido del lanzamiento y capacitación de miles de usuarios,
y otro de una compañía farmacéutica, que mientras desarrolla las pruebas de las drogas de forma
Agile, el proceso de presentación y aprobación del FDA se realiza de forma predictiva.
Para que observemos los diferentes puntos de vista, lógicos por el diferente punto de observación de
la realidad, en su famosa presentación “Bimodal IT: How to Have It All Without Making a Mess”, María
Mesaglio, vicepresidente de investigación de Gartner, recomienda específicamente no hacer
proyectos mixtos, proteger los equipos de los diferentes modos y sobre todo evitar hacer el Modo 1,5
al que llama un tímido medio donde no se logran obtener los frutos de la agilidad pero tampoco los de
la estabilidad.
14
Plantea que no se debe tratar de implementar Agile pero con los requerimientos desde el inicio, o
implementar Scrum BUT; que hay que terminar en Agile hasta el final lo que se haya empezado en
Agile, etc. O sea lo contrario de la Guía Agile….
Recordemos que en ese mismo artículo María Mesaglio de Gartner hablaba de las tres eras de IT:
1. La primera donde IT estaba aislado, y el foco estaba en la tecnología.
2. La segunda de la industrialización enfocada en el proceso donde lo importante era la

automatización y la eficiencia.
3. La tercera que es la actual, la Digitalización, con el desafío de migrar el valor a las manos de los
usuarios con muchas oportunidades, muchos riesgos, y mucha incertidumbre porque si bien
sabemos que cada industria va a ser digitalizada para sobrevivir, lo que no sabemos es cuánto o
cómo será digitalizada cada una porque si bien se puede predecir la trayectoria de una tecnología
técnicamente, lo que no se sabe es cómo los usuarios van a responder a usarla.
El modo 1 corresponde a la era 2, a la industrialización de IT, efectiva cuando se trabaja de acuerdo a

un plan predefinido para crear entregas estables y confiables, cuando se sabe que hay que hacer…
pero como en la digitalización hay un alto grado de incertidumbre Gartner sostiene que todas las
empresas tienen que transformarse en bimodal, ya que no es posible responder a todas las
necesidades desde un único modo y que es un deber más o menos urgente dependiendo del sector
al que pertenezca la empresa tener los dos modos, dependan o no ambos del departamento de IT.
Al principio se hablaba de un Modo 1 de maratonistas enfocado en la estabilidad y

confiabilidad, haciendo todo lo que ya se sabe cómo hacer complementado por un
Modo 2 de velocistas o sprinters enfocado en la agilidad y flexibilidad, siendo
capaces de responder y adaptarse al cambio y capaces de operar en un ambiente
de gran incertidumbre. Gartner mencionaba dos velocidades, pero se cambió a
bimodal porque si bien la velocidad es un buen signo del modo 2, el valor agregado
más importante es poder avanzar aun cuando hay mucho que no se sabe y hay
gran incertidumbre, aún más que la velocidad que se gana. De ahí la analogía de ver el modo 1 como
maratonistas y el modo 2 como velocistas.

En la era de digitalización se precisan ambos, maratonistas y sprinters, pero ambos
modos requieren un enfoque riguroso y disciplinado.
Porque la realidad es que las empresas generalmente no inician desde cero, ya tienen un
departamento de IT con profesionales entrenados como maratonistas, y por lo tanto deben buscar
cuáles de ellos son los mejores candidatos para transformarlos en velocistas o sprinters. Algunas de
las características más importantes para seleccionarlos es que estos profesionales tengan empatía
con los problemas de los usuarios finales, se sienten confortables con la ambigüedad, que les baste
saber cuál es el objetivo y no necesiten toda la información detallada por adelantado, que sean
curiosos, les guste cambiar y probar nuevas aplicaciones, aventuras, tecnología, etc.
Con ellos en el modo 2 se crean equipos multidisciplinarios, donde se trabaja en conjunto entre IT y el
negocio donde todos los integrantes suman sus conocimientos y habilidades para producir algo que
agrega valor al negocio.
También es clave para el éxito del modo 2 que al menos uno de los integrantes de cada equipo tenga
una capacidad excelente de relacionamiento tanto internamente como con el resto de la organización,
dado que estos equipos van a tener que lidiar con las barreras culturales que estaban acostumbrados
a trabajar con el modo 1. Alguien que sepa con quien hablar y que permita que cada equipo pueda
seguir avanzando y que lidie con esas barreras.
15
Al inicio de la implementación de bimodal, van a tener los proyectos más importantes en modo 1, y
aquí o allí comenzarán a implementar modo 2. Como no es posible aprender a ser bimodal leyendo,
tienen que aprenderlo haciéndolo y no pedir permiso, sino empujar con el mayor aval posible. No
esperar a empezar cuando estén listos, sino en el momento que tomaron la decisión que para un
determinado proyecto es lo más efectivo.
Luego de varios proyectos en modo 2, seguramente se encontrarán con una pared, donde
efectivamente deberán realizar modificaciones en la organización y es cuando deberán cambiar
procedimientos: cómo conseguir Budget, cómo se planifica, etc.
Para dejar de ser unimodal tradicional hay muchos factores que tienen que ver con la cultura
organizacional que tiene que cambiar y esa transformación hay que hacerla en forma gradual, por eso
Gartner recomienda que al mismo tiempo de implementar modo 2 en proyectos aislados, se tiene
que transformar el modo 1 para que el core de la organización se renueve, se transforme en modular,
configurable, flexible, porque si el objetivo es que el modo 2 sea dominante, entonces el Core debe
estar preparado para trabajar en este modo.
Seleccionar los primeros proyectos es sumamente importante y debe realizarse cuidadosamente y

deben ser proyectos que nos den cierta garantía de que serán exitosos, porque de ellos depende que
podamos avanzar con este cambio tan importante para toda la organización.
Lo ideal es hacer primero varios proyectos aislados, luego

sumar algunos de reemplazo y cuando bimodal está
funcionando correctamente sumar proyectos de core nuevo en
modo 2.
Así que aunque al inicio ambos modos deben estar aislados,

no se pueden mantener de esta manera y el objetivo es que
se sincronicen los equipos de ambos modos. Para eso es
importante que el modo 2, no sea tratado como “shadow” IT, y
ni los integrantes ni los proyectos deben ser tratados como
fuera de la ley.
Deben actuar como bailarines que se complementan y se juntan y

separan. Los puntos críticos están cuando se pasan los proyectos de
uno a otro equipo en diferentes modos. Ambos equipos deben estar
preparados para esa transferencia.
Ante las diferentes metodologías que se fueron desprendiendo de la de cascada, como fases, espiral,
prototipado evolutivo hasta aparecer las Agile, la respuesta que muchos managers y coachs de
proyectos empezamos a dar es que:
La mejor solución es tener un enfoque multimodal adaptado a la organización de la que

se trate, o sea una metodología Propietaria Multimodal.
Cuando decimos multimodal nos referimos a un enfoque que contemple diferentes metodologías,
entendiendo que para diferentes proyectos es necesario tener diferentes procesos y usar diferentes
técnicas y herramientas, ya que es tan contraproducente utilizar Scrum para realizar una modificación
repetida y ya muy conocida como utilizar cascada para hacer una innovación. Como siempre se trata
de utilizar el menos común de los sentidos que es el “sentido común”.
16
Volviendo a los dos casos que plantea la Agile Practice Guide, lo que como coachs desde Multimodal
recomendamos es que, dado que son diferentes equipos, pueden hacer sus proyectos con distintas
metodologías. Un proyecto de desarrollo del proyecto de alta tecnología que se beneficiaría de un
enfoque Agile, y otro proyecto de implementación tradicional para el lanzamiento y la capacitación de
miles de usuarios, al igual que en la compañía farmacéutica, con un proyecto de pruebas de las
drogas de forma Agile realizado por un equipo de proyecto Agile, y otro proyecto tradicional para la
presentación y aprobación del FDA.

Actualmente, como la idea fundamental de las metodologías Agile es ganar tiempo sin perder calidad
ni control, en todas las áreas de todo el mundo cada vez más se utilizan metodologías ágiles. Las
más utilizadas son Scrum y Lean, asociadas con algunas técnicas como Kanban, y lo que más las
diferencia de las tradicionales son los roles, por ejemplo el cambio del rol de Líder que pasa de ser el
detentador de poder a ser el servidor de un equipo con lo cual se crea un fuerte vínculo entre el
equipo y el líder que suele traducirse en una mayor lealtad al producto que el equipo está creando.
Para completar un poco el panorama sobre Multimodal TI habría que agregar que la idea de utilizar
diferentes modos no es exclusiva de software en TI sino que también siguió su camino de evolución
en hardware. Como vienen señalado en numerosos estudios de las grandes empresas de TI como
Red Hat, los pocos sectores públicos y la pocas empresas que aún no han emprendido la
transformación, al menos ya comprenden la urgencia de empezarla antes que la ola digital los voltee,
y se están moviendo a multimodal TI a ambos niveles (software y hardware). Es interesante leer este
artículo. Las empresas se están adaptando a aplicar Multimodal TI empujadas por la aparición
constante de nuevo hardware y nuevo software gracias a la nube.
Algunas publicaciones interesantes sobre el cambio de mindset

En los últimos años frente al éxito de las metodologías Agiles consultoras importantes publicaron
artículos difundiendo sus opiniones respecto al Agilismo, y dado que en realidad las Metodologías
Agiles nacieron gracias a un artículo, el de Takeuchi, Hirotaka y Nonaka, Ikujiro que publicaron en
1986 “The New Product Development Game” en el Harvard Business Review, nos gustaría resumirles
algunos otros artículos conocidos, que les proponemos para el primer debate de nuestra asignatura.
En febrero del 2016 Gartner publicó un artículo denominado “Making Sense of the Agile Methodology
Wars” para aclararles el panorama a quienes deben decidir como transformarse en ágiles, incluyendo
a los líderes de muchas organizaciones de IT que apurados por el mercado, se comprometen a
agilizar sin conocer las diferencias y similitudes entre tradicionales y ágiles.
En el mismo advierte que hay que tener años de experiencia de seguir “a rajatablas” una metodología
para conseguir la aptitud para adaptarla a las necesidades de una organización determinada.
Como las metodologías ágiles comparten una filosofía pero difieren en el enfoque, al comenzar el
proceso se debe seleccionar solo un enfoque de Agile y dominarlo antes de intentar usar otros, así
que recomienda elegir una metodología ágil para comenzar y apropiársela.
La mayoría de los equipos ágiles usan Scrum al principio, y también son mayoría los que continúan
utilizando Scrum como base a medida que maduran. Scrum proporciona un framework a nivel de
equipo y de procesos para la aplicación de prácticas ágiles, e incluso cuando se implementan marcos
ágiles empresariales Scrum suele ser el framework central.
17
Según sus encuestas, el 91% de las organizaciones que utilizan Agile comenzaron con Scrum y
continúan usándolo, aunque hayan incorporado tableros Kanban y prácticas de XP como orientarse a
las pruebas, trabajar en parejas, etc.
Explica también que existen algunos métodos que no son realmente Agiles y están destinados a
organizaciones de desarrollo que quieren pensar en sí mismas como ágiles mientras siguen
trabajando y entregando en procesos y artefactos tradicionales que les resultan familiares.
Y plantea que la introducción de Agile es un cambio cultural significativo que mejora la relación de las
áreas con TI y ayuda a la transformación de toda la organización, pero que adoptar cualquier
metodología ágil requiere capacitación, aconsejando empezar con un entrenamiento de Scrum, y
administrar el proceso de cambio cultural de manera proactiva, hacia la mejora continua que es el
corazón de Agile.
También advierten que la capacitación es necesaria pero no suficiente para lograr los cambios
culturales necesarios y que la base de la transición al desarrollo centrado en el producto es la
transición de una cultura del "yo" a una cultura de "nosotros", donde el equipo es responsable del
trabajo y de sus miembros y que en estos equipos la autoridad no fluye de arriba hacia abajo.
Dado que el equipo es la unidad cultural esencial y no el individuo, y que los equipos ágiles exitosos
son grupos de alta perfomance autogestionados, las métricas Agiles también están orientadas al
equipo y se centran en el valor para el cliente entregado por el equipo.
Y si bien continuamente hay que revisar, adaptar y mejorar los procesos, e incorporar nuevas
prácticas ágiles, al adoptar una metodología, hay que comenzar implementando el método como fue
diseñado con la guía de un entrenador ágil experimentado, para luego poder ajustar las prácticas a la
organización utilizando las retrospectivas regulares para identificar las oportunidades de mejora.
Finalmente informan que según otra encuesta de Gartner sobre "Agile in the Enterprise", los líderes
de TI informaron que el porcentaje de proyectos que dejan de hacerse en cascada y se hacen Agile
sigue aumentando cada año.
Por otra parte en la revista de Harvard se publicó el artículo “Llenar la empresa de posits no la hará
más ágil” planteando que en la actualidad, enfrentándose al reto de la metodologías ágiles, las
organizaciones están tratando de aprender cómo implementar una nueva forma de trabajar,
pensar, romper los silos, aplanar estructuras tradicionales y construir relaciones de confianza
con personas aun cuando no las conocen.
Dado que el agilismo da la oportunidad de la visibilidad, la adaptación al cambio, la flexibilidad y el

aprendizaje de los errores, pero requiere que los equipos incorporen herramientas que
favorezcan el desarrollo de una nueva forma de generar inteligencia colectiva, así como
habilidades para maximizar el rendimiento del equipo.
Cada miembro de un equipo Agile, debe aprender los principios y valores que la sustentan, identificar
los nuevos paradigmas que favorecen la aparición de los comportamientos productivos para alcanzar
el objetivo de la forma más efectiva en el menor tiempo posible.
18
Agile es un conjunto de creencias que permite a los equipos operar y tomar decisiones de
manera eficaz para realizar un trabajo concreto y entregar un producto a la medida de las
necesidades cambiantes de su cliente.
Las metodologías ágiles son posibles gracias a la retroalimentación que sigue a la escucha, la
confianza y el compromiso que surgen del feedback constantes para ganar velocidad, aprendizaje y
mejoras. Escuchar, probar, escuchar y cambiar en una conversación permanente para ir
construyendo sin necesidad de tener que apostarlo todo a un solo número y color.
El entorno Agile obliga a superar esa cultura individualista en la que tenemos que ser perfectos,
autosuficientes y dar respuesta a todo, a superar la competitividad con cada individuo centrado en sus
resultados, y pasar a otro sistema en el que cada acción esté sincronizada con el interés colectivo
para asegurar el resultado colectivo final.
En esta apuesta por la colaboración en lugar de la competencia, para desde la confianza

construir un entorno en el que todos los miembros se sientan parte de un contexto seguro, y pueda
compartir sus puntos fuertes y sus vulnerabilidades, para que puedan ser cubiertas por el resto del
equipo y no pongan en riesgo el resultado común.
El método “pull” de asignación de tareas, en el que cada persona elige hacerse cargo de ciertos
elementos de la lista de pendientes, requiere una confianza que deberá ser alimentada durante
todo el proyecto, y repararla cada vez que sea necesario.
La confianza y la conexión con el propósito, favorecen la comunicación y la colaboración, y logran

reducir desperdicios. La consciencia de la organización debe ser sistémica y, para ello hay que
escuchar más allá de las palabras y realizar una labor de inspección, que pasa por poner en
marcha diferentes formas de observar y de preguntar para encontrar el punto de apalancamiento del
equipo.
El artículo finaliza hablando de tres puntos clave para adaptarse a las metodologías ágiles: Abrazar
el error como oportunidad de aprendizaje; Entrenarnos en el feedback, no sólo en dar sino en
recibir mucho feedback y aprender a aceptarlo; Consciencia sistémica: Ver a la organización y al
equipo como un sistema que se autorregula en relación al objetivo.
LA ERA DE LA TRANSFORMACIÓN DIGITAL
Vivimos en la era de la transformación digital, que es simultáneamente tecnológica y social, y por lo

tanto requiere tanto adoptar las nuevas tecnologías como las nuevas maneras de comunicarnos y
organizarnos dentro de las sociedades a las que pertenecemos, entre ellas en la empresa.
Debemos adaptarnos a la vertiginosa velocidad actual del cambio y seguir innovando para dar valor
añadido, para poder garantizar la futura competitividad de nuestras empresas.
En esta “r-evolución” global en oleadas tenemos que surfear para no hundirnos y estar en la cresta
para destacarnos de nuestros competidores, obligándonos a ser más creativos para aprovechar las
potentes herramientas tecnológicas que nos ofrecen nuevas oportunidades como las redes sociales
para fidelizar, para aprovechar la comunicación multidireccional para saber lo que los usuarios
opinan, tenemos que aprender a utilizar la Web para escuchar, interpretar y gestionar, debemos
adaptarnos a los cambios tecnológicos y sociales aumentando la necesidad de estar conectados para
ser competitivos.
19
Pero como todos sabemos los individuos y por lo tanto las empresas como cualquier tipo de sociedad
tienden a resistirse al cambio, y en el ambiente de TI ya se sabe que aún es muy fuerte la resistencia
de la antigua manera de hacer las cosas a la de la post-revolución digital y a los cambios disruptivos
que introduce.
La resistencia no es sólo a los cambios tecnológicos sino también a los cambios sociales que
requieren los nuevos marcos de gestión del trabajo.
Habrá entonces que estar prevenido porque seguramente en nuestra gestión nos encontraremos
casos de oposición desde a utilizar herramientas modernas (como los tableros Kanban) a cambiar la
manera de relacionarse (como adaptarse al modelo de líder servidor).
Aunque estos conceptos se explicarán en detalle más adelante, lo importante es entender que la
oposición no es sólo a la nueva tecnología sino a la nueva manera de relacionarse que requiere este
nuevo milenio. Y que el problema es que esta oposición les impide a las organizaciones utilizar los
nuevos modelos de comunicación que les permitirían tanto hacia afuera utilizar otra forma de hacer
negocios, como hacia adentro implementar otra manera de organizar el trabajo.
Muchas veces esta oposición se debe a que quienes estaban acostumbrados a “hacer las cosas de
otra manera” tienen un miedo, del que generalmente ni siquiera se percatan, de perder su lugar en la
organización a la que pertenecen.
Se genera así una profecía de autocumplimiento en la que finalmente realmente lo pierden por no
haber querido, podido o sabido cambiar; por no haber aprovechado las oportunidades para
capacitarse en las nuevas tecnologías de gestión, por no haber modificado su conducta de líder
jerárquico, por no haber ayudado a que los equipos se autogestionen, etc.
Y esto ocurre no sólo por no querer dedicar tiempo a estar al tanto de las nuevas tecnologías y
adaptarse al nuevo entorno tecnológico, sino también por no haberse adaptado al nuevo entorno
social y por lo tanto no haber transformado sus competencias para cubrir las nuevas necesidades.

Los nuevos proyectos requieren una nueva manera de organizarse porque requieren adaptarse
a la gran velocidad del mercado actual, para lograr alcanzar sus objetivos a tiempo
eficientemente.
Para lograrlo es necesario contar con las capacidades creativas de todos los miembros de la
organización ya que el recurso humano capacitado es cada vez más el recurso más escaso y más
valioso en la nueva sociedad.
En todo equipo cada vez más hay Millennials, pertenecientes a la Generación Y, que se hicieron
mayores de edad en el nuevo milenio, nacieron en una época de prosperidad económica, saben que
hay trabajo para ellos y en general prefieren no tener un buen empleo a estar en un trabajo que no les
guste por lo que tienden a una alta rotación y es difícil retenerlos.
Según el estudio del 2009 de Delloite4 si bien son personas que necesitan mucho feedback, al
haberse criado con mucha tecnología, Internet y redes sociales son esenciales para asesorar en
tecnología y para obtener alto rendimiento en las organizaciones.
4
Una de las Big Four auditors, junto a PricewaterhouseCoopers, Ernst & Young, y KPMG
20
Son ideales para formar este tipo de equipos porque son más propensos a aceptar responsabilidades
más pronto, no tienen miedo de tomar retos aunque tengan metas un poco ambiguas, reconocen
rápidamente lo que se requiere en el mercado, saben trabajar muy bien en equipo y son muy
apegados a la tecnología. El reto es retenerlos pues para recompensarlos no hay que olvidar que sus
elecciones no son definidas por el salario sino por el estilo de vida.
Con la tecnología que disponemos actualmente es evidentemente más rentable tener sistemas o
máquinas haciendo el trabajo repetitivo y más personas explotando al máximo su capacidad
creativa… y La mejor manera de retener personas creativas es organizarlas en equipos
empoderados5.
Los equipos empoderados están basados en la idea que, aunque puede haber una persona
más inteligente que el resto, no va a ser más inteligente que todos los demás juntos
trabajando en un equipo de este tipo.
De acuerdo con esto es mejor que el trabajo se distribuya por consenso del equipo en lugar de por
una autoridad que indique qué hacer para enfrentar cada problema que aparece, sólo porque “sabe
más” ya que los nuevos problemas requieren nuevas y creativas soluciones, así que estos equipos
además de estar empoderados deben ser auto-organizados.
El equipo auto-organizado resuelve los problemas internamente en lugar de escalarlos y toma

las decisiones en reuniones frecuentes.
En estas reuniones la comunicación debe fluir libremente entre todos los miembros del equipo
enfocados en la entrega de valor y no en seguir procedimientos ya probados sino en modificarlos o
crear nuevos más ágiles.
La idea es ir manteniéndolos ágiles y para ello lo que suele utilizarse es Lean. Esta metodología
implica básicamente replantearse constantemente los procesos buscando eliminar de los mismos
todo aquello que no sea imprescindible para generar valor.
Los equipos se encargan de mantener la información publicada constantemente actualizada y en

“boards” muy visibles para todos los involucrados para aumentar todo lo posible la visibilidad y la
transparencia dentro de la organización en lugar de mantener la información “secreta” y
“compartimentada”.
Estos boards por un lado hacen más difícil ocultar un mal desempeño y por otro facilitan la
colaboración de todos en cada proyecto, o cambio de la organización. Las metodologías de gestión
Agiles permiten abrazar los cambios que se van requiriendo cada vez más rápido en lugar de tratar de
impedirlos porque lo que le importa al equipo no es cumplir un plan preestablecido sino satisfacer al
“cliente”.
Para eso en varias de las metodologías Agile aparece una figura que represente a ese cliente, que
sea el destinatario de la acción del equipo, que le destine el tiempo necesario, que pueda participar
en las reuniones del equipo y que tenga la visibilidad completa de su trabajo.
Este Product Owner es quien puede asignar prioridades basado en su conocimiento del valor
de una característica para la organización pero balanceándola con el esfuerzo que el equipo le
comunica que ésta requerirá para poder implementarla.
Aunque muchos siguen creyendo que estos equipos empoderados auto-dirigidos y auto-organizados
son incompatibles con los equipos distribuidos, hay cada vez más experiencias exitosas de
implementación de metodologías Agiles en equipos con participantes situados en diferentes países.
5
El término empoderado viene del empowerment inglés y se refiere al proceso por el cual se accede
al control y aumenta el poder de un equipo.
21
Estos son facilitados por la globalización y también en parte como causa o consecuencia de la
aparición de nuevas herramientas tecnológicas que permiten la comunicación fluida aún a grandes
distancias como los documentos compartidos, las conferencias múltiples, los boards online, etc. que
además hasta pueden no tener costo para la organización porque cada vez hay más apps gratuitas
para cubrir este tipo de necesidades.
Lo cierto es que cada vez hay más equipos distribuidos, ya sea por la naturaleza geográfica del
proyecto que abarca grandes extensiones geográficas o inclusive el mundo entero o por precisar de
skills y conocimientos específicos que muchas veces dificultan situar en un mismo lugar físico a todos
los integrantes del equipo, y hacen necesario aprovechar estas soluciones tecnológicas que permiten
mantener una comunicación fluida en equipos distribuidos inclusive en distintas zonas horarias, por
ejemplo con apps de Kanban.
A pesar de lo dicho algunas veces debemos seguir enfrentando además de la oposición de la vieja
forma de liderazgo, a otras a la nueva tecnología, como oponerse “por seguridad” a utilizar las app de
la nube… Estas oposiciones aumentan la dificultad que están teniendo las grandes organizaciones
para alcanzar la velocidad que el mundo requiere, por lo que demandan cada vez más líderes que
guíen su incorporación al mundo digital que diariamente incorpora innovaciones de todo tipo,
incluyendo más aplicaciones innovadoras centradas en la satisfacción del usuario.
Progresivamente van aumentando los proyectos que utilizan la tecnología digital para transformar la
actividad cotidiana de las empresas utilizando nuevas tecnologías de generación, almacenamiento y
procesamiento de datos.
Los cambios en el mercado y/o en la demanda de los consumidores traccionan así la transformación
no sólo de los productos y servicios que la empresa utiliza, sino de los que produce y hasta de cómo
los entrega. De ahí que la Internet de las Cosas (IoT) está cambiando la forma en que nos
comunicamos y hacemos las cosas utilizando la tecnología digital para mejorar como las hacemos.
Para una transformación digital no alcanza con implementar tecnología, hay que cambiar la
organización para poder aprovechar al máximo su potencial.
Según un estudio del MIT del 2011 para Negocios Digitales las grandes empresas sí o sí van a tener
que rediseñar sus modelos subyacentes de negocio y operativos tanto como los productos y servicios
resultantes.
Hay algunas empresas a las que ya se les reconoce indiscutidamente haber logrado su
transformación digital y que obtienen el rédito por haberlo hecho como Nespresso.
El sistema de gestión de relación con los clientes de Nespresso basado en la nube ofrece acceso a
las opciones de compras de productos e insumos, al servicio de atención al cliente, etc. utilizando un
acceso omnicanal en los que el resultado es igual visitando físicamente un local, el sitio web con una
computadora, o utilizando una app en un smartphone.
Observando la realidad desde otro ángulo, la investigación del MIT y Capgemini encontró que la
transformación digital exitosa sólo ocurre de arriba hacia abajo, o sea que requiere ser
impulsada desde la parte superior.
Para la transformación digital, los CIOs necesitan moverse más allá de la zona de confort de su papel
tradicional de administradores de costos y convertirse en líderes empresariales que entiendan el
potencial de las nuevas tecnologías y tengan la capacidad de crear nuevos modelos de negocio y de
organización.
22
Cada interesado en un proyecto digital necesita conseguir el apoyo para lograrlo, y aunque según un
estudio de Gartner, la mitad de los CEOs quiere liderar esa transformación a la tecnología de
disrupción digital, la realidad es que en el fondo aún tienen miedo y hay que enfrentar la resistencia
de la que hablábamos unos párrafos atrás, tanto a los cambios disruptivos tecnológicos como a los
cambios sociales que requieren los nuevos marcos de gestión del trabajo. Por eso observamos tanto
una resistencia al hardware de realidad virtual como al cambio de la estructura organizacional a una
menos jerárquica y más basada en el consenso.
Además de los ya enunciados, hay otros dos grandes problemas que encuentran las grandes
empresas para la transición digital:
Insuficientes personas talentosas capacitadas para la revolución digital, e insuficiente apoyo

de la organización.
Esta falta de apoyo de la organización ocurre a pesar que según Harvard Business Review, los
ejecutivos de cinco de las principales industrias (medios masivos de comunicación, de
telecomunicaciones, de servicios financieros, de retail y de seguros) previeron la disrupción digital de
2017.
El VP y CTO global de Hitachi Data Systems (HDS) Hubert Yoshida, nombrado en el 2013 uno de los
"Diez líderes de mayor impacto de la tecnología", afirmó que la transformación digital debería estar no
sólo en la agenda de los directores de TI sino de todos los directores y gerentes generales porque los
negocios están cambiando y advirtió en reiteradas oportunidades el riesgo que corren los que no
cambien de desaparecer frente a competidores más ágiles, que no tienen legacy y pueden usar la
movilidad, la nube o la analítica desde su nacimiento para crecer rápida y exponencialmente.
Como ejemplo de estas nuevas pujantes empresas capaces de adaptarse al nuevo mercado citó el
caso de Marriott que con más de mil personas en su área de TI, ahora compite directamente no
contra otra gran cadena hotelera como sería de esperar, sino contra Airbnb, una startup de ocho años
que en el 2013 tenía solo cinco personas de TI.
Lo que hay que considerar para comprender este fenómeno es que además de usar la tecnología
para innovar, las nuevas empresas digitales usan la tecnología de forma innovadora logrando con
menores costos satisfacer a la nueva generación de consumidores que se ha acostumbrado y
requiere muchas más opciones.
El planteo que también hace H. Y. es que lo digital es una estrategia de negocios. Para poder
transformar el negocio, hay que transformar los cada vez más abundantes datos en información útil
para tomar decisiones de negocios utilizando software de inteligencia de datos, para lo cual los
departamentos de TI deben revertir la cadena de valor de lo que hacen, lo que significa “invertir más
recursos en apps y satisfacción a los usuarios, y menos en manejar la infraestructura, para lo cual
deben virtualizarla y automatizarla”.
Por eso, empresas con TI heredadas importantes han adoptado lo que Gartner comenzó a llamar “TI
bimodal”, para empezar a trabajar en su transformación sin tener que dejar de lado sus inversiones
anteriores.
Otro referente mundial en innovación tecnológica y liderazgo empresarial, Cabrera, ha escrito sobre la
era digital y la redarquía tratando de unir el mundo Agile con las necesidades organizativas de los
grandes corporativos, que son muy diferentes a las de las startups, pequeñas o medianas empresas.
23
Su libro Redarquía es uno de los más importantes sobre las nuevas formas
organizativas en la era digital, planteando que las organizaciones necesitan
mantenerse competitivas frente al cambio discontinuo, el futuro cada vez más
incierto, y la redarquía como nuevo orden emergente.
Él plantea que las organizaciones deben simultáneamente poder explotar la

viejas certezas y explorar la nuevas realidades, obtener resultados confiables y
a la vez innovar y adaptar la cultura y formas de hacer las cosas de la
organización para competir en un mundo digital, ya que la transformación
digital no es un objetivo final sino un proceso de aprendizaje continuo.
Hay nuevos modelos de creación de valor en la era digital, la movilidad, las nuevas tecnologías
sociales, el Big Data y el nuevo talento digital que afectan las expectativas de los usuarios, las
estructuras operativas y los modelos de negocio.
Para conseguir que los productos y servicios de una organización sean percibidos y relevantes en un
mundo digital, una de las más importantes capacidades a desarrollar es la influencia de los líderes
como arquitectos sociales, para que sean capaces de crear las condiciones para que emerjan la
confianza y los compromisos que faciliten la cooperación, establecer credibilidad, comprender a los
demás, conectar emocionalmente y desarrollar las nuevas estructuras que hagan posible la
innovación colectiva.
Para crear nuevas organizaciones capaces de aprender, adaptarse y abordar la complejidad de una
sociedad digital, sin sacrificar su capacidad operativa actual, hay que hacer una reingeniería de la
dimensión social, de la forma tradicional de organizar y aplicar la inteligencia colectiva de una
organización a través de una estructura jerárquica y de procesos de negocio como mecanismo de
coordinación.
Así como la “dimensión de procesos” les dió escalabilidad para capitalizar un crecimiento en un
mercado de oferta, la nueva “dimensión social” les da a las
organizaciones capacidades de adaptación a los cambios, de
gestionar la creciente complejidad y conectar con el genio
colectivo de las personas de la organización en un mercado
esencialmente de demanda.
La dimensión social es lo que da realmente a las organizaciones

su capacidad multimodal, le permite explorar colectivamente las
nuevas oportunidades, en un modo redárquico (de comunidad) y
no jerárquico (organigrama), dotándolas del propósito, la
confianza y la transparencia necesarias para abordar los desafíos de negocio de manera colectiva.
La clave de esta nueva modalidad operativa consiste en reformular la colaboración para que ésta no
sea “algo más que hacer”, un elemento más en la lista de prioridades, sino un medio fundamental
para abordar todas las prioridades del negocio.
Se trata de utilizar el potencial de las nuevas tecnologías sociales para cambiar radicalmente la
cultura empresarial, de modo que se pueda establecer un nuevo paradigma en la gestión y el
liderazgo de las organizaciones, que haga posible los resultados operativos con el aprendizaje y el
trabajo colaborativo. El uso estratégico de la colaboración de masas es la clave de la nueva
modalidad de la organización.
El aprovechamiento de la inteligencia colectiva crea una nueva fuente de ventaja competitiva, y da a

la organización la agilidad y la innovación necesaria para ser competitivos en el nuevo contexto.
24
Por eso, las organizaciones tradicionales van a tener que complementar las estructuras jerárquicas
formales con nuevos modelos de creación de valor en comunidad, rediseñando sus estructuras para
hacer posible esta nueva dimensión social.
Y, a la vez, van a tener que transformar su cultura para hacer posible un nuevo contrato social con
sus trabajadores, para hacer realidad los nuevos valores que hacen posible la colaboración masiva:
redarquía, transparencia, confianza, autonomía, y sentido de propósito para la comunidad.
Transformar la organización no es sencillo. Se trata de dotar a las organizaciones jerárquicas actuales

de una nueva dimensión social que les permitan interactuar con la nueva realidad, aprender,
adaptarse y abordar la complejidad manteniendo su capacidad operativa y los resultados del negocio
durante todo el período que dure la necesaria transformación. No es una cuestión de tecnología sino
de personas, no se trata de poner en marcha una aplicación social que haga posible la colaboración
social, y luego esperar que funcione.
Llegar al destino requiere un planteamiento estratégico, un compromiso al máximo nivel de la

organización y la voluntad de buscar respuestas colectivas a los desafíos a que nos enfrentamos. Es
fundamental que el cambio lo impulsen muchas personas de todos los departamentos, no
sólo los de siempre.
El cambio redárquico integra las prácticas de los medios de comunicación sociales en la gestión del
cambio organizativo, facilitando la escalabilidad y sostenibilidad de los mismos y eliminando muchas
de las limitaciones y patologías de la jerarquía formal.
La redarquía como motor del cambio organizacional permite:
● Reducir el miedo a los cambios e incrementar la confianza, facilitando la colaboración y la

innovación colectiva.
● Movilizar a las personas de la organización hacia el aprendizaje colaborativo y la innovación

colectiva sin importar la jerarquía o posición, en base a sus intereses, pasiones,
conocimientos y experiencia.
● Involucrar a toda la organización en la búsqueda de respuestas creativas a los desafíos

estratégicos.
● Facilitar la búsqueda colectiva de soluciones a los retos del día a día acelerando la adopción
de los cambios.
● Evitar la sobrevaloración del legado y el statu quo haciendo posible que surjan nuevas
perspectivas y realidades que generen la energía que necesitamos para los cambios.
● Involucrar a clientes, distribuidores y canales en el diseño de los productos acelerando la

adopción y aceptación de los mismos por el mercado.
● Redefinir las fronteras del negocio y hacer incursiones en los modelos de negocio de otros.
● Desarrollar nuevos indicadores del progreso en base a la difusión de las nuevas conductas.
● Potenciar la emergencia de verdaderos activistas organizativos defensores de los cambios

que neutralicen a los passion killers de siempre.
25
La redarquía permite hacer algo más que aferrarse a los logros del pasado y evolucionar con los
jóvenes, cuyos valores son los de la web social, hacia un modelo de empresa fundamentalmente
nuevo. Si se logra implantar con éxito una nueva metodología de gestión empresarial, se pueden
superar con éxito los retos estratégicos de un mundo digital y configurar un modelo organizativo que
haga de la innovación y el liderazgo el trabajo de todos.
Basándonos en los cinco pilares para realizar una transformación digital exitosa que cita otro experto,
el CIO de la empresa austriaca Spar, podríamos decir que tenemos que:
● Alinear las personas: Para eso hay que explicar al iniciar el proceso de transformación que es
un proceso que tarda años y no meses, cuáles son los factores que lo impulsan, cuáles son
las tecnologías a utilizar, cuáles son las metodologías a involucrar, etc. Y sobre todo hay que
convencer a las personas concretas que necesitan cambiar.
● Habilitar al personal: Para eso hay que brindarles capacitación y herramientas para realizar la
transformación. Hay que hacer que aprendan nuevas metodologías y tecnologías, y que
mejoren su conjunto de habilidades aceptando que hay un período de ramp up, o sea una
curva de aprendizaje que hace que se demoren los resultados iniciales. E inclusive utilizando
servicios para reducirles trabajo de mantenimiento o tareas repetitivas que solo consumen
tiempo para permitirles capacitarse para la transformación.
● Aprovechar los recursos dentro y fuera de TI: Incluyendo a los expertos y no sólo en
tecnología, sino a proveedores expertos en su tecnología, usando sus recursos de negocios
y entendiendo lo que la empresa necesita hasta a aprovechar la experiencia de los que hacen
el coaching y mentoring para lograr realizar un cambio real que sea productivo y notable.
● Vender bien lo que hacen para poder obtener financiamiento para el siguiente proyecto:
Poniéndolo en términos económicos como “porque hicimos aplicaciones móviles pudimos
acelerar la entrega de servicios, porque hicimos esta analítica pudimos obtener más
ganancias en las ventas, más ventas cruzadas, etc.”.
● Convencer a la junta directiva: La clave de la transformación es el liderazgo. La directiva tiene

que estar comprometida: CEO, CIO, CFO e incluso CMO, para pedir el presupuesto
necesario para realizar cada parte del proyecto. “Tienen que convencer a la junta. Si no van a
invertir el dinero para empezar este viaje, van a ir a la quiebra”, resaltó el experto.
Tenemos entonces que encarar el cambio de dos maneras diferentes dependiendo el tipo de
organización: Si tenemos un startup o una pequeña empresa seguramente nuestro esfuerzo será
sobre todo para convencerlos de las ventajas de fijar procesos repetibles e incorporar una
metodología probada para poder conseguir una rutina afinada para realizar actividades conocidas sin
perder tiempo descubriendo cada vez la pólvora o el hilo negro con cada proyecto porque
seguramente habrá muchos milennials, poca burocracia e implementar metodologías Agile va a
resultarles natural.
Si estamos en un corporativo entonces seguramente no van a necesitar esforzarse para comprender

las ventajas de tener procesos repetibles sino para comprender lo imprescindible de adaptarse al
nuevo milenio, comprender la redarquía e implementar una metodología no basada en procesos
estables que favorece la anticipación sino una ágil que favorece la adaptación e implica estar
dispuestos a adaptar constantemente los procesos.
Una metodología Agile implica muchísimos menos procesos de planificación previa y control
posterior, aunque se planifique y controle más, sólo que constantemente.
26
Lo que seguro sí implica es muchísima más cohesión, más responsabilidad de los equipos, más valor
para enfrentar los desafíos, en suma otro mindset... que es más fácil adoptar en una startup que en
un corporativo.
No hace tanto que se publicó un artículo en un diario argentino, sobre la experiencia de ser parte de
una empresa argentina como 10Pines, que desde hace casi una década brinda soluciones
informáticas y capacitación a clientes como el Grupo Alsea (Starbucks, Burger King), Claro (Argentina
y Uruguay), Fox, MercadoLibre y Tenaris, con una organización horizontal, y la diferencia con la
experiencia de pertenecer a una empresa tradicional con jefes, estructura, y jerarquías.
10Pines tiene un grupo llamado Roots conformado por todos los miembros de la empresa excepto los
recién incorporados, con acceso a toda la información de la compañía, participación en el bono anual
(del 50% de la ganancia bruta de la empresa) y en las decisiones estratégicas. Ellos reciben los
pedidos y deciden tanto si se toma el proyecto como quién se hace responsable.
Al estar en grupos autoorganizados tienen más responsabilidad, libertad y lealtad. Cada uno puede
elegir si trabaja en la oficina o por homeworking, y hasta los sueldos se otorgan en base a lo que la
empresa genera de acuerdo a una tabla pública que contiene todas las personas ordenadas por
mérito, conocimiento, antigüedad y responsabilidades, que revisa periódicamente un grupo
autoconvocado con representantes de todos los proyectos. Evidentemente esta estructura es
impracticable para una gran empresa, pero lo que sí es posible es organizarla con células Agiles en
equipos Scrum como ya lo han hecho otras en otras partes del mundo.
Este artículo puede leerse relacionado con artículos anteriores de casos semejantes de otros países
como el de Semco, la empresa que no tiene jefes - elmundo.es economía.
En el mismo plantean el caso de una empresa autogestionada, el de Semco de Sao Paulo, dedicada
a la producción de maquinaria industrial. Ante una situación de quiebra, los empleados para evitar el
cierre tomaron medidas "autogestionadas".
Tienen un manual de supervivencia de 20 páginas en forma de cómic a modo de normativa de la

empresa. Los trabajadores deciden su horario y salario, y saben lo que cada uno trabaja y gana. Ya
han multiplicado casi por siete su productividad y quintuplicado sus beneficios e incrementado la
plantilla de 100 a 3.000 empleados. Parece ser que la consideran una empresa ideal para trabajar por
los pocos niveles de la escala salarial, por la posibilidad de evaluar periódicamente a sus jefes y
decidir su participación en los beneficios de la empresa. Comparar estos casos con otros semejantes
podría aportarnos mucha información sobre este tipo de empresas.
En otro artículo de hace ya algunos años sobre el banco ING, publicaron que aunque al adoptar
Scrum al principio se seguían manejando presupuestos y cronogramas, flexibilizaron el alcance. Y
que aceptar que el delivery del software no puede ser pronosticado exactamente por adelantado fue
un cambio importante y aumentó el velocity. Los primeros proyectos de Scrum comenzaron en 2011,
obteniéndose una mejora en la productividad y mejoras en la arquitectura que resultaron en mejoras
en el mantenimiento.
La innovación, la energía, la colaboración y la satisfacción de los empleados aumentó drásticamente

y se ganó la confianza del área comercial basado en el éxito de la entrega de software utilizable. Al
año duplicaron los equipos Scrum, algunos con mezcla de personal propio y outsourcers, otros
distribuidos globalmente, pero todos alineados con la Guía de Scrum bajando costos y tiempos de
delivery, y disminuyendo incidentes técnicos. Ya entonces la mayoría de los lanzamientos eran
realizados por equipos Scrum, que demostraron ser capaces de adaptarse rápidamente a las
solicitudes cambiantes del negocio, mientras la comunicación directa eliminó antiguas barreras.
27
También planteaban que para fines de ese año esperaban que todas las entregas de software fueran
hechas por equipos Scrum y continuar el camino de la agilidad a través de Scrum, ya que encontraron
que al resolver cada problema se visibilizan más, y al reconocer que no eran problemas nuevos
pudieron ver la ventaja de exponerlos para que se solucionen, guiados por valores como la
transparencia, disciplina, aprendizaje y mejora continua.
Finalmente, tenemos un artículo publicado en la revista del diario La Nación de Santiago Bilinkis
sobre lo curioso que es que, pese a la reiteración de advertencias y la profundidad de la disrupción, la
mayoría de las personas continúa con su vida igual, sin prepararse para un fenómeno de ocurrencia
probable, cercano y anunciado. La razón para este contrasentido es que existe un sesgo cognitivo
psicológico más fuerte que "ignorar lo improbable", que es la "resistencia al cambio", que nos hace
ignorar todo lo posible lo que nos confronta con la necesidad de cambiar. No importa cuán probable
sea, si el problema aún no nos golpeó elegimos no hacer, y para peor la repetición de advertencias
nos va insensibilizando, dándonos la falsa impresión de haber ya reaccionado y tomado cartas en el
asunto. Y nos dice que aunque el refrán dice que "No hay peor sordo que el que no quiere oír", hay
un tipo de sordo peor: el que no acusa recibo de lo que oye y sin embargo está convencido de que ya
escuchó.
La idea de resumir estas publicaciones es que puedan elegir al menos una para estudiar el caso y
debatirla con sus compañeros en el transcurso de esta primera iteración de 4 semanas,
relacionándola con los 4 temas planteados en este módulo:
• Principios comunes a todas las metodologías Agiles.

• Aportes de Scrum, Lean, XP, etc.
• Continuum metodológico. Del concepto de Bimodal de Gartner a Multimodal actual.
•Gestión de la transformación del management en las organizaciones que no nacieron Agiles. Cambio de
mindset.
28

Principios Agiles

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Principios Agiles

Cargado por

Copyright:

Formatos disponibles

Diplomatura en Metodologías

​Módulo 1: ​Principios Ágiles

Ana Bardoneschi abardoneschi@itba.edu.ar

Paula Elisa Kvedaras pkvedaras@itba.edu.ar

Proyectos, Productos y Operaciones 4

El cambio de pensar en Proyectos a enfocarse en Productos Agiles 5

Los Tres Documentos Básicos de Agile 7

Línea de Tiempo de la Gestión de Proyectos Agiles y Tradicionales 9

Lo que tienen en común las Metodologías Agiles 9

Ciclo de Vida del Proyecto y del Producto 11

Lo que tienen en común las Metodologías Tradicionales y las Agiles 12

Del concepto de Bimodal de Gartner a Multimodal 13

Algunas publicaciones interesantes sobre el cambio de mindset 17

En cambio un cuerpo de conocimientos o de “buenas prácticas” es lo que una asociación de

Proyectos, Productos y Operaciones

Para las metodologías tradicionales un

Seguramente muchos hemos visto versiones

El cambio de pensar en Proyectos a enfocarse en Productos Agiles

El problema de las metodologías tradicionales de gestión de proyectos es que pierden flexibilidad

La aparición de las metodologías Agiles fue el primer cambio significativo en la gestión de

Ambas actualmente se aplican muchas veces juntas en muchas industrias y ya no solo en la de

Los Tres Documentos Básicos de Agile

​ stamos descubriendo formas mejores de desarrollar software tanto por

❏ Enfatiza la importancia de la entrega de un producto utilizable. La documentación por sí

❏ Los planes se realizan cuando menos se conoce de un proyecto.

7. El software funcionando es la medida principal de progreso.

9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

● Nosotros aumentamos el retorno sobre la inversión enfocándonos en el aporte

● Nosotros entregamos resultados fiables involucrando al cliente frecuentemente y

● Nosotros esperamos la incertidumbre y la gestionamos a través de iteraciones, con

● Nosotros damos rienda suelta a la creatividad y a la innovación reconociendo que las

● Nosotros potenciamos el rendimiento a través de la orientación del grupo a los

● Nosotros mejoramos la eficacia y fiabilidad a través de estrategias situacionalmente

Línea de Tiempo de la Gestión de Proyectos ​Agiles​ y ​Tradicionales

Lo que tienen en común las Metodologías Agiles

● Se cambió la noción de equipo tradicional por la de equipos empoderados,

● Se cambió el enfoque jerárquico verticalista ​por ​equipos auto-organizados, ​con lo cual

● Se publica constantemente actualizada la información del progreso del proyecto en

● Se le da participación al cliente durante todo el proyecto, ​se lo incluye en el equipo;

● Se entrega el producto del trabajo en versiones; ​entregas pequeñas y frecuentes;

● Se prueba rápidamente en la realidad​, obteniendo realimentación rápida.

● Se puede implementar la mejora continua porque al final de cada iteración el equipo

Las empresas vienen utilizando hace muchos años el concepto de VUCA

Ciclo de Vida del Proyecto y del Producto

En las metodologías tradicionales tanto el costo como la

Y a lo largo del tiempo observamos que la influencia de

A diferencia de lo que ocurre en Agile que el

Lo que tienen en común las Metodologías Tradicionales y las Agiles

Las dos corrientes metodológicas, las de los Proyectos Agiles

El PMI inclusive ha participado en la redacción de la única norma internacional sobre Dirección de

Aunque hay muchas metodologías ágiles reconocidas para desarrollar

Del concepto de Bimodal de Gartner a Multimodal

Esta propuesta consiste en administrar y coordinar paralelamente dos métodos de entrega de

En el “Modo 1” del corredor de maratón se priorizan la fiabilidad y la eficiencia en los proyectos a

El Modo 1 trata de controlar lo desconocido y el Modo 2 trata de interactuar con el contexto y

Como todos los consultores de TI reconocidos hace mucho hincapié en la necesidad de

El PMI denomina enfoque híbrido a una combinación de enfoques predictivos, iterativos,

1. La primera donde IT estaba aislado, y el foco estaba en la tecnología.

2. La segunda de la industrialización enfocada en el proceso donde lo importante era la

El modo 1 corresponde a la era 2, a la industrialización de IT, efectiva cuando se trabaja de acuerdo a

Al principio se hablaba de un Modo 1 de maratonistas enfocado en la estabilidad y

Seleccionar los primeros proyectos es sumamente importante y debe realizarse cuidadosamente y

Módulo 1: Principios Ágiles

stamos descubriendo formas mejores de desarrollar software tanto por

Línea de Tiempo de la Gestión de Proyectos Agiles y Tradicionales

● Se cambió el enfoque jerárquico verticalista por equipos auto-organizados, con lo cual

● Se le da participación al cliente durante todo el proyecto, se lo incluye en el equipo;

● Se entrega el producto del trabajo en versiones; entregas pequeñas y frecuentes;

● Se prueba rápidamente en la realidad, obteniendo realimentación rápida.

En esta apuesta por la colaboración en lugar de la competencia, para desde la confianza