OKRS ¿QUÉ SON Y CÓMO IMPLEMENTARLAS?

OKR significa Objectives and Key-Results (Objetivos y Resultados-Clave).

La metodología OKR, que es muy similar a la gestión por directrices, ha conquistado cada día más empresas
interesadas en desarrollar la gestión basada en indicadores y metas como camino para una cultura de alto
rendimiento y resultados. algunas veces, un estudio breve sobre la metodología OKR trae más preguntas que
respuestas. Es por eso que preparamos este artículo introductorio con consejos y experiencias sobre la implantación
de la metodología.

¿Qué son las OKRs?

Las OKRs (Objectives and Key Results) son una re lectura de la gestión por metas (Management by
Objectives,  o  MBO) articulada por Peter Drucker. El término Objectives and Key Results surgió a partir del libro High
Output Management, de Andy Grove (ex-CEO de Intel) y fue popularizado en la década del 2000 por John Doerr,
inversor de venture capital y miembro del consejo de administración de Google.

Se trata de un sistema de metas colectivas e individuales, que convergen para la búsqueda de metas globales de una
organización.

La simplicidad y transparencia de las OKRs y sus efectos de enfoque y motivación de equipos hizo con que las OKRs
se volvieran populares muy rápidamente, especialmente entre las empresas de tecnología en el Valle de Silicio.

Su adaptabilidad a diferentes realidades también fue responsable por su gran aceptación. En Google, por ejemplo,
las OKRs fueron adoptadas en el primer año de actividades, cuando la empresa contaba con cerca de 40
colaboradores, y están en uso hasta hoy.

Anatomía de una OKR

Una OKR es compuesta por un objetivo cualitativo acompañado de algunos key-results cuantitativos

y/o mensurables.
Objetivos

Como se puede ver, el objetivo no precisa ser SMART. Por el contrario, los objetivos deben ser cualitativos para no
generar conflictos con los key-results. Buenos objetivos también deben ser buscados: Cuánto más memorables,
mejor. En el caso de arriba, nuestro objetivo es “Ser un dominio respetado por Google” (confieso que era posible
buscar un nombre más inspirado.

Key-Results

Las key-results deben ser métricas y entregables, medirán si fuimos exitosos al alcanzar nuestro objetivo. Por lo
tanto un buen ejercicio para hacer es, si logramos nuestros key-results preguntarnos: ¿habremos conseguido
nuestro objetivo?

Buenas Key-Results son S.M.A.R.T., una antigua sigla que quiere decir:

 Specific, o específico

 Measurable, o mensurable

 Achievable, o alcanzable

 Relevant, o relevante

 Time-bound, o  con fecha de vencimiento

En el caso de arriba, tenemos dos key-results:

 Subir el domain authority a 30 pontos hasta el fin del trimestre (quarter), y

  Aparecer en la primera página de resultados de Google en dos keywords relevantes para nuestro negocio
(en este caso, quedó implícito que la fecha de verificación del key-result era el fin del trimestre)

¿Cuál es la diferencia entre OKRs y metas tradicionales?

OKRs son metas. Entonces ¿por qué todo ese alborozo al respecto? Una buena pregunta. OKRs son una adaptación
de la práctica tradicional de metas a la realidad más inestable y competitiva de las empresas de hoy en día. El
objetivo de este capítulo es explicar las principales diferencias:

 Ciclos más cortos: Las OKRs son creadas y re evaluadas en ciclos menores, que varían entre 1 y 6 meses.

 Más transparencia: Las OKRs generalmente son públicas dentro de una empresa. Ya que están menos
directamente ligadas al compensation (ver abajo), eso deja de ser un problema. Por otro lado, los beneficios
de alineamiento y motivación al tener metas públicas son enormes.

 De abajo para arriba: OKR son definidas de una forma más bottom-up. En MBOs, los objetivos tienden a ser
desdoblados de arriba para abajo de una manera formal y rígida, por el área de planeamiento estratégico o
rendimiento. De esta forma, si todos los funcionarios alcanzaran sus metas, supuestamente la empresa
habría alcanzado sus metas corporativas.

OKRs, por otro lado, son más flexibles: los funcionarios son incentivados a definir sus metas en alineamiento con los
objetivos más elevados (como los de su equipo , o los de la empresa), y después verlos con sus gerentes.

 Moonshots: En algunas empresas, OKRs son alcanzadas cuando sus “dueños” logran 70% de éxito. Entonces,
usted me pregunta, ¿70% es el nuevo 100%? La verdad es que no. La idea es que si los funcionarios, de
manera agregada, apuntasen más alto, alcanzarían más resultados. Así, el % de atención significa menos que
los resultados reales alcanzados.

 OKRs son menos ligadas directamente a la remuneración: en organizaciones meritocráticas hard-core, la

realización del objetivo es la base para la remuneración variable. Si usted logra 100% de las metas, usted
incrementa N veces su salario mensual/anual. (algunas empresas pueden usar esta fórmula con disparadores
de metas de equipo y corporativas), que pueden aumentar o disminuir la distribución. Pero eso puede llevar
al sandbagging en toda la organización: los funcionarios tienden a lograr el piso y negociar metas más
fáciles, para que sea mayor la chance de alcanzarlas.

En las OKRs, el % de conclusión no importa – importan los resultados reales alcanzados. En MBO, el cociente (% de
conclusión de un objetivo) es lo que importa, o un proxy para los resultados. En las OKRs, lo que vale es el
numerador.

OKRs y planeamiento (estratégico)

Planeamientos estratégicos plurianuales pueden parecer una broma en el mundo actual, en el que no conseguimos
ni planear lo que nuestras empresas estarán haciendo en 6 o 8 meses, pero aun así es importante que haya algún
tipo de plan en curso, contra el cual las decisiones puedan ser tomadas en la rutina de la empresa.

Grandes empresas poseen planes (visiones) de 3 o 5 años, y ciclos de metas de 1 año, con “revisiones” semestrales.
“Revisiones” está a propósito entre comillas, pues en toda mi experiencia profesional, nunca vi suceder una revisión
de esas. O mejor dicho, vi, pero eran más para renegociaciones unilaterales:
   
Escenario 1: El funcionario está entregando resultados, y si todo continúa igual, alcanzará con sobra su meta en el
final del año. Su jefe, o alguien de la empresa, intenta a cualquier costo recontratar una meta más agresiva para el
funcionario, pues aquella “había sido demasiado fácil”.

Escenario 2: La empresa entra en un camino lleno de baches, y alcanzar metas se convierte en algo imposible, por
alguna crísis de imagen o un factor exógeno al control del funcionario. Nadie recontrata sus metas, que “no van a ser
alcanzadas”.
Renegociaçiones de meta dentro de un ciclo son un asunto muy delicado. Por eso, deja de tener sentido aplicar
ciclos largos de metas, en favor de ciclos más cortos. Así, los ajustes pueden ser hechos sin que quede la impresión
que las metas son “de mentirita”, y la empresa corrige su curso como sea necesario.

El ritmo que suele funcionar para la mayoría de las empresas está compuesto por un sueño (hablaremos más al
respecto), metas corporativas anuales, y ciclos trimestrales de metas de la empresa, de los equipos, y de los
funcionarios.

 Sueño: la empresa posee una meta misionera/visionaria, que lleva muchos años para ser alcanzada, como
por ejemplo la de una empresa con la que trabajamos, que busca mil millones de downloads para sus
aplicativos.

 OKRs anuales: con base en lo Soñado, la empresa establece metas corporativas anuales, que deben ser
comunicadas por el CEO para toda la empresa a comienzo del año fiscal

 OKRs trimestrales: el CEO de la empresa, al comienzo del año, establece las metas del primer trimestre, y a
partir de ellas, equipos y funcionarios planean las metas tácticas que los levarán más cerca de los objetivos
anuales.

Sueño

La visión a largo plazo de la empresa debe ser representada por un sueño, que, en el caso de Google, es “organizar
las informaciones del mundo y volverlas universalmente accesibles y útiles”. Este sueño debe servir como una
estrella guía para las principales decisiones de la empresa, y un trampolín para cada ciclo de OKRs, sea él anual o
trimestral.

Según Jim Collins, autor de  Good to Great, los sueños deben ser metas grandes, audaces, y unidas al propósito
mayor de la empresa. Como Jorge Paulo Lemann, actualmente el mayor accionista individual de empresas como
Anheuser-Busch InBev, Burger King y Heinz Kraft, dice: “Usted tiene que soñar muy alto, porque soñar alto y soñar
pequeño cuesta el mismo trabajo”. Larry Page de Google y Eric Schmidt dicen lo mismo, así como Jeff Bezos, de
Amazon.

Consejos para implementar OKRs en su empresa

Ahora que ya entendimos bien que son las OKRs y cuál es su importancia, vamos a ofrecer algunos consejos prácticos
de cómo implementarlas en su empresa.

Adapte la metodología a sus necesidades

La metodología OKR posee una serie de características propias, lo que no significa que debe ser implementada de la
misma forma en todas las empresas.

No hay una receta que pueda ser aplicada de forma generalizada con éxito garantizado, ni sirve simplemente
copiarla de otras organizaciones. Antes de adoptarla, es preciso adaptarla a la realidad de su empresa.

Implemente por etapas

Lo ideal es que la introducción de la metodología OKR vaya siendo implementada  gradualmente. Escoja un área para
que funcione como piloto y empiece por ella.

Esta es una forma segura de evaluar el éxito de la metodología y acompañar la adaptación de los colaboradores al
nuevo proceso, que va siendo insertado a la cultura de gestión de la empresa. Después, amplíe el uso de las OKRs
para otras áreas.

Defina ciclos cortos

El éxito de la metodología OKR depende mucho de la definición de ciclos más cortos para el cumplimiento de las
metas. En general, las empresas definen un período de tres meses para el desdoblamiento de las metas individuales
y de equipos.

Tenga un líder y algunos embajadores

Escoger un líder para la implementación de las OKRs en la empresa es una forma de facilitar el proceso de
adaptación a la nueva metodología de metas. Es recomendado que este líder sea uno de los gestores de la empresa.

El deberá estudiar a fondo cómo funciona la metodología, para que pueda comandar todo el proceso. El líder
también será responsable por la creación de un grupo de embajadores de la práctica que tendrá como
responsabilidad garantizar su aplicación correcta y constante en la empresa.

Acompañe las metas regularmente

Durante el proceso de implantación de las OKRs, es importante acompañar semanalmente la evolución de las metas.
Esa es una forma de evaluar si hay alguna dificultad en su aplicación y si es necesario hacer alguna modificación para
seguir con el proceso.

A medida que las personas dominen con más propiedad el uso de las OKRs, esta evaluación podrá ocurrir en
intervalos mayores. Recuerde que las metas deben ser estipuladas para un plazo de tres meses.

Comience por las OKRs de la empresa

El primer paso para determinar las metas es definir las OKRs de la organización. Empiece por metas globales,
trazando los objetivos de la empresa para el período de un año, por ejemplo. A partir de este objetivo anual,
determine metas más específicas, que deberán ser cumplidas siempre en el horizonte de un trimestre.

Después camine hacia las OKRs en áreas

Ahora que los objetivos de la empresa ya están determinados, es preciso escoger las metas por áreas y para los
equipos. Para esta etapa, el consejo es tener prudencia.

No es recomendado iniciar definiendo un gran número de metas, ni metas muy  ambiciosas, que puedan confundir o
sobrecargar a los colaboradores. Lo ideal es comenzar por metas más simples, para que todos puedan contribuir y
acompañar su evolución, comprendiendo mejor el funcionamiento de la metodología.

Alcanzar metas más fáciles puede ser un impulso para desafíos mayores, que vendrán con la implantación de
indicadores más osados en los ciclos posteriores.

Involucre a los colaboradores en la definición de metas

Después de uno o dos ciclos de metas para los equipos, es hora de determinar las metas individuales. Una práctica
adoptada por las empresas exitosas al implementar OKRs que debe ser observada es: Los propios colaboradores
participan de la definición de sus metas.

En general, las OKRs individuales son definidas en parte por los líderes de la empresa (40% de ellas) y en parte por
los propios colaboradores (60%). Pero está claro que esto no sucede de forma aleatória.

Es preciso que los gestores reúnan a sus equipos y, con base en las metas globales de la empresa, determinen la
forma en que cada uno de los miembros puede colaborar para que la organización alcance  sus objetivos.

Lo ideal es que cada colaborador tenga entre 3 y 5 OKRs para cumplir en cada ciclo.

Errores comunes en la utilización de las OKRs

La metodología OKR puede ser un gran diferencial en los procesos de su empresa. Pero es preciso tomar algunos
cuidados para garantizar su éxito. Vea algunos errores comunes en la hora de implementar OKRs:

No acompañar las OKRs (set and forget)

Una meta que no es acompañada puede caer en el olvido. Su acompañamiento periódico contribuye para el
comprometimiento de quien debe alcanzarla.
No respetar la implantación por fases

Trabajar con OKRs presupone un cambio en la cultura de la empresa. Y eso precisa ocurrir de forma gradual.

No tener un líder y champions

Más que un coordinador del proyecto, el líder es el gran incentivador de la implantación da metodología OKR en la
empresa. Como dice Jorge Paulo Lemann, “todo tiene que tener un dueño”.

Falta de comunicación y alineamiento

Las OKRs son metas que convergen para un objetivo mayor de la empresa. Por eso, es preciso que las áreas
intercambien informaciones y auxilios. Difícilmente el trabajo de un área no influenciará en las otras.

LA IMPORTANCIA DE LOS RITUALES EN LA PRÁCTICA DE LOS OKR (OBJETIVOS Y RESULTADOS CLAVE)

Quizás el peor error en la implementación de la metodología OKR ( Objectives & Key-Results ), sea el error en aplicar
correctamente y aprovechar el conjunto de rituales que sirven para apoyar la práctica de la gestión ágil de metas.

Por supuesto, cuanto más fluida, menos burocrática, sea la práctica, mejor. Sin embargo, seamos realistas, el camino
nunca va directamente del cinturón blanco al cinturón negro, ¿verdad? La formalización de ciertos rituales es crucial
para la efectividad de la metodología, especialmente en los ciclos iniciales de implementación, así como un paso
importante en la creación de una cultura organizacional enfocada a resultados. En las próximas líneas explicaré qué
ritos son los más importantes.

Ritual de formulación

Objetivo: Definición de los OKR del ciclo

Frecuencia: Trimestral

Este es el ritual donde se establecen las metas de un ciclo dado.

En cada comienzo del ciclo, es crucial invertir el tiempo de los equipos para que los objetivos se construyan de
manera participativa, aumentando el compromiso y la propiedad de todo el equipo. Recuerde que, en general, al
menos el 60% de los objetivos deben construirse de abajo hacia arriba en la organización.

Ritual de validación

Objetivo: Traducir y validar los OKR de la empresa y departamentos.

Frecuencia: trimestral

Consideramos de suma importancia que toda la empresa, en la medida de lo posible, participe en un ritual para
validar los objetivos de la empresa y de los equipos. La práctica de la validación genera, una vez más, el importante
buy-in necesario para que todos asuman el control de los resultados de la empresa. Este es también el momento de
discutir las posibles dependencias entre los resultados de cada equipo (por ejemplo, el objetivo de ventas del equipo
comercial debe estar alineado con el objetivo de capacidad del equipo de DevOps para que no haya sorpresas en el
futuro). También es hora de calibrar los OKR: compruebe si los objetivos de diferentes áreas están en el mismo nivel
de dificultad. Este ritual concluye con el compromiso de todos con los OKR contratados.

Ritual de progreso

Objetivo: Evaluar la relación de lo que se está haciendo (esfuerzo) con lo que se está logrando (resultado).
Frecuencia: semanal y mensual.

En los rituales semanales, la idea es una evaluación táctico-operativa, en la que el propio equipo analiza si sus
esfuerzos (proyectos y acciones) se están traduciendo en resultados y, en consecuencia, avance hacia los
OKRs. Sugerimos una reunión de planificación al comienzo de la semana y una reunión de control al final de la
semana, donde se identifican y celebran los logros.
Mensualmente (generalmente al comienzo de cada mes), el liderazgo de la empresa debe sentarse y evaluar si la
empresa en su conjunto está dando pasos hacia sus objetivos de ciclo. No se supone que sea una reunión para
presentar resultados, sino una reunión para resolver problemas, enfocada a las correcciones que son necesarias para
llegar allí.

ritual de legado

Objetivo: Presentar resultados y generar conocimientos sobre los logros y derrotas del ciclo.
Frecuencia: trimestral

Al final de cada trimestre, es interesante que el CEO de la empresa presente los resultados obtenidos, en forma de
OKR de la empresa, en una reunión de todos. Aquí, también, la atención debe centrarse en el aprendizaje y no en la
asignación de culpa (señalar con el dedo), que puede ser extremadamente perjudicial para la cultura de resultados
de la empresa.

FEEDBACKS: CUANTO MÁS, MEJOR

Hecho: Cuantos más feedbacks son intercambiados entre colaboradores dentro de una organización, mejores son los
resultados individuales (y como consecuencia los resultados de la empresa).

Los Feedbacks también son muy buenos para la carrera. En el libro, Thanks for the feedback: The Science and Art of
Receiving Feedback Well,  Douglas Stone y Sheila Heen exponen los resultados de una extensa investigación donde
muestran que profesionales que buscan feedbacks con frecuencia, especialmente feedbacks constructivos, son
percibidos como más competentes, se establecen en nuevos papeles más rápidamente y poseen un desempeño
mayor que la media.

Pero al final, ¿que significa feedback?

La palabra Feedback viene de la conjunción de dos palabras de origen inglesa: “Feed” y “Back”. Al pie de la letra,
podría ser traducido como “Retroalimentación” o “Retroacción”. Vamos a dar una definición más práctica:

Feedback es el proceso por el cual una persona ayuda a otra a desarrollarse por medio de sus propias percepciones
(sean positivas o negativas).

Idealmente, se parte siempre de la premisa que la intención del emisor es de genuino interés en el desarrollo del
receptor. En caso que el motivo del feedback sea otro, y no este, es solo una forma de descargar las propias
frustraciones.

Pero este artículo no es un paper académico sobre el origen del feedback:  es  una provocación para que usted
(profesional de recursos humanos y/o ejecutivo) revea su modelo de gestión de rendimiento basado en
ciclos extensos y cansadores de Evaluaciones de Desempeño y pensar en un modelo más fluido y constante, donde
las personas son vistas como agentes de cambios y donde el fantasma de la “inmadurez” no asusta más. Llamaremos
a este nuevo modelo de Feedbacks Continuos.

¿Por qué los Millennials precisan de Feedbacks Continuos?

Hasta el 2025, los famosos Millennials (aquellos nacidos entre 1980 y el 2000) van a representar, aproximadamente,
75% de la fuerza de trabajo mundial. Nos guste o no, esta es una realidad que no tiene vuelta. Siendo así, es papel
fundamental de las organizaciones entender cómo esa generación trabaja y qué es lo que buscan.

Entre sus características, el espíritu emprendedor es la más destacada. Esto está relacionado con el hecho que los
Millennials sueñan muy alto y que, en su gran mayoría, aspiran a cargos de liderazgo. Están tan determinados a
alcanzar tales objetivos que cada vez  buscan más herramientas y prácticas capaces de ayudarlos a alcanzar sus
sueños.

Partiendo de la premisa del genuino interés por el otro y de la total  transparencia, los feedbacks entran como una
práctica capaz dirigir nuestras acciones y comportamientos en dirección a nuestros sueños trayendo inputs de
mejoras y reforzando comportamientos positivos. Los millennials no solo están abiertos a recibir feedbacks sino que
los buscan todo el tiempo.
 Fonte: Harvard Business Review

Si usted pide para dar un feedback a su funcionario a fin de año, créalo: ¡Él probablemente no estará más ahí para
recibirlo!

¿Por qué feedbacks continuos contribuyen para una cultura de Growth Mindset?

Growth Mindset, (lo contrario de Fixed Mindset) es la escuela científica que defiende que inteligencia, creatividad y
habilidades son mutables a partir de práctica, aprendizaje y esfuerzo, contrariamente de estáticas e inmutables. Y
por este motivo, estas son las características de aquellas personas que alcanzan niveles superiores de realización
personal y profesional. El infográfico de abajo define muy bien la diferencia entre el Growth mindset y el Fixed
Mindset y estoy seguro de que usted se sentirá representado en por lo menos algunas de las afirmaciones:

Fonte: 7 steps to adopting a Growth Mindset at your school

La visión que podemos desarrollar nuestras habilidades, si les dedicamos esfuerzo y estudio, altera
fundamentalmente las relaciones de trabajo, que antes eran basadas en una visión más rígida y juzgadora de el
rendimiento de los funcionarios.

Si conectamos los puntos, se hace evidente que feedbacks y Growth Mindset tienen mucho en común. Ya que los
feedbacks son una gran herramienta de apoyo para aquellas personas que desean enfrentar los desafíos como
oportunidades y que desean alcanzar niveles de excelencia que no eran imaginables antes.

Pero eso no e solo un capricho: una cultura de crecimiento y desarrollo de  resultados prácticos, contribuye con el
sentido de urgencia, con generación de resultados, y lo más importante, con la mejoría continua de procesos,
prácticas e indicadores.

¿Por qué los feedbacks continuos son buenos para su negocio?

Piensen en las ventajas de recibir feedbacks continuos como algo similar a las ventajas de un GPS con relación a un
Mapa de Papel. Ambos ofrecen instrucciones  para su destino. El GPS, lo guía en el contexto de una evaluación
precisa del lugar donde usted se encuentra en el momento. De la misma forma, en tiempos donde no solo
cambiamos como todo a nuestro alrededor también cambia rápidamente, es importante aprender continuamente
sobre cómo podemos mejorar nuestro rendimiento superando así obstáculos y desafíos.
Análogamente piense en un Avión con un GPS/Sistema de Navegación que solo muestra la posición del avión de
hora en hora. Es probable que si este avión no se cae, demore mucho más que lo normal para alcanzar su destino.

Con nosotros no es diferente. Si esperamos un año para dar feedbacks a nuestros liderados es probable que hasta
allí, ellos ya hayan renunciado de tanta  frustración. También es probable que estén afuera de la ruta deseada pues
su “GPS” no está funcionando de manera adecuada.

Para finalizar, es evidente que más feedbacks tienen un impacto significativo en el resultado de la empresa.
Acompañe conmigo dos rápidas líneas de raciocinio:  Cuanto más feedback, menos las personas – y la empresa – se
desvían de su ruta planeada (la estrategia). Así, es menor el gap entre estrategia y ejecución.

Paralelamente, cuanto más feedback, más desarrollo, y en consecuencia, más rápido acumulamos habilidades y
competencias. Cuánto más habilidades y competencia acumulamos, más preparados estamos para encarar desafíos
y superar obstáculos. Cuánto más desafíos y obstáculos superamos, más próximos de nuestros sueños estaremos.
Cuánto más cerca estemos de nuestros sueños, más motivados estaremos. Cuánto más motivados estemos, más
entregamos. Y cuánto más entregamos, más crece la empresa, consecuentemente ¡más lucro es generado!

¿Estoy convencido y quiero comenzar. ¿Pero por donde?

Claro que la teoría no tiene en cuenta la complejidad de tales cambios en la práctica. El psicólogo Daniel Coleman
afirma que “Las amenazas a nuestra posición a los ojos de los otros son extremadamente potentes biológicamente,
casi como aquellas amenazas a nuestra supervivencia”. O sea, biológicamente hablando, no estamos preparados
para recibir feedbacks, puesto que nuestros cerebros interpretan estos mensajes como una amenaza a nuestra
supervivencia.

Por otro lado, también no estamos preparados para dar feedbacks ya que tememos la posición defensiva del otro y
más todavía tememos causar malos sentimientos y desentendimientos.

Mi respuesta: Tomando en cuenta esta última posición negativa y evaluándola comparativamente con las ventajas
antes y depués citadas:

¡Feedbacks, cuánto más mejor! (justificada en las líneas siguientes)

Usted probablemente debe estar pensando, ¿Pero un feedback mal dado puede ser destructivo e ineficiente, no?.

Podemos y debemos mejorar la forma cómo damos y cómo recibimos estos mensajes, y por ser procesos tan
relevantes serán abordados en otros posts. El principal motivo por el cual las personas en general tienen dificultades
en recibir y dar feedbacks no es la falta de competencia y sí la falta de frecuencia.

Los Feedbacks deben ser intercambiados frecuentemente y en la medida de lo posible en tiempo real, lo que
significa que las personas deben recordar lo que sucedió. Si tiene algo que decir, ¡dígalo! Piense antes de hablar,
claro, pero ¡dígalo! Sus percepciones pueden ser de extrema importancia al proceso de desarrollo de otras personas,
ayudar y acompañar el crecimiento de otros, no hay precio que pague esto.

Ese intercambio no es solo placentero sino también educativo en la medida que cuánto más intercambiamos
mejores y más precisos se vuelven nuestros mensajes. Y en la medida que también mejoramos nuestro mensaje
ayudamos al otro y aprendemos a recibir de forma más eficiente sus percepciones.

En mi opinión, este proceso es enriquecedor ya que al  aprender a recibir y dar feedbacks entendemos que todavía
tenemos mucho trabajo por hacer y que aceptar que somos seres en desarrollo abre espacio para abrazar desafíos,
persistir al enfrentar obstáculos, ver el esfuerzo como un camino para la excelencia y aprender con las críticas resulta
inevitablemente, en niveles superiores de excelencia y más conquistas.

OKR VS. KPI: LA SOPA DE LETRAS QUE NECESITAS CONOCER

OKR y KPI son dos siglas muy presentes en el día a día de una empresa, pero ¿sabes cuáles son las diferencias entre
ellas y cuál es la importancia de cada una para un negocio?

¿Qué es un KPI? ¿Y un OKR?: OKR vs. KPI

OKR ¿qué es? Es una sigla que significa Objectives and Key Results, o sea, objetivos y resultados clave. Como su
nombre lo indica, son los objetivos y resultados esperados que sirven como base de los resultados medibles.

Es decir, los OKR de una empresa permiten que todos estén alineados en relación con los objetivos y resultados
esperados para el negocio en un determinado periodo.

Y ¿Qué es un KPI? KPI es la sigla de Key Performance Indicators. KPI en español significa “Indicador clave de
desempeño”. Entonces, los KPI son métricas usadas para hacer seguimiento a los resultados de determinadas
acciones o proyectos en una empresa.

En otras palabras, los KPI son números medibles que permiten obtener insights sobre el desempeño del
negocio. Para ello, deben ser analizados constantemente para que sea posible entender lo que está funcionando y lo
que debe ser mejorado para apalancar los resultados.

OKR vs. KPI: ¿Cuál es la diferencia entre KPI y OKR? 

Un KPI siempre será un valor medible, una métrica, mientras que un OKR será un objetivo o un resultado
clave. Por ejemplo, “Tasa de abandono” puede ser un KPI de ventas y “aumentar la retención de clientes” (objetivo)
“en un 15%” (resultado clave) puede ser el OKR.

A pesar de las diferencias entre OKR vs. KPI, ambas metodologías son complementarias: mientras los KPI muestran
cómo está el desempeño del negocio, los OKR determinan cuáles son los objetivos y resultados que deben ser
logrados.

Para entender mejor las diferencias entre las dos siglas, es importante saber cuál es la diferencia entre métrica e
indicador.

Una métrica es un número absoluto, un indicador es una información más estratégica que permite evaluar el
desempeño de un negocio. Es justamente por eso que OKR y KPI caminan de la mano.

Lee también: 10 tipos de indicadores de desempeño para los procesos.

¿Por qué es importante establecer los OKR y KPI?

Al definir los OKR y KPI, será posible hacer análisis más precisos sobre el desempeño de toda la empresa y de sus
respectivas áreas en un determinado período. Además, el seguimiento de esa información permite hacer
comparaciones para entender lo que evolucionó y lo que todavía debe ser mejorado.

Resaltando una observación importante: aunque sea ideal que los OKR sean los mismos para toda la empresa, los
KPI deben ser específicos para cada equipo. Finalmente, todos los colaboradores deben estar enfocados en lograr
los objetivos de la empresa, pero cada área tendrá su propia estrategia para conseguirlo.

Por eso, es natural que los KPI de Marketing sean diferentes a los KPI de atención al cliente, que a su vez serán
distintos de los KPI de ventas. Lo esencial es que todos esos indicadores estén alineados con los OKR del negocio.

¿Cómo implementar los OKR? 

Para definir e implementar los OKR, debes preguntarte: “¿Qué quiero lograr (objetivo)? ¿Cómo puedo medir si
estoy en camino correcto (resultados clave)?”. Además, recuerda que es importante ser conciso al establecer esa
información.

Y no sólo eso: los OKR deben ser claros para que toda la empresa comprenda cuáles son los objetivos del negocio. Es
por eso que son amplios, como: “Volverse una marca referencia en el mercado”, pues sirven como un punto de
referencia para las metas que serán trazadas. 

Es eso lo que hará que los OKR sean implementados con éxito, dado que dictarán los caminos a seguir. Además,
todos los OKR deben deben tener plazos para ser cumplidos y responsables, sea una persona o un área entera.

¿Cuáles son algunos ejemplos de OKR?

“Aumentar la satisfacción de los clientes con la atención de la empresa” es un buen ejemplo de OKR. El objetivo
aquí es que los clientes queden más satisfechos con la atención prestada.

Los resultados clave que mostrarán que la empresa está en el camino correcto para lograrlo pueden ser: obtener
un NPS de 75 o más -que es la zona de excelencia- en los próximos 3 meses como plazo y reducir en un 15% el
tiempo promedio de espera para ser atendido, en los próximos dos meses.

Otro ejemplo de OKR es “Volverse una marca referencia en el mercado”. El objetivo es estar entre las mejores
empresas de su nicho de actuación. Un ejemplo de resultado clave para eso, es lograr 60% del market share o
participación de mercado en el periodo analizado.

¿Cómo definir un buen KPI?

El primer paso para definir los KPI de forma asertiva es establecer una planeación estratégica, pues será a partir de
ahí que podrás escoger lo que debe ser monitoreado y lo que de hecho está alineado a los OKR de la empresa.

Después, debes crear tus metas y objetivos con base en la metodología SMART, es decir, deben ser:

 específicos (“specific”);

 medibles (“measurable”);

 alcanzables (“attainable”);

 relevantes (“relevant”);

 temporales (“time based”). 

Finalmente, es necesario definir cuál será el período de seguimiento de esa información y cuáles equipos serán
responsables de cada KPI.

¿Cuáles son algunos ejemplos de KPI?

“Tasa de abandono” es un buen ejemplo de KPI, pues debe ser un punto de atención importante para las empresas,
sea un abandono de carrito o de atención. Cuando un cliente desiste de continuar su recorrido con la empresa, eso
indicará que hay alguna falla en el proceso, por eso el mejoramiento de ese KPI debe estar constantemente en el
radar.

El “CAC”, sigla para “Costo de Adquisición del Cliente”, es otro ejemplo de KPI. Este indicador sirve para medir
cuánto cuesta adquirir un cliente, entonces entre más bajo sea este número, mejor para la empresa.

METODOLOGIA AGILE
El desarrollo ágil de software se refiere a las metodologías de desarrollo de software centradas en la idea de
desarrollo iterativo, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos
multifuncionales autoorganizados. El valor máximo en el desarrollo ágil es que permite a los equipos entregar valor
más rápido, con mayor calidad y previsibilidad, y una mayor aptitud para responder al cambio. Scrum y Kanban son
dos de las metodologías ágiles más utilizadas. A continuación se muestran las preguntas más frecuentes sobre Agile y
Scrum, respondidas por nuestros expertos.

¿QUÉ ES AGILE?

El desarrollo de software ágil se refiere a un grupo de metodologías de desarrollo de software basadas en el

desarrollo iterativo, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos
multifuncionales autoorganizados. Los métodos ágiles o los procesos ágiles generalmente promueven un proceso de
gestión de proyectos disciplinado que fomenta la inspección y la adaptación frecuentes, una filosofía de liderazgo
que fomenta el trabajo en equipo, la autoorganización y la responsabilidad, un conjunto de mejores prácticas de
ingeniería destinadas a permitir la entrega rápida de software de alta calidad, y un enfoque comercial que alinea el
desarrollo con las necesidades del cliente y los objetivos de la empresa. El desarrollo ágil se refiere a cualquier
proceso de desarrollo que esté alineado con los conceptos del Manifiesto Ágil. El Manifiesto fue desarrollado por un
grupo de catorce figuras líderes en la industria del software, y refleja su experiencia sobre los enfoques que
funcionan y los que no para el desarrollo de software. Leer más sobre elManifiesto ágil. ¿Sabías que Agile también se
puede aplicar a proyectos de hardware? Conozca el revolucionario marco Agile para hardware de Cprime .

Obtenga más información y plantillas de murales para comenzar con Agile

¿QUÉ ES SCRUM?

Scrum es un subconjunto de Agile. Es un marco de proceso ligero para el desarrollo ágil y el más utilizado.

 Un "marco de proceso" es un conjunto particular de prácticas que deben seguirse para que un proceso sea
coherente con el marco. (Por ejemplo, el marco del proceso Scrum requiere el uso de ciclos de desarrollo
llamados Sprints, el marco XP requiere programación en pares, etc.)

 “Ligero” significa que la sobrecarga del proceso se mantiene lo más pequeña posible, para maximizar la
cantidad de tiempo productivo disponible para realizar un trabajo útil.

Un proceso Scrum se distingue de otros procesos ágiles por conceptos y prácticas específicos, divididos en las tres
categorías de roles, artefactos y cajas de tiempo. Estos y otros términos utilizados en Scrum se definen a
continuación. Scrum se usa con mayor frecuencia para administrar software complejo y desarrollo de productos,
utilizando prácticas iterativas e incrementales. Scrum aumenta significativamente la productividad y reduce el
tiempo de obtención de beneficios en relación con los procesos clásicos de " cascada ". Los procesos de Scrum
permiten a las organizaciones ajustarse sin problemas a los requisitos que cambian rápidamente y producir un
producto que cumpla con los objetivos comerciales en evolución. Un proceso Scrum ágil beneficia a la organización
ayudándola a

 Incrementar la calidad de los entregables

 Afronte mejor el cambio (y espere los cambios)

 Proporcione mejores estimaciones mientras dedica menos tiempo a crearlas

 Tener más control sobre el cronograma y el estado del proyecto.

¿CUÁLES SON LOS BENEFICIOS DE AGILE?

Beneficios para el cliente

Los clientes encuentran que el proveedor responde mejor a las solicitudes de desarrollo. Las características de alto
valor se desarrollan y entregan más rápidamente con ciclos cortos que con los ciclos más largos favorecidos por los
procesos clásicos de "cascada".

Beneficios para los proveedores

Los proveedores reducen el desperdicio al concentrar el esfuerzo de desarrollo en características de alto valor y
reducen el tiempo de comercialización en relación con los procesos en cascada debido a la disminución de los gastos
generales y la mayor eficiencia. Una mayor satisfacción del cliente se traduce en una mejor retención de clientes y
referencias de clientes más positivas.

Beneficios para los equipos de desarrollo

Los miembros del equipo disfrutan del trabajo de desarrollo y les gusta ver su trabajo utilizado y valorado. Scrum
beneficia a los miembros del equipo al reducir el trabajo no productivo (por ejemplo, escribir especificaciones u
otros artefactos que nadie usa) y darles más tiempo para hacer el trabajo que disfrutan. Los miembros del equipo
también saben que se valora su trabajo, porque los requisitos se eligen para maximizar el valor para los clientes.

Beneficios para los gerentes de producto

Los gerentes de producto, que suelen ocupar el puesto de propietario de producto, son responsables de hacer
felices a los clientes asegurándose de que el trabajo de desarrollo esté alineado con las necesidades del
cliente. Scrum facilita esta alineación al brindar oportunidades frecuentes para volver a priorizar el trabajo, para
garantizar la máxima entrega de valor.

Beneficios para los gerentes de proyectos

Los gerentes de proyectos (y otros) que cumplen el rol de ScrumMaster encuentran que la planificación y el
seguimiento son más fáciles y más concretos, en comparación con los procesos en cascada. El enfoque en el
seguimiento a nivel de tarea, el uso de Burndown Charts para mostrar el progreso diario y las reuniones diarias de
Scrum, en conjunto, le dan al Project Manager una tremenda conciencia sobre el estado del proyecto en todo
momento. Esta conciencia es clave para monitorear el proyecto y para detectar y abordar los problemas
rápidamente.

Beneficios para las PMO y los ejecutivos de nivel C

Scrum proporciona una alta visibilidad del estado de un proyecto de desarrollo a diario. Las partes interesadas
externas, como los ejecutivos de nivel C y el personal de la Oficina de gestión de proyectos, pueden utilizar esta
visibilidad para planificar de manera más eficaz y ajustar sus estrategias en función de información más sólida y
menos especulaciones.

¿CUÁLES SON LOS REQUISITOS DE SCRUM?

Scrum no define solo qué forma deben tomar los requisitos, sino que simplemente dice que se recopilan en el
Product Backlog y se denominan genéricamente como "Product Backlog Items" o "PBI" para abreviar. Dada la
naturaleza de caja de tiempo de un Sprint, también podemos inferir que cada conjunto debería requerir mucho
menos tiempo para implementarse que la duración del Sprint. La mayoría de los proyectos de Scrum toman prestada
la práctica "XP" (Programación extrema) de describir una solicitud de función como una "Historia de usuario",
aunque una minoría utiliza el concepto más antiguo de un "Caso de uso". Iremos con la opinión de la mayoría aquí y
describiremos tres artefactos de requisitos razonablemente estándar que se encuentran en los registros de
productos.

Historia del usuario

Una historia de usuario describe una característica deseada (requisito funcional) en forma narrativa. Las historias de
usuario suelen estar escritas por el propietario del producto y son responsabilidad del propietario del producto. El
formato no está estandarizado, pero normalmente tiene un nombre, texto descriptivo, referencias a documentos
externos (como capturas de pantalla) e información sobre cómo se probará la implementación. Por ejemplo, una
historia puede parecerse a lo siguiente:

Nombre: el planificador ingresa un nuevo contacto en la libreta de direcciones, para que uno pueda contactar a la
persona más tarde por correo postal o electrónico
Descripción: El planificador ingresa información de contacto estándar (nombre y apellido, dos líneas de dirección,
ciudad, estado, código postal, país, etc.) en la pantalla de ingreso de contactos. Uno hace clic en "Guardar" para
mantener los datos y "Cancelar" para descartar los datos y volver a la pantalla anterior.

Cómo probar: El probador ingresa y guarda los datos, busca el nombre en la libreta de direcciones y hace clic en
él. Uno ve una vista de solo lectura de la pantalla de ingreso de contactos, con todos los datos ingresados
previamente.

Los elementos de esta historia de usuario son:

1. Nombre: El nombre es una frase u oración descriptiva. El ejemplo utiliza una organización básica de
"función-acción-razón". Otro estilo común, popularizado por Mike Cohn, sigue la plantilla "Como <tipo de
usuario>, quiero <algún objetivo> para que <algún motivo>". La elección de la plantilla es menos importante
que tener un estándar viable de algún tipo.

2. Descripción: esta es una descripción de alto nivel (poco detalle) de la necesidad que se debe cumplir. Para
los requisitos funcionales (orientados al usuario), la descripción se presenta en forma narrativa. Para
requisitos no funcionales, la descripción se puede redactar de cualquier forma que sea fácil de entender. En
ambos casos, la clave es que el nivel de detalle es modesto, porque los detalles finos se resuelven durante la
fase de implementación, en las discusiones entre los miembros del equipo, los propietarios de productos y
cualquier otra persona involucrada. (Este es uno de los conceptos centrales de Scrum: los requisitos se
especifican a un nivel que permite una estimación aproximada del trabajo requerido para implementarlos,
no en detalle).

3. Pantallas y documentos externos: si la historia requiere cambios en la interfaz de usuario (especialmente los
que no son triviales), la historia debe contener o enlazar a un prototipo de los cambios. También se deben
enumerar todos los documentos externos necesarios para implementar la historia.

4. Cómo probar: La implementación de una historia se define como completa si, y solo si, pasa todas las
pruebas de aceptación desarrolladas para ella. Esta sección proporciona una breve descripción de cómo se
probará la historia. En cuanto a la característica en sí, la descripción de los métodos de prueba es breve, con
los detalles que se trabajarán durante la implementación, pero necesitamos al menos un resumen para guiar
el proceso de estimación.

Hay dos razones para incluir la información sobre cómo probar la historia. La razón obvia es guiar el desarrollo de
casos de prueba (pruebas de aceptación) para la Historia. La razón menos obvia, pero importante, es que el equipo
necesitará esta información para estimar cuánto trabajo se requiere para implementar la historia (ya que el diseño y
la ejecución de la prueba es parte del trabajo total).

Historia

No todos los requisitos para un nuevo desarrollo representan características de cara al usuario, pero representan un
trabajo importante que debe realizarse. Estos requisitos a menudo, pero no siempre, representan el trabajo que se
debe realizar para admitir las funciones de cara al usuario. A estos requisitos no funcionales los denominamos
"Historias técnicas". Las Historias técnicas tienen los mismos elementos que las Historias de usuarios, pero no es
necesario convertirlas en narrativas si no hay ningún beneficio al hacerlo. Las historias técnicas generalmente las
escriben los miembros del equipo y se agregan al Backlog del producto. El propietario del producto debe estar
familiarizado con estas historias y comprender las dependencias entre estas y las historias de usuario para clasificar
(secuenciar) todas las historias para su implementación.

Defecto

Un Defecto, o informe de error, es una descripción de una falla del producto para comportarse de la manera
esperada. Los defectos se almacenan en un sistema de seguimiento de errores, que puede o no ser físicamente el
mismo sistema que se utiliza para almacenar la Pila de Producto. De lo contrario, alguien (generalmente el
propietario del producto) debe ingresar cada defecto en la lista de trabajos pendientes del producto, para
secuenciarlo y programarlo.
¿CUÁLES SON LOS ROLES DE SCRUM?

Los tres roles definidos en Scrum son ScrumMaster, Product Owner y Team (que consta de miembros del
equipo). Las personas que cumplen estos roles trabajan en estrecha colaboración, todos los días, para garantizar el
flujo fluido de información y la rápida resolución de problemas.

ScrumMaster

El ScrumMaster (a veces escrito "Scrum Master", aunque el término oficial no tiene espacio después de "Scrum") es
el guardián del proceso. El ScrumMaster es responsable de hacer que el proceso funcione sin problemas, de eliminar
los obstáculos que afectan la productividad y de organizar y facilitar las reuniones críticas. Las responsabilidades de
ScrumMasters incluyen

 Enséñele al Product Owner cómo maximizar el retorno de la inversión (ROI) y cumplir sus objetivos a través
de Scrum.

 Mejorar la vida del equipo de desarrollo facilitando la creatividad y el empoderamiento.

 Mejore la productividad del equipo de desarrollo de cualquier forma posible.

 Mejore las prácticas y las herramientas de ingeniería para que cada incremento de funcionalidad pueda
enviarse potencialmente.

 Mantenga la información sobre el progreso del equipo actualizada y visible para todas las partes.

En términos prácticos, ScrumMaster necesita comprender Scrum lo suficientemente bien como para capacitar y
orientar a los otros roles, y educar y ayudar a otras partes interesadas que están involucradas en el proceso. El
ScrumMaster debe mantener un conocimiento constante del estado del proyecto (su progreso hasta la fecha) en
relación con el progreso esperado, investigar y facilitar la resolución de cualquier obstáculo que frene el progreso y,
en general, ser lo suficientemente flexible para identificar y tratar cualquier problema que surgir, de cualquier forma
que se requiera. El ScrumMaster debe proteger al Equipo de las perturbaciones de otras personas actuando como
interfaz entre los dos. ScrumMaster no asigna tareas a los miembros del equipo, ya que la asignación de tareas es
una responsabilidad del equipo. El enfoque general de ScrumMaster hacia el equipo es alentar y facilitar sus
capacidades de toma de decisiones y resolución de problemas, para que puedan trabajar con una eficiencia
creciente y una necesidad menor de supervisión. El objetivo es tener un equipo que no solo esté capacitado para
tomar decisiones importantes, sino que lo haga bien y de manera rutinaria.

Descargue la hoja de referencia del rol de Scrum Master

Dueño del producto

El Product Owner es el guardián de los requisitos. El propietario del producto proporciona la "fuente única de la
verdad" para el equipo con respecto a los requisitos y su orden planificado de implementación. En la práctica, el
Product Owner es la interfaz entre la empresa, los clientes y sus necesidades relacionadas con el producto, por un
lado, y el Equipo, por el otro. El propietario del producto protege al equipo de las solicitudes de corrección de
errores y funciones que provienen de muchas fuentes, y es el único punto de contacto para todas las preguntas
sobre los requisitos del producto. El Product Owner trabaja en estrecha colaboración con el equipo para definir los
requisitos técnicos y de cara al usuario, para documentar los requisitos según sea necesario y para determinar el
orden de su implementación. El propietario del producto mantiene la lista de trabajos pendientes del producto (que
es el depósito de toda esta información), manteniéndolo actualizado y al nivel de detalle y calidad que el Equipo
requiere. El propietario del producto también establece el cronograma para entregar el trabajo terminado a los
clientes y hace la última llamada para determinar si las implementaciones tienen las características y la calidad
necesarias para el lanzamiento.
Descargue la hoja de referencia del rol del propietario del producto

Equipo

El equipo es un grupo autoorganizado y multifuncional de personas que realizan el trabajo práctico de desarrollar y
probar el producto. Dado que el equipo es responsable de producir el producto, también debe tener la autoridad
para tomar decisiones sobre cómo realizar el trabajo. Por lo tanto, el equipo se autoorganiza: los miembros del
equipo deciden cómo dividir el trabajo en tareas y cómo asignar las tareas a las personas a lo largo del Sprint. El
tamaño del equipo debe mantenerse en el rango de cinco a nueve personas, si es posible. (Un número mayor
dificulta la comunicación, mientras que un número menor conduce a una baja productividad y fragilidad). Nota: Un
término muy similar, "Equipo Scrum", se refiere al Equipo más el ScrumMaster y el Product Owner.

Descargue la hoja de referencia del equipo Scrum

¿CÓMO TE AHORRA DINERO AGILE?

¿CUÁLES SON ALGUNAS MÉTRICAS ÁGILES QUE PUEDO USAR PARA GENERAR INFORMES?

Qué medir en ágil es la pregunta permanente. Debería haber dos filtros principales que deberíamos preguntarnos
antes de medir algo; “ ¿Esta medida acelerará la entrega de valor?  , ”Y“ ¿Esta medida aumentará la confianza?  ”.

A continuación se muestra un ejemplo de una medición ágil adecuada. Por lo general, una organización creará un
objetivo para aumentar la velocidad del punto de la historia, y esto parece racional porque siempre nos esforzamos
por ofrecer más en la medida de lo posible. Esta perspectiva mira el problema desde el ángulo equivocado porque lo
que queremos es una entrega de valor, no una producción más alta. Esos no son los mismos; uno se centra en los
resultados y el otro se centra en la producción. Agile enfatiza el resultado; que es entrega de valor, no salida. Mirar a
través de la lente que equipara los aumentos de velocidad con la salida supone algunas cosas; los equipos no están
trabajando lo suficiente y ese resultado es igual al valor. De las cuales ambas suposiciones suelen ser falsas.

Deberíamos utilizar la velocidad para hacer funcionar nuestro negocio; Se puede usar una velocidad de punto de la
historia para dividir la acumulación de productos y planificar aproximadamente cuándo estarán disponibles
características específicas para nuestros clientes. Lo que tenemos que hacer es incentivar la estabilidad en la
velocidad, no la velocidad que está cambiando o en flujo. En un mundo donde hay incentivos para aumentar la
velocidad, los equipos lo obligarán y proporcionarán una mayor velocidad de puntos en la historia. Inflarán los
puntos de la historia para lograr el aumento deseado, lo que a su vez reducirá nuestra capacidad para administrar el
negocio porque la velocidad ya no es significativa.

Abordado de una manera ligeramente diferente, podríamos medir el decir / hacer del sprint. Evaluar la estimación
de un equipo de cuántos puntos de la historia entregarán en comparación con lo que realizan en un
sprint. Inmediatamente, el incentivo provoca estabilidad en la velocidad del punto de la historia, lo que brinda a la
empresa la capacidad de predecir cuándo se lanzarán las funciones al mercado.

El primero les dice a los equipos que no son de confianza y erosiona la creación de entrega de valor donde el
segundo promueve ambos. También detecta a los equipos que van bien a medida que sus estimaciones comienzan a
converger con el rendimiento, moverse para decir / hacer de cero le da a la empresa la capacidad de llevar la
velocidad al banco y generar confianza dentro de la organización. Todo el mundo gana; nuestros clientes, nuestra
organización y el equipo.

Muestra de métricas operativas

 Tiempo de espera

 Tiempo del ciclo

 Gráficos de quema
Métricas de salida de muestra

 Rendimiento

 Modelo de evaluación de la agilidad

 Calidad técnica / mediciones de defectos / cobertura de códigos

 # de funciones, etc.

Muestra de métricas de resultado / valor

 Moral del equipo

 Satisfacción del cliente / NPS

 Valor de negocio

Eche un vistazo a estos artículos para obtener más información sobre las métricas ágiles:

Métricas de personas: cómo las revisiones anuales de desempeño permiten malos comportamientos

Validación de Agile con métricas de rendimiento

¿Está haciendo un mal uso de las métricas en Agile y Scrum?

Métricas en la gestión de proyectos

¿CÓMO TRATO CON LOS EQUIPOS DISTRIBUIDOS EN AGILE?

Esta pregunta tiene dos dimensiones. Tener equipos con miembros del equipo remoto y tener todos los equipos
locales donde los equipos están intactos pero en diferentes ubicaciones geográficas. Evite el primero a toda costa.

Equipos intactos en diferentes ubicaciones geográficas

Como con todos los problemas, el contexto es una limitación principal para resolver esta situación. Las empresas que
adoptan estos atributos organizativos obtienen mejores resultados; confianza, y llevar las decisiones al lugar donde
existe la información. Las personas que realizan el trabajo tienen la información; por tanto, esta es una circunstancia
que conviene dejar que los equipos la resuelvan por sí mismos. La organización necesita confiar, financiar y apoyar
las ideas provenientes de los equipos con respecto a esta dificultad.

La organización necesita apoyar la experimentación para resolver todos los problemas porque eso elimina el fracaso
de la conversación. Los experimentos requieren un estado conocido, el estado deseado y actividades que avancen
hacia el estado deseado. Permita que los equipos experimenten, evalúen y se ajusten al nuevo aprendizaje
encontrado que resulta de esa experiencia. Luego, prepárese para apoyar un enfoque diferente y otro experimento.

Tener equipos con miembros de equipo remotos

Tener miembros de equipo distantes es una mierda para todos. La alteración de la comunicación es sustancialmente
peor, lo que provoca una falta de conciencia relacionada con los productos de construcción.

La forma más sensata de lidiar con esto es crear todos los equipos con gente local. Desafíe su pensamiento,
suposiciones y limitaciones si los equipos colocados no son posibles. Como último recurso, seguir el camino descrito
anteriormente debería sacar lo mejor de una situación terrible.

Recursos útiles:

Administrar equipos distribuidos

Scrums diarios en un mundo

distribuido Los equipos distribuidos ahora pueden construir más rápido con Bitbucket

¿QUÉ ES SAFE?
El desarrollo ágil a nivel de equipo o de pequeña organización ha surgido en los últimos 20 años como una forma
realmente poderosa de mejorar la entrega, el compromiso y la calidad. Sin embargo, el escalado ágil a
organizaciones medianas y grandes de manera exitosa y repetible ha sido un problema. Scaled Agile Framework
(SAFe) ha surgido como la solución líder a ese problema. SAFe es una colección de principios, estructuras y prácticas
que se ha demostrado que escalan de manera consistente y exitosa las prácticas ágiles y brindan los beneficios de
Agile a organizaciones que han estado trabajando en metodologías en cascada o ad-hoc. Obtenga una inmersión
profunda en SAFe tomando nuestro curso de capacitación líder en SAFe .

Recursos útiles

Diez pasos para lanzar su primer tren de lanzamiento ágil de SAFe

5 pasos para transformar su enfoque de transformación: aplicación de los principios y conceptos de SAFe a una
transformación de Scaled Agile Framework (SAFeTM)

¿CÓMO SE RELACIONA AGILE CON DEVOPS?

Si bien Agile y DevOps comenzaron como movimientos metodológicos independientes, comparten una serie de
rasgos centrados en mejorar la eficiencia y la velocidad de los equipos. A medida que las organizaciones se vuelven
más ágiles y refinan sus habilidades de gestión de proyectos, dependen cada vez más de que los equipos técnicos
puedan mantener el ritmo y mantener una cierta flexibilidad.

Aquí es donde DevOps entra en juego como el "yang" del "yin" de Agile. El enfoque DevOps ayuda a los grupos de
desarrollo a utilizar nuevas herramientas, automatización y diferentes estrategias culturales para cambiar no solo
cómo trabajan ellos mismos, sino cómo trabajan con los demás. Se convierte en una relación simbiótica en la que los
equipos de productos trabajan de la mano con los desarrolladores y probadores y similares para garantizar que
todos tengan más conciencia contextual. Esto promueve una mayor calidad general de los entregables en un período
de tiempo más corto.

Recursos útiles

Desarrollo impugnado: Encontrar el pragmatismo en Agile y DevOps

Informe sobre el estado de DevOps de 2017
Divulgando JIRA para obtener conocimientos profundos sobre las tendencias de salud de aplicaciones, bases de
datos y servidores

¿DEBERÍA USAR SCRUM, KANBAN U OTRA VERSIÓN DE AGILE?

Scrum es el sabor de ágil basado en equipo dominante que se usa en la actualidad, tiene más de veinte años y ha
sido probado en el tiempo. Dicho esto, Kanban tiene sus orígenes en la fabricación y Toyota lo aplicó en 1953, otro
enfoque de larga duración. Luego, hay varios tipos de marcos de escalamiento para considerar si el tamaño de la
organización es uno de sus contextos.

El contexto es primordial para la respuesta. ¿Qué necesidades comerciales desafían su negocio? ¿Qué tamaño tiene
su organización? ¿Cómo está organizada su empresa? ¿Están sus equipos de productos centrales dispersos en
muchas ubicaciones geográficas? Por lo tanto, los problemas comerciales reales que enfrenta su empresa y la forma
en que responde a sus clientes son contextuales a la respuesta.

Hacer la pregunta, "Scrum, Kanban u otro sabor ágil" es el primer paso y un excelente lugar para
comenzar. Considerar un cambio hacia un enfoque ágil es el primer paso hacia la sostenibilidad. Como se describió
anteriormente, ágil es un requisito para el éxito futuro, no es nuevo. Aquellas organizaciones que no adopten alguna
forma de agilidad no responderán a las necesidades de los clientes y del mercado y estarán en desventaja
significativa.

Recursos útiles:

3 diferencias entre Scrum y Kanban que necesita saber

Un vistazo al interior de Agile: Scrum y Kanban

¿Mi proyecto es adecuado para Kanban o Scrum?

¿CÓMO ESCALO LA ADOPCIÓN ÁGIL?

El escalado ágil es uno de los problemas más desafiantes de resolver porque hay muchas variantes de cómo se
estructuran las organizaciones y sus necesidades comerciales son diversas. Esta conciencia pone de relieve la noción
de contexto.

Debido a esa divergencia diversa, han surgido muchos marcos de escala, y la noción de "talla única para todos" es
una premisa falsa. Scrum es el marco de trabajo dominante del equipo; por lo tanto, la mayoría de los frameworks
de escalado tienen Scrum en su núcleo. Usar Scrum como base para resolver problemas de escalado es sólido
porque la mayoría de ellos se suman para extender como técnica. Como ejemplo, los marcos de escalado de SAFe
introducen Kanban para facilitar los desafíos de escalado mientras mantienen Scrum en su núcleo.

Los aspectos críticos a considerar al escalar más allá de la dinámica del equipo son; coordinación, comunicación,
trabajo compartido o dependiente y lejanía de grupos o miembros del equipo. Estas limitaciones son las mismas
restricciones en la implementación en equipo de Scrum; sin embargo, a medida que los equipos aumentan en
número, se amplifican y son extremadamente difíciles de resolver. A medida que una organización pasa de la
estructura de un equipo a la de varios equipos, se hacen evidentes problemas más amplios. Suelen ser la hoja de
ruta y las raciones de inversión entre iniciativas en competencia para respaldar la visión y los objetivos del negocio.

El tamaño de la organización también influye en la implementación y adopción de los esfuerzos de escalado, así
como en el marco de escalado seleccionado. Una empresa de trescientos empleados y una organización de decenas
de miles de empleados requieren enfoques diferentes. Nuevamente ilustrando el modismo de “talla única”.

Sin duda, el escalamiento organizacional de Scrum es una actividad de toda la empresa, no algo aislado de la gestión
e ingeniería de productos, como ocurre a menudo con las implementaciones de Scrum.

Obtenga más información sobre cómo escalar Agile

Recursos útiles

Requisitos Lean Agile en sistemas complejos a gran escala

Escalado ágil con Atlassian y SAFe®

¿Quiere escalar ágilmente en toda su empresa? Vea lo que dicen 5000 encuestados

Cómo llevar Agile a escala en su empresa

¿CUÁL ES EL MEJOR ENFOQUE HOLÍSTICO PARA LA ADOPCIÓN ÁGIL?

A menudo, cuando una organización adopta ágil, la atención se centra en el grupo de servicios de ingeniería con una
colaboración marginal con el departamento de gestión de productos. Este patrón es generalizado y generalmente
explica por qué las empresas no sienten que reciben los beneficios que esperan de una adopción ágil. Además la
conjetura de que ágil no funciona.

Las necesidades comerciales, el tamaño de la empresa, la estructura organizativa y una serie de otras
consideraciones crean el contexto necesario para enmarcar un enfoque de adopción ágil. Con mucho, el sistema de
éxito líder requiere la inclusión de todos los aspectos del negocio. El pensamiento sistémico, el de comprender que
todos los dominios de la empresa logran la entrega de valor, están alineados y trabajando juntos. Por lo tanto, pedir
al departamento de ingeniería con algún apoyo del departamento de gestión de productos que se convierta en ágil
no da en el blanco.

Desafortunadamente, la empresa probablemente tendrá que considerar la reestructuración y el cambio de estilos de

gestión para lograr la alineación organizacional. Los mejores resultados se obtienen cuando el equipo de liderazgo
hace todo lo posible con la mente abierta a las posibilidades cuando colabora. Colabore con un enfoque en la
entrega de valor y trabaje de una manera solidaria reconociendo que todos cambiarán de forma en apoyo de esas
posibilidades.

Algunos ejemplos son cuando el departamento de contabilidad pasa de la contabilidad de costos a la contabilidad
ajustada. El departamento de recursos humanos considera el cambio a OKR y la eliminación de MBO y KPI. Las
métricas de la empresa se centran en las mediciones que se correlacionan con la entrega de valor sobre la
producción.

El mejor enfoque al considerar una adopción ágil se relaciona con el contexto de su organización como se describe
anteriormente. Luego sea inclusivo con el equipo de liderazgo y sus áreas de enfoque con miras a la entrega de valor
acelerada sobre la producción y la utilización.

¿CÓMO AMPLIFICO EL IMPACTO DE AGILE?

Desarrollando una organización de aprendizaje con el beneficio de un propósito claro y proporcionando un entorno
en el que se confía en las personas.

Organización que aprende

¿Qué significa o implica ser una organización que aprende? Los principios fundamentales de Scrum son inspección,
adaptación y transparencia. Están integrados en los principios de Scrum y están presentes en cada evento como
circuitos de retroalimentación. Tenían la intención de tener tantas oportunidades de aprendizaje como fuera posible
y experimentar con la mayor frecuencia posible.

Necesitamos involucrar a toda la empresa en estos principios porque los mayores beneficios de la agilidad dependen
del pensamiento sistémico. El pensamiento sistémico junto con el enfoque en la entrega de valor. Deseamos que las
mediciones que influyen en los servicios de ingeniería sean coherentes con lo que impulsa el negocio.

Propósito claro
La organización necesita proporcionar un propósito que sea más grande que los individuos dentro de la organización,
un objetivo que sea más grande que la propia organización. Debe llegar al nivel emocional de todos, y debería ser la
razón de inspiración por la que la gente quiere venir a trabajar.

Entorno de confianza
El objetivo es que todos puedan experimentar y aprender. La experimentación es diferente a simplemente fallar en
algo. Si construimos un experimento, se deben definir algunas cosas. Un estado actual, el estado deseado y el
experimento en sí que avanza hacia el estado deseado.

Dado ese conjunto de restricciones, el experimento produce un resultado respaldado o una hipótesis nula. Y ambos
son puntos de datos importantes que deberían influir en nuestro comportamiento futuro.

En conclusión, lo ágil es un deporte de toda la empresa y no una mera actividad de servicios de ingeniería. Sin los
tres; organización de aprendizaje, propósito claro y entorno de confianza, los efectos de la agilidad se verán
disminuidos.

¿CÓMO HAN ADOPTADO OTRAS ORGANIZACIONES AGILE CON ÉXITO?

El contexto es esencial, el marco para un cambio tan dramático como alterar la forma en que opera una empresa
requiere guiar al personal a través del viaje en lugar de arrastrarlo. Algunas áreas críticas para el éxito son reconocer
que el cambio es difícil y reconocer que este esfuerzo es un esfuerzo humano.

Adoptar los valores de Scrum de compromiso, coraje, enfoque, apertura y respeto. Y expresarlos de manera que la
empresa los adopte por completo, de modo que se conviertan en valores compartidos organizacionalmente
promoverá el éxito.

Un enfoque dinámico para la búsqueda de voluntarios hará surgir al personal que busca un cambio positivo y filtrará
a los que se oponen al cambio. Esta estrategia eliminará los bloqueadores organizacionales de la transición porque
no son parte del progreso hacia el nuevo método operativo. A medida que avanza el tiempo, el cambio comienza a
tener resultados visibles; personal más feliz, la innovación se vuelve más pronunciada y la entrega de valor se
acelera. De repente, se produce un impulso a medida que el personal, los equipos, los departamentos y las unidades
de negocio se sienten atraídos hacia el nuevo modelo operativo ágil.

El tema de escalar ágil es monolítico, por lo tanto, comenzar en el equipo o en algunos equipos es el comienzo del
viaje que se requiere. Tenga cuidado con la aplicación de marcos de escalado en el primer día, por lo general, los
resultados no son tan beneficiosos a largo plazo.

UN VISTAZO AL INTERIOR DE AGILE: SCRUM Y KANBAN

Cómo incorporar Scrum y Kanban en su estrategia general

¿Qué has oído sobre Agile? ¿Está tratando de decidir si Scrum o Kanban es un mejor enfoque para su equipo en
particular? ¿Se pregunta si las funciones fuera del desarrollo de aplicaciones, como marketing, diseño de experiencia
de usuario, infraestructura, se benefician de las técnicas ágiles? ¿Quieres conocer algunos conceptos básicos, pero
poderosos, para acercarte a tu ciclo de lanzamiento? ¿Tiene dependencias complejas o encaja en un entorno de
PMO no ágil pero quiere ser ágil?

Si respondió afirmativamente a alguna de estas preguntas, únase a nosotros en un seminario web en el que se
explican estos conceptos clave:

 Agile no es solo un marco para el desarrollo de software, es una forma de pensar que puede abarcar el
negocio

 Agile ofrece una medida de progreso más clara que los informes de estado o planes de proyecto
tradicionales.

 Lo ágil se puede realizar dentro de procesos PMO estructurados y bien definidos

 Agile mejora la capacidad de gestionar las expectativas de los clientes y las partes interesadas

También discutiremos algunas similitudes y diferencias de alto nivel entre Scrum y Kanban junto con
recomendaciones para incorporar ambos en su estrategia general, incluso cuando su empresa en general necesita
continuar con algunos proyectos utilizando un enfoque tradicional basado en planes.

Metodología ágil: una descripción general

El arte del desarrollo de software iterativo e incremental

 15

Quienes trabajan en la industria, o muy cerca de ella, son conscientes de que el arte del desarrollo de software es
especial y diferente a otros tipos de proyectos de ingeniería. Requiere el cuidado y la atención de un equipo que sea
adaptable y flexible, y de aquellos que estén dispuestos a responder rápidamente a los cambios y no se inmuten
ante las demandas de un cliente durante la noche. De esto se trata la metodología Agile. 

Según el informe State of Agile de Verison One en 2020 , Agile llegó para quedarse. Los principios y prácticas de la
metodología Agile se han escalado entre equipos y a nivel mundial. Las conclusiones clave del informe son:

 "El 95% de los encuestados informa que sus organizaciones practican métodos de desarrollo ágiles".

 "El 81% de los encuestados dijo que su organización tiene equipos ágiles donde los miembros del mismo
equipo no trabajan todos en la misma ubicación (es decir, no comparten la ubicación)".

 "El 71% de los encuestados dijo que su organización practica Agile con varios equipos coubicados que
colaboran a través de fronteras geográficas".
Definición de metodología ágil:

La metodología ágil es un tipo de proceso de gestión de proyectos, utilizado principalmente para el desarrollo de
software, donde las demandas y soluciones evolucionan a través del esfuerzo colaborativo de equipos
autoorganizados y multifuncionales y sus clientes.

La metodología Agile es una colección de principios que valoran la adaptabilidad y la flexibilidad. Agile  tiene como
objetivo proporcionar una mejor capacidad de respuesta a las necesidades comerciales cambiantes y, por lo tanto,
se centra en permitir que los equipos cumplan con incrementos viables .

Partiendo de los valores y principios del Manifiesto Ágil, se creó como respuesta a las deficiencias de los métodos de
desarrollo tradicionales, como el método Waterfall . La industria del software es un mercado altamente competitivo
debido a que el software es algo que se puede actualizar continuamente. Esto significa que los desarrolladores
necesitan mejorar e innovar constantemente sus productos para mantenerse en la cima del juego, y el enfoque
lineal y secuencial del método Waterfall simplemente no fue suficiente.

Una breve historia del desarrollo de software ágil

En la década de 1990, el desarrollo de software se enfrentó a una pequeña crisis . Conocida como 'la crisis del
desarrollo de aplicaciones' o 'retraso en la entrega de aplicaciones', la industria se dio cuenta de que no podía
moverse lo suficientemente rápido para satisfacer las demandas y requisitos de los clientes; el tiempo estimado
entre una necesidad comercial y la aplicación real era de unos tres años. Vea, los modelos de desarrollo tradicionales
se basaron en un enfoque de línea de tiempo, donde el desarrollo sucedió secuencialmente y el producto final no se
reveló a los clientes hasta el último paso. Esto dejaba poco margen para la flexibilidad en lo que respecta a las
revisiones y los cambios de progreso. Entonces, cuando se terminó una aplicación real, era muy probable que los
requisitos y sistemas de los objetivos originales del proyecto hubieran cambiado.

Con el tiempo, el dinero y los esfuerzos desperdiciados, e incluso algunos proyectos cancelados a la mitad, los líderes
profesionales de la comunidad del software pensaron que era hora de un enfoque nuevo y renovado. Luego, en
2001, en un albergue de esquí nevado en Utah, un grupo de profesionales de la industria se reunió para discutir las
prácticas de la industria. Aunque la reunión se organizó con un enfoque principal en la discusión de los ciclos de
desarrollo, algunos participantes ya estaban considerando la idea de un nuevo método de desarrollo de
software. Todos anhelaban cimentar un proceso que legitimara lo que se estaba practicando, y así surgió la creación
del Manifiesto Ágil.

¿Qué es el Manifiesto Ágil?

El Manifiesto Agile es una declaración de los valores y principios expresados en la metodología Agile. Compuesto por
cuatro valores fundamentales y 12 principios clave, su objetivo es ayudar a descubrir mejores formas de desarrollar
software al proporcionar una estructura clara y medible que promueva el desarrollo iterativo, la colaboración en
equipo y el reconocimiento de cambios.

Los valores y principios del ' Manifiesto para el desarrollo de software ágil ' son:

Valores:

1.

1. Individuos e interacciones sobre procesos y herramientas

2. Software de trabajo sobre documentación completa

3. Colaboración con el cliente sobre la negociación del contrato

4. Responde al cambio sobre el siguiente plan

Principios:

1.

1. Satisfacción del cliente a través de la entrega de software temprana y continua 

2. Adapte los requisitos cambiantes a lo largo del proceso de desarrollo

3. Entrega frecuente de software de trabajo

4. Colaboración entre las partes interesadas del negocio y los desarrolladores durante todo el
proyecto.

5. Apoyar, confiar y motivar a las personas involucradas

6. Habilite las interacciones cara a cara

7. El software que funciona es la principal medida de progreso

8. Procesos ágiles para respaldar un ritmo de desarrollo constante

9. La atención a los detalles técnicos y al diseño mejora la agilidad

10. Sencillez

11. Los equipos autoorganizados fomentan grandes arquitecturas, requisitos y diseños.

12. Reflexiones periódicas sobre cómo ser más eficaz.

Quienes aplican cualquier tipo de metodología Agile se adhieren a estos valores y principios. El manifiesto ofrece una
buena descripción general de lo que se espera cuando se trata de las prácticas del ciclo de vida del desarrollo ágil.

¿Qué es la gestión ágil de proyectos?

La gestión ágil de proyectos es una metodología que se utiliza comúnmente para entregar proyectos complejos
debido a su capacidad de adaptación. Enfatiza la colaboración, la flexibilidad, la mejora continua y los resultados de
alta calidad. Su objetivo es ser claro y medible mediante el uso de seis entregables principales para realizar un
seguimiento del progreso y crear el producto. 

Los entregables:

1.

1. Declaración de la visión del producto: un resumen que articula los objetivos del producto.

2. Hoja de ruta del producto: la visión de alto nivel de los requisitos necesarios para lograr la visión del
producto.
 3. Pila de productos: ordenada por prioridad, esta es la lista completa de lo que se necesita para su
proyecto.

4. Plan de lanzamiento: un calendario para el lanzamiento de un producto funcional.

5. Backlog de Sprint: las historias de usuario (requisitos), los objetivos y las tareas vinculadas al Sprint
actual.

6. Incremento: la funcionalidad del producto de trabajo que se presenta a las partes interesadas al
final del sprint y que potencialmente podría entregarse al cliente.

Hay varios marcos dentro de la gestión de proyectos ágiles que se pueden utilizar para desarrollar y entregar un
producto o servicio. Cada marco destaca un enfoque específico y se centra en un resultado
determinado. Dependiendo del resultado solicitado, se elige y aplica el enfoque particular de Agile. Si bien cada uno
tiene su propio conjunto de características y terminología, comparten principios y prácticas comunes. 

Dos de los más populares que apoyan el ciclo de vida del desarrollo ágil son Scrum y Kanban.

Metodología Agile Scrum

Scrum es un marco ágil que se utiliza para implementar las ideas detrás del desarrollo de software ágil. Es el marco
ágil más popular utilizado en las empresas .  Creado por Jeff Sutherland y Ken Schwaber (quienes también formaron
parte de las 13 personas que cimentaron el Manifiesto Ágil), comprende cinco valores : compromiso, coraje,
concentración, apertura y respeto. Su objetivo es desarrollar, entregar y mantener productos complejos a través de
la colaboración, la responsabilidad y el progreso iterativo.

Lo que distingue a Scrum de otras metodologías ágiles son los roles, eventos y artefactos que lo componen, con los
que opera. Esto es lo que son:

Roles del equipo Scrum

 Dueño del producto : experto en el producto que representa a las partes interesadas y es la voz del cliente.

 Equipo de desarrollo : Grupo de profesionales que entregan el producto (desarrolladores, programadores,

diseñadores). 

 Scrum master : líder de servicio organizado que asegura que se siga la comprensión y ejecución de Scrum. 

Eventos de Scrum

 Sprint : Horarios iterativos en los que se logra un objetivo. El marco de tiempo no excede un mes calendario
y es consistente durante todo el proceso de desarrollo.

 Planificación de Sprint : donde todo el equipo Scrum se reúne, al comienzo de cada Sprint, para planificar el
próximo Sprint.

 Scrum diario : reunión en caja de 15 minutos que se realiza a la misma hora, todos los días del Sprint, donde
se discuten los logros del día anterior, así como las expectativas para el siguiente.
  Revisión del Sprint : una reunión informal que se lleva a cabo al final de cada Sprint donde el equipo Scrum
presenta su Incremento a las partes interesadas y discute la retroalimentación.

 Retrospectiva de Sprint : una reunión donde el equipo Scrum reflexiona sobre los procedimientos del Sprint
anterior y establece mejoras para el siguiente Sprint.

Artefactos Scrum

 Pila de productos : administrada por el propietario del producto, es donde se enumeran todos los requisitos
necesarios para un producto viable en orden de prioridad. Incluye características, funciones, requisitos,
mejoras y correcciones que autorizan cualquier cambio que se realice en el producto en versiones futuras.

 Backlog de Sprint : una lista de las tareas y requisitos que deben cumplirse durante el próximo Sprint. A
veces, se acompaña de un tablero de tareas Scrum, que se utiliza para visualizar el progreso de las tareas en
el Sprint actual y cualquier cambio que se realice en un formato de 'Tareas pendientes, pendientes y
finalizadas'.

Kanban

Kanban es un método muy visual que se utiliza popularmente en la gestión de proyectos ágiles. Pinta una imagen del
proceso de flujo de trabajo, con el objetivo de identificar cualquier cuello de botella al principio del proceso, de
modo que se entregue un producto o servicio de mayor calidad.

Sus seis prácticas generales son:

1.

1. Visualización

2. Limitar el trabajo en curso

3. Gestión de flujo

4. Haciendo explícitas las políticas

5. Usar bucles de retroalimentación

6. Evolución colaborativa o experimental

Kanban, un concepto que se desarrolló en la línea de producción de las fábricas de Toyota en la década de 1940,
logra eficiencia a través de señales visuales para señalar ciertas etapas del proceso de desarrollo. Las señales
mencionadas son un tablero Kanban, tarjetas Kanban y, a veces, incluso carriles Kanban .

 Tablero Kanban : una herramienta de gestión visual que se utiliza para visualizar el proceso de
desarrollo. Puede ser físico (una pizarra, notas adhesivas y marcadores) o virtual (como la herramienta
de gestión de proyectos en línea de Zenkit ) y se puede utilizar para la productividad personal , así como para
uso profesional.

 Tarjetas Kanban : Tarjetas que representan un elemento / tarea de trabajo en el proceso de trabajo. Usado
para comunicar el progreso a su equipo, representa información como el estado, el tiempo del ciclo y los
plazos inminentes.

 Carriles Kanban : un elemento visual en el tablero que le permite distinguir aún más las tareas / elementos
al categorizarlos. Fluyendo horizontalmente, ofrece distinción y proporciona una mejor visión general del
flujo de trabajo.

Otros enfoques del ciclo de vida del desarrollo ágil

Programación extrema (XP)

Basado en los cinco valores de comunicación, simplicidad, retroalimentación, coraje y respeto, XP es un marco que
tiene como objetivo producir una mayor calidad de vida para el equipo de desarrollo, así como un producto de
mayor calidad, a través de una colección de prácticas de ingeniería. Estas prácticas son:

 El juego de la planificación  Programación en pareja

 Pequeños lanzamientos  Propiedad colectiva

 Metáfora  Integración continua

 Diseño simple  Semana de 40 horas

 Pruebas  Cliente in situ

 Refactorización  Estándar de codificación

Cristal

Crystal comprende una familia de metodologías ágiles que incluyen Crystal Clear, Crystal Yellow y Crystal Orange. Sus
características únicas están guiadas por factores como el tamaño del equipo, la importancia del sistema y las
prioridades del proyecto. Los componentes clave incluyen el trabajo en equipo, la comunicación y la sencillez, así
como la reflexión para ajustar y mejorar periódicamente el proceso de desarrollo. Este marco Agile señala cómo
cada proyecto puede requerir un conjunto personalizado de políticas, prácticas y procesos para cumplir con las
características específicas del proyecto.

Método de desarrollo de sistemas dinámicos (DSDM)

DSDM es una metodología ágil que se centra en el ciclo de vida completo del proyecto. Fue creado en 1994 después
de que los usuarios de Rapid Application Development (RAD) quisieran más gobernanza y disciplina para esta forma
iterativa de trabajo. Basada en ocho principios , su filosofía es "que cualquier proyecto debe estar alineado con
objetivos estratégicos claramente definidos y centrarse en la entrega temprana de beneficios reales para el
negocio". 

Promueve el uso de las siguientes prácticas para que pueda ofrecer una guía de mejores prácticas para la entrega a
tiempo y dentro del presupuesto de proyectos:

 Talleres facilitados

 Modelado y desarrollo iterativo

 Priorización de MoSCoW

 Boxeo de tiempo

DSDM está diseñado para ser independiente y puede implementarse junto con otras metodologías iterativas.

Desarrollo basado en funciones (FDD)

FDD es un proceso de desarrollo de software ligero, iterativo e incremental. Con el objetivo de entregar software
tangible y funcional de manera oportuna, es una metodología ágil que implica fases de trabajo específicas y muy
cortas, que deben realizarse por separado por función. Su proceso de desarrollo se basa en un conjunto de mejores
prácticas con un objetivo de valor para el cliente. Las ocho mejores prácticas son:

1.

1. Modelado de objetos de dominio

2. Desarrollando por característica

3. Propiedad del componente / clase

 4. Equipos de funciones

5. Inspecciones

6. Gestión de la configuración

7. Construcciones regulares

8. Visibilidad de avances y resultados

Mejores prácticas de metodología ágil

Siempre es útil saber cómo hacer las cosas mejor. Aquí hay siete cosas que usted y su equipo deben hacer al
implementar cualquier tipo de metodología ágil:

Colaboración con el cliente

Uno de los valores fundamentales establecidos en el Manifiesto Agile, la colaboración con el cliente es una parte
vital de la metodología Agile. A través de una comunicación constante con el equipo de desarrollo, el cliente siempre
debe estar al tanto del progreso, y el esfuerzo combinado dará como resultado un producto de mayor calidad.

Historias de usuarios

Una herramienta utilizada para explicar una función de software desde la perspectiva del usuario final, el propósito
de una historia de usuario es crear una descripción simplificada de un requisito. Ayuda a imaginar el tipo de usuario
del producto, lo que quieren y las razones para ello. Un formato de historia de usuario común que se utiliza es:

Como [función], quiero [función], porque [razón].

Integración continua

La Integración Continua (CI) implica mantener el código actualizado al producir una compilación limpia del sistema
varias veces al día. Con una regla que establece que los programadores nunca dejan nada sin integrar al final del día,
permite la entrega de una versión del producto adecuada para su lanzamiento en cualquier momento. Lo que CI
busca hacer es minimizar el tiempo y el esfuerzo que requiere cada integración.

Pruebas automatizadas

La realización de pruebas automatizadas mantiene al equipo informado sobre cuáles cambios de código son
aceptables y si una funcionalidad está funcionando según lo planeado. Las pruebas de regresión se ejecutan
automáticamente antes de que comience el trabajo.

Programación en pareja

La programación en pares tiene como objetivo mejorar mejores diseños, menos errores y compartir conocimientos
entre el equipo de desarrollo. Una de las prácticas de programador ágiles menos aceptadas, involucra a un
programador 'conduciendo' (operando el teclado), mientras que el otro 'navega' (observa, aprende, proporciona
retroalimentación). Los roles se pueden rotar.

Desarrollo impulsado por pruebas (TDD)

TDD tiene como objetivo fomentar diseños simples e inspirar confianza. En lugar de un proceso en el que se agrega
software que no se ha demostrado que cumpla con los requisitos, es un método basado en la repetición de un ciclo
de desarrollo muy corto donde los requisitos se convierten en casos de prueba, y luego se mejora el software para
pasar las nuevas pruebas.

Gráficos de evolución
Un gráfico de evolución es una representación gráfica del trabajo que queda por hacer frente al tiempo que tiene
para hacerlo. El uso de uno como parte de su plan de gestión de proyectos Agile le permite pronosticar cuándo se
completará todo el trabajo. Un gráfico de evolución detallado también incluirá la cantidad de Historias de usuario
por unidad de tiempo.

La metodología ágil es un proceso eficaz para los equipos que buscan un enfoque flexible para el desarrollo de
productos. Ya no es exclusivo de la industria del software, se puede implementar en cualquier empresa comercial
que requiera un plan de ataque no lineal que también deba valorar la colaboración del cliente, el trabajo en equipo
eficaz , los cambios receptivos y, por supuesto, los resultados de calidad.

Los 12 principios ágiles: ¿qué son y siguen siendo importantes?

Tiempo de lectura 11 minutos

En 2001, apareció el Manifiesto Ágil . Quería cambiar el proceso de desarrollo de software. El manifiesto tiene cuatro
temas centrales, pero no mucha gente sabe que también hay 12 principios ágiles . Estos ofrecen ejemplos más
concretos de cómo debería llevarse a cabo el desarrollo de software ágil. Muchos años después, casi todas las
organizaciones  dirán que "son ágiles", pero muchas solo expresan los valores y principios del Manifiesto Ágil. El
mundo del desarrollo de software también ha cambiado drásticamente. Es interesante revisar los principios ágiles,
ver lo que significan y evaluar si todavía son importantes.

Entrega temprana y continua de software valioso

Como dice el primer principio, "Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y
continua de software valioso".

Por lo general, desarrollamos software con el tiempo y el dinero de otra persona para ayudarla de alguna manera. Si
esperamos demasiado para entregar el producto, probablemente no satisfará al cliente. Esto es incluso más cierto
ahora que en 2001. No solo es valioso tener comentarios tempranos y tenerlos continuamente durante todo el
proyecto, los clientes esperan una entrega rápida. Y cada entrega debe agregar algo de valor para el cliente. Por
ejemplo, al cliente no le importa que haya refactorizado la página de inicio de sesión. A ella  le importa que ahora le
permita iniciar sesión con su cuenta de Google.

Supere la brecha entre DevOps y Agile con Plutora

La gestión de las dependencias entre las metodologías Agile, DevOps y Waterfall puede ser una lucha. Plutora
proporciona un entorno colaborativo donde los equipos pueden moverse rápidamente.

APRENDE MÁS

Los usuarios utilizan cada vez más software para todo tipo de tareas. Y están acostumbrados a actualizaciones
frecuentes. Entonces, cuando nos pidan cambios, no estarán dispuestos a esperar meses antes de verlos.

Aceptar el cambio

El segundo principio establece: “Bienvenidos requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles
aprovechan el cambio para la ventaja competitiva del cliente ”.

En un mundo que cambia constantemente a un ritmo rápido, nadie puede predecir realmente cuáles serán los
requisitos de una pieza de software. Sin embargo, a las empresas no les gustan las sorpresas. Pero lo que les gusta
aún menos es gastar dinero en un producto que ya no es relevante. Si aceptamos el cambio, el software podría
proporcionar al cliente una ventaja competitiva porque satisface las necesidades actuales y más recientes, no las del
año pasado.
El hecho de que el mundo cambia constantemente ha sido cierto durante décadas. La sociedad cambia, el mercado
cambia, nuestras organizaciones cambian y la gente cambia. En lugar de intentar detener o ralentizar este proceso,
debemos aceptarlo y utilizarlo en beneficio nuestro o de nuestro cliente.

Entrega frecuente

El siguiente principio es "Entregar software que funcione con frecuencia, desde un par de semanas hasta un par de
meses, con preferencia a la escala de tiempo más corta".

Este principio en realidad parece una repetición del primero y, en cierto modo, lo es. Sin embargo, el primer
principio señala que debemos comenzar a entregar software valioso lo  antes posible . Este principio detalla un poco
más lo que significa entregar de forma  continua . Recomienda entregar una nueva versión de su software en un
corto período de tiempo. Esto significa versiones más pequeñas, y versiones más pequeñas significan menos
posibilidades de que se produzcan errores. Los lanzamientos más frecuentes también brindan más momentos de
retroalimentación por parte del cliente. Si solo recibe comentarios sobre todos sus cambios después de varios
meses, tendrá mucho más trabajo que pueda acomodar cualquier comentario.

Este es un principio que se ha vuelto más radical con los años. Ya no consideramos un ciclo de lanzamiento de "un
par de meses" como ágil. La industria ha evolucionado a lanzamientos diarios o semanales.

Empresas y desarrolladores juntos

Otro principio establece: "Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el
proyecto".

Los desarrolladores a menudo están protegidos de la gente de negocios. Los analistas se ponen entre ellos para
"traducir" el lenguaje comercial a un lenguaje que los desarrolladores puedan entender. Este principio ágil insta a las
organizaciones a eliminar estas barreras y permitir que los desarrolladores y la empresa interactúen entre sí a
diario. Esto aumenta la comprensión y el respeto mutuos.

Si alguna vez jugó al juego del teléfono  cuando era niño, sabe que cada paso adicional en la comunicación conduce a
la pérdida de información. Hacer que la empresa y los desarrolladores trabajen en estrecha colaboración reduce
(pero no elimina) este riesgo. Incluso en el mundo moderno de los equipos distribuidos, deberíamos intentar
trabajar juntos en estrecha colaboración a diario. Detectar los malentendidos temprano y obtener retroalimentación
mutua ayuda a producir resultados exitosos.

Individuos motivados

También hay “Construya proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y
confíe en ellos para hacer el trabajo ".

Un equipo ágil es un equipo lo suficientemente maduro y responsable como para producir software de calidad. Esto
requiere cierta confianza. Pero si no puede confiar en sus desarrolladores, ¿por qué los contrataron? Con el
entrenamiento, el entorno y las herramientas correctos, los desarrolladores motivados se sentirán capacitados para
hacer su trabajo de manera profesional.

Si construye sus proyectos en torno a personas que no están motivadas o que se han desmotivado debido a la falta
de confianza o apoyo, es probable que su proyecto no tenga éxito. Peor aún, los desarrolladores inteligentes no
tendrán problemas para encontrar mejores trabajos.

Conversación cara a cara

Y también existe el principio que establece: "El método de información más eficiente y eficaz hacia y dentro de un
desarrollo es la conversación cara a cara".

La tecnología ha aumentado la cantidad de formas en que los humanos pueden comunicarse. Pero ninguno de estos
es tan bueno como una charla cara a cara. Nuestro cerebro interpreta todo tipo de señales, no solo las ondas
sonoras de nuestras voces. La expresión facial y el lenguaje corporal también importan. No es raro que la
comunicación asincrónica provoque malentendidos.
El siguiente diagrama, del libro de Alistair Cockburn "Agile Software Development", nos muestra cuán efectivas son
las diferentes formas de comunicación:

Desde 2001, la forma en que trabajamos ha cambiado drásticamente. Muchas organizaciones tienen personas que
trabajan de forma remota, incluso en otras zonas horarias. Tecnologías como los rastreadores de problemas y Slack
crean formas de comunicación asincrónica y herramientas como Skype y Hangouts nos permiten tener
conversaciones remotas cara a cara. Nunca será 100% como una interacción en la vida real, pero tal vez sea  lo
suficientemente bueno.   Los equipos de todo el mundo están demostrando que aún pueden tener éxito y ser ágiles
sin verse en la vida real.

Software de trabajo

Uno de los principios dice: "El software funcional es la principal medida de progreso".

Los proyectos de software pueden llevar mucho tiempo. Por tanto, es absolutamente racional que las empresas
midan el progreso. Este principio ágil establece que la forma principal de medir el progreso es el software de
trabajo. Los análisis terminados, los modelos completos o las hermosas maquetas tienen poco significado si no se
convierten en un software que funcione. Pueden ser necesarios, pero si no ha puesto al menos una pequeña parte
de eso en un producto funcional, entonces no ha creado valor para su cliente.

Hoy, a menudo damos un paso más. Si el software en funcionamiento no se ha enviado, no está terminado y, por lo
tanto, no se ha realizado ningún progreso. El software inédito es inventario. Y el inventario es un costo, no una parte
de los ingresos o el valor.

Desarrollo sostenible

El octavo principio es el siguiente: “Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deberían poder mantener un ritmo constante de forma indefinida ".

¿Entonces, qué significa eso exactamente? Para mí, significa que las personas deben trabajar en un entorno en el
que experimenten presiones que puedan manejar para siempre. La presión se presenta en diferentes formas y
formas. Piense en cosas como el presupuesto, los plazos, la política de la empresa y el respeto entre colegas. 

Cada una de estas cosas puede ser una fuente de estrés y hacer que las personas se alejen, o pueden ser cosas que
están presentes pero que no son motivo de preocupación.

Aquí está la cosa. No significa que una organización ágil no pueda tener ninguno de estos problemas. Significa que no
pueden estar sucediendo todo el tiempo. Por ejemplo, un equipo ágil puede manejar un período intenso de trabajo
de alto ritmo. Pero deberían tener un período de descanso después de eso. Si la organización siempre está
estresando al equipo al límite, no es sostenible; el equipo no puede mantener ese ritmo para siempre.
Observe cómo el principio menciona "patrocinadores, desarrolladores y usuarios". Por tanto, todo el mundo debería
poder mantener el ritmo actual de desarrollo. Por ejemplo, si los desarrolladores están creando funciones
demasiado rápido para los usuarios, entonces los desarrolladores deberían adaptarse. Una forma de hacerlo sería
reducir la velocidad. Otra sería invertir más tiempo en documentación y educar a los usuarios sobre las nuevas
funciones.

La idea central de este principio es que todos los involucrados pueden seguir el ritmo al que se desarrolla el
software.

Excelencia técnica

Hay otro dicho: "La atención continua a la excelencia técnica y el buen diseño mejora la agilidad".

Muchas empresas prefieren el tiempo de comercialización al buen diseño técnico. Y para ser justos, no se les puede
culpar. Acabamos de mencionar que el software inédito tiene un costo. Al usuario final no le importa la excelencia
técnica y no genera ingresos para el negocio.

Pero si los equipos descuidan un buen diseño técnico durante demasiado tiempo, su velocidad y tiempo de
comercialización comenzarán a disminuir. Su capacidad para cambiar el producto como reacción a un mercado
cambiante disminuirá. Están perdiendo su agilidad.

Este principio sigue siendo muy relevante. En mi experiencia, tanto los gerentes como los desarrolladores no son
conscientes (lo suficiente) de este principio. En proyectos pequeños, puede tener sentido trabajar rápido sin un buen
diseño. Pero si el proyecto es lo suficientemente grande, vale la pena prestar atención a la calidad técnica. Martin
Fowler creó un pseudo-gráfico para visualizar esto:

Esto no significa que necesitemos grandes diseños teóricos antes de comenzar a codificar. Pueden surgir buenos
diseños a medida que evoluciona el software. Pero los desarrolladores necesitan tener el tiempo y ser lo
suficientemente responsables para hacerlo.

Sencillez

“La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial”, es otro principio.

Maximizar la cantidad de trabajo no realizado se puede hacer en varios lugares: puede eliminar procedimientos que
ya no son relevantes, automatizar el trabajo manual, usar bibliotecas existentes en lugar de escribir las suyas
propias, etc. Todo ahorra tiempo y dinero, dándonos espacio para céntrese en ofrecer más valor.

Este es un esfuerzo continuo para todas las organizaciones. Pero requiere algo de trabajo identificar dónde y cómo
podemos mejorar.

Equipos autoorganizados
Uno de los últimos principios es que "las mejores arquitecturas, requisitos y diseños surgen de equipos
autoorganizados".

Este principio es una combinación de algunos principios anteriores. Si queremos que la empresa y los
desarrolladores se comuniquen entre sí con regularidad y eficacia, si queremos medir el progreso mediante software
que funcione y no modelos teóricos, y si trabajamos con personas motivadas, entonces deberíamos tener equipos
que produzcan software de calidad sin demasiado control. desde arriba.

Los equipos deben aprender a autoorganizar todos los aspectos del desarrollo de software: deben reunir los
requisitos comunicándose con la empresa, escribir software de calidad, organizar su trabajo, etc. Esto conduce a un
mejor software porque los desarrolladores comenzarán a "poseer" el software.

Los desarrolladores todavía se consideran trabajadores de la línea de fábrica que pueden satisfacer los
requisitos. Pero el desarrollo de software es un trabajo que requiere mucho más. El equipo debe poder organizarse
para cumplir.

La otra cara de la historia es que los desarrolladores de software ágiles deberían asumir esta responsabilidad. Un
equipo ágil requiere que los desarrolladores asuman responsabilidades más allá de simplemente escribir código.

Reflexión y ajuste regulares

Por último, está el último principio que dice: "A intervalos regulares, el equipo reflexiona sobre cómo ser más eficaz,
luego sintoniza y ajusta su comportamiento en consecuencia".

A intervalos regulares, los equipos autoorganizados deben tomarse el tiempo para observar la forma en que trabajan
y adaptarse en consecuencia. Ningún equipo corre a la perfección. Un equipo ágil maduro puede identificar
problemas con respeto mutuo y luego tomar medidas para mejorar el proceso.

Este principio siempre importará. Es lo que hace que las personas, los equipos y el negocio sean exitosos al no
aceptar el status quo pero siempre buscando mejorar la situación.

Todos siguen importando

Puede notar que todos los principios ágiles siguen siendo relevantes hoy. Eso es porque se basan en la realidad
económica y la naturaleza humana, dos cosas que realmente no cambian tanto. En todo caso, algunos principios se
han vuelto más radicales de lo que se pretendía. Por ejemplo, deberíamos desplegarnos semanalmente o incluso
diariamente y ahora podemos automatizar más de lo que imaginamos en 2001. Por otro lado, a algunos principios se
les ha dado un significado diferente al que imaginamos en 2001: los individuos ya no necesitan estar en el mismo
espacio para una comunicación eficaz, por ejemplo.
Definición y características del Scrum Master
Los modelos de gestión como Lean o Kanban ayudan a las empresas a agilizar sus proyectos y a desarrollarlos de
forma eficaz. Asimismo, existen perfiles profesionales que se dedican a agilizar los procesos de trabajo, como puede
ser el Agile Coach o el Scrum Master, que facilita la resolución de tareas.

El Scrum Master: definición y características

El Scrum Master (SM) o facilitador de proyectos, es la figura que lidera los equipos en la gestión ágil de proyectos. Su
misión es que los equipos de trabajo alcancen sus objetivos hasta llegar a la fase de «sprint final», eliminando
cualquier dificultad que puedan encontrar en el camino.

En otras palabras, el Scrum Master es el responsable de que se sigan las prácticas y valores descritos en el modelo
Scrum. Se puede comparar el papel del Scrum Master al de un coach/mentor que acompañará al equipo hacía el
éxito del proyecto

Como facilitador de proyectos, es el encargado de sacar adelante todos aquellos proyectos que utilicen una
metodología Scrum:  desde la elaboración del Product Backlog (el archivo que recoge las tareas y funciones a
desarrollar), y Sprint Bakclog (documento que muestra la división de tareas entre los miembros del equipo),
el Sprint (en donde se realizan todas las acciones y se testea si las acciones realizadas funcionan) hasta el Burn Down
(el análisis y control de las tareas realizadas y todo lo que queda pendiente).

uchos Scrum Master han desempeñado con anterioridad el papel de Project Managers, por lo que no solo facilitan
las tareas al resto del equipo sino que en muchas ocasiones también ayuda a encontrar soluciones a los problemas.
Si también te interesa esta profesión te recomendamos el Master in Digital Project Management.

¿Cuáles son las principales características de un Scrum Master?

 Asesora y refuerza a los miembros del equipo para que puedan trabajar de forma autoorganizada y con
espíritu y conciencia de equipo. Para ello, se encarga de gestionar “dinámicas de grupo” que contribuyan al
desarrollo de los objetivos marcados.

 Elimina cualquier impedimento con el que se encuentre el equipo para conseguir sus objetivos finales.

 Si los desarrolladores no saben cómo abordar las tareas, el Scrum Master los juntará a todos para explicarles
en qué consisten y qué tarea abordará cada uno.

 Facilita la fase de sprint final al equipo. Cuando los miembros del equipo están presentando a
los stakeholders (perfiles interesados en los productos) el proyecto, evita que no se atasquen en el sprint
final, actuando como guía y moderador de las presentaciones en muchos casos.

 Ayuda a llevar a cabo los  daily standups, esto es, proporcionar todas las actualizaciones que el equipo
necesita para el desarrollo de los proyectos.

 A veces puede realizar las tareas de un agile coach. Es decir, se asegura de que todos los miembros del
equipo aprendan y utilicen la metodología adecuada.

 Trabaja codo con codo con el Product Owner (el representante de los clientes) y que desde un primer
momento define los objetivos del proyecto, detecta riesgos que pueda haber durante la fase de sprint y
busca actualizaciones para las tareas a desarrollar.

 Al igual que el Producto Owner, el Scrum Master trabaja con otras figuras como son los  stakeholders, y
representa al equipo de trabajo en las reuniones de  Scrum of Scrums.En estas reuniones es donde el Scrum
Master presenta los temas de diesño técnico y las acciones llevadas a cabo por el equipo.

 La figura del Scrum Master refuerza así la idea de que esta metodología mejora el trabajo en equipo,
centrando todos los esfuerzos en conseguir un mismo objetivo para satisfacer las necesidades de los
stakeholders.
En muchos casos el perfil del Scrum Master es desempeñado por alguno de los miembros del equipo ágil de
proyectos. Además, sabemos que existen certificados para convertirse en Scrum Master profesional, no obstante
desde IEBS no queremos lanzar a los profesionales a la piscina y preferimos ofrecer un  Postgrado en Gestión Ágil de
Proyectos que ayude a conocer de la mano de profesionales, cuáles son estas metodologías ágiles y qué beneficios
aportan a las empresas.

13 HERRAMIENTAS PARA LA GESTIÓN ÁGIL DE PROYECTOS

Existen muchas maneras de apostar por ellas, tanto si puedes permitirte gastar dinero como si no es así. La cuestión
es tener ganas de cambiar las cosas para conseguir dinamizar a tu equipo de trabajo y rentabilizar tu negocio.

En multitud de sectores donde los cambios están a la orden del día las empresas necesitan desarrollar todos sus
servicios de forma rápida y competitiva. Esto se convierte en una tarea ardua para su consecución pero no
imposible. Normalmente, lo más recomendable es probar las diferentes funcionalidades del servicio para medir si
funciona o no. De ahí, ofrecer una perfecta solución final. Para que todo el proceso se realice correctamente,
el Digital Project Management se encargará de ello velando por ofrecer el mejor servicio a los clientes.

Para aplicar la gestión ágil de proyectos dentro de cualquier departamento empresarial se utilizarán diferentes
herramientas que conseguirán llevarte al éxito. ¿Cuál es la mejor? ¿Cuáles me ofrecen la opción gratuita o de pago?
Aquí te presentamos las 15 herramientas que resultan más útiles y rentables para una empresa:

Trello 

Lo cierto es que esta plataforma es extremadamente útil, flexible, visual y ¡GRATIS! Permite organizar visual y
temporalmente los flujos de trabajo cómodamente. Se hace a partir de columnas verticales a las que pueden
asignarse las distintas etapas del proyecto (pendientes, en curso, finalizadas…), notas, perfiles de  determinados
trabajadores, etc. También podremos crear categorías y check-lists para marcar todas las tareas terminadas o por
acabar, etc.

Trello tiene su app para smartphones y tablets, además de permitir el acceso web. ¿Te vas a perder las enormes
ventajas que te ofrece? ¡Seguro te quedarás con ella!

Atlassian Jira 

La herramienta ideal para las empresas de software. Tiene la posibilidad de organizar las etapas de un proyecto,
asignarlas a profesionales y seguir su desarrollo en equipo.

Su interfaz es muy cómoda e intuitiva porque muestra todas las actividades venideras, en desarrollo, finalizadas o en
incidencias desde un mismo módulo principal organizado por columnas.

¿Su inconveniente? Es de pago. Pero, a pesar de ello, este software no es excesivamente caro y permite la  descarga
de una semana de prueba totalmente gratuita. ¡La gestión ágil de proyectos nunca fue tan fácil!

Asana 

Con más de 400.000 usuarios Asana es uno de los software más populares del momento. Fue creada por Dustin
Moskovitz, co-fundador de Facebook y está diseñada para mejorar la comunicación y colaboración del equipo.

Los usuarios tienen muy buena opinión de Asana y alaban su diseño intuitivo. También sus funcionalidades: permite
a los profesionales visualizar sus objetivos, asignarles un tiempo y priorizarlos, recibir actualizaciones y visualizarlo
todo a modo de calendario.

Asana es gratis para equipos de 15 miembros, mientras que sus opciones de pago son: Premium Workspaces para
más de 15 miembros y Organizations para aquellas empresas con más de 100 empleados.

Axosoft 

Este software cuenta con cuatro módulos: Scrum, Gestor de fallos, Help Desk y Wiki. Optimiza los procesos
operativos mediante análisis automatizados, gráficos y un tablero que permite la visualización, edición y difusión de
tareas.
La aplicación de una gestión ágil de proyectos es sencillo a través de todas las posibilidades que nos oferta. A pesar
de ser una herramienta de pago, tiene la posibilidad de que el usuario se descargue una versión de prueba de 14 días
de duración. Si la pruebas, ¿nos cuentas si te has quedado con ella?

iceScrum 

Este software es totalmente gratuito y facilita el cumplimiento de objetivos empresariales. Permitie la organización
de tareas por columnas, exactamente igual que los anteriores. Sin embargo, como programa gratuito su ventaja se
centra en los análisis, indicadores y gráficos que construye a partir de los datos que proporcionamos. ¿Encaja entre
tus necesidades?

Scrumblr 

Y aquí una herramienta para los más perezosos que buscan facilidades dentro de su organización sin complicarse
mucho. Escribe el nombre de tu tablero y haz click en GO! Te aparecerá una pizarra cuyo tamaño podrás modificar y
junto a herramientas que tú mismo irás descubriendo.

Mediante el enlace podrás compartirlo con quien quieras. Podrán editar y modificar el contenido igual que tú. De
más utilidad es la versión para descargar (también gratuita) que igualmente puede visualizarse en el navegador web.
¿Lo negativo? La usabilidad está bastante abandonada.

LeanKit 

Con LeanKit aplicarás Kanban de forma rápida y sencilla organizando las tareas de cualquier organización de una
forma similar a las columnas verticales de otras plataformas pero incluyendo muchas otras funcionalidades (como
los análisis y recomendaciones de mejora), así como elementos visuales (subdivisiones dentro de cada columna).
Tiene una versión totalmente gratuita pero limitada a equipos pequeños. Por ello, es ideal para pequeñas empresas.

A pesar de esto, cuenta con versiones de pago que incluyen numerosas ventajas como las pizarras ilimitadas.
Cualquier empleado podrá realizar una gestión ágil de sus proyectos, ¿a qué esperas?

Active Collab

Una herramienta poco conocida pero con una interfaz muy sencilla y potente. Gracias a ser una plataforma intuitiva
y centrada en la optimización de recursos permite conocer en qué fase del proyecto está cada empleado, cuánto
presupuesto se ha destinado, si está atascado o qué carga de trabajo lleva cada trabajador.

Con ella podemos añadir o insertar estilos, imágenes, enlaces etc. y cualquier empleado conocerá qué tiene que
hacer, cuándo debe entregar sus tareas y mantener una comunicación fluida con el resto de su equipo. Suele ser
utilizada por los coordinadores o responsables de cada proyecto para controlar si el proceso cumple con sus
expectativas.

Flow-e

Se trata de una aplicación que trata tus correos como tareas sin necesidad de que tengas que salir de Gmail o de
Outlook. Por lo que, todos los cambios que hagas en Flow-e se hacen también al mismo tiempo en las cuentas de
correo sin que tengas que salir de la aplicación.

Flow-e es similar a Trello, ya que organiza todo en tres columnas destacadas (To-DO, Doing y Done) y cada tarea te
llega al correo como una tarea diferente. No te pierdas su funcionamiento con este vídeo:

Google Drive 

La archiconocida herramienta de Google es utilizada universalmente en el ámbito doméstico, escolar, universitario y

laboral. Cuenta con numerosas acciones ubicadas en Drive con las que podemos crear archivos Excel, Docs,
Presentaciones, Dibujos y Formularios, así como compartirlos con otras personas mediante invitación o la creación
de un enlace.

Asimismo, Drive también permite subir archivos de todo tipo, incluso en formato PDF, vídeo o audio. ¡Un lujo de
herramienta gratuita!
Basecamp 

Basecamp permite crear pizarras de discusión donde los trabajadores pueden escribir comentarios en tareas
específicas, listados de tareas e incluso un centro de intercambio de documentos que puede integrarse fácilmente
con el correo.

¿Inconveniente? Es de pago pero tiene una versión de prueba de una duración de 2 meses.

Slack

Es una herramienta donde triunfa la mensajería en tiempo real. Es decir, se creó para mejorar la comunicación entre
los equipos de una empresa. Su funcionamiento es como la red social Whatsapp con la ventaja principal de que es
compatible con Windows, iOs y Android.

Una de sus peculiaridades es que ofrece a los empleados una experiencia muy personalizable donde es posible crear
grupos de trabajo de forma independiente y salas comunes para contemplar cualquier necesidad de la organización.

La herramienta nos permite crear una comunicación fluida entre los trabajadores de la empresa desde cualquier
punto geográfico y posibilita el envío de documentación e información en tiempo real.

Planning Poker

Una herramienta basada en la gamificación, sencilla y simple de utilizar. Basada en la metodología de Scrum,
planning poker se basa en la técnica de estimación del tiempo que requiere una tarea que se produce en un equipo.
Su característica principal es que utiliza cartas numeradas basadas en la secuencia de Fibonacci y cuanto más alto es
el número mayor es la probabilidad de equivocarse en la estimación.

¡Los sprints no fueron tan divertidos desde la existencia de esta herramienta!

¿Nuestro consejo? Hay un sin fin de herramientas de gestión que facilitarán tus tareas diarias, pero cada empresa es
un mundo, por lo que recomendamos probar varias aplicaciones para determinar cuál de ellas se adapta mejor a tu
organización y a tus proyectos Agile.

Actualmente la gestión ágil de proyectos está de moda. Esto se palpa en el ambiente empresarial, por lo que conocer
y manejar las métodologías ágiles ofrecen un aumento de la productividad. No lo pienses más y aprende la disciplina
que está triunfando en todo el mundo con el Master in Digital Project Management. ¡Te esperamos!

Las metodologías ágiles

Por definición, las metodologías ágiles son aquellas que permiten adaptar la forma de trabajo a las condiciones del
proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las
circunstancias específicas del entorno.

Ventajas del Agile Project Management

A continuación enumeramos algunas de las ventajas que nos brinda la gestión ágil de proyectos:

 Mejora de la calidad del producto: Estas metodologías fomentan el enfoque proactivo de los miembros del
equipo en la búsqueda de la excelencia del producto. Además, la integración, comprobación y mejora
continúa de las propiedades del producto mejora considerablemente el resultado final.

 Mayor satisfacción del cliente: El cliente está más satisfecho al verse involucrado y comprometido a lo largo
de todo el proceso de desarrollo. Mediante varias demostraciones y entregas, el cliente vive a tiempo real
las mejoras introducidas en el proceso.

 Mayor motivación de los trabajadores: Los equipos de trabajo autogestionados, facilitan el desarrollo de la

capacidad creativa y de innovación entre sus miembros.

 Trabajo colaborativo: La división del trabajo por distintos equipos y roles junto al desarrollo de reuniones
frecuentes, permite una mejor organización del trabajo.
  Uso de métricas más relevantes: Las métricas utilizadas para estimar parámetros como tiempo, coste,
rendimiento, etc. son normalmente más reales en proyectos ágiles que en los tradicionales. Gracias a la
división en pequeños equipos y fases podemos ser más conscientes de lo que está sucediendo.

 Mayor control y capacidad de predicción: La oportunidad de revisar y adaptar el producto a lo largo del
proceso ágil, permite a todos los miembros del proyecto ejercer un mayor control sobre su trabajo, cosa que
permite mejorar la capacidad de predicción en tiempo y costes.

 Reducción de costes: La gestión ágil del proyecto elimina prácticamente la posibilidad de fracaso absoluto
en el proyecto, porque los errores se van identificando a lo largo del desarrollo en lugar de esperar a que el
producto esté acabado y toda la inversión realizada.

Metodologías ágiles más utilizadas

Pero, ¿cuáles son los tipos de metodologías ágiles más utilizados en las empresas actuales? Existen diferentes
opciones pero las más utilizadas son: programación extrema (XP), Scrum y Kanban, todas ellas se guían a través de
un patrón establecido por el Manifiesto Ágil realizado por varios autores que establecieron los 12 principios del
software ágil.

1# Extreme Programming XP

Esta herramienta es muy útil sobre todo para startups o empresas que están en proceso de consolidación, puesto
que su principal objetivo es ayudar en las relaciones entre los empleados y clientes. La clave del éxito del  Extreme
Programming XP es potenciar las relaciones personales, a través, del trabajo en equipo, fomentando la comunicación
y eliminando los tiempos muertos.

Sus principales fases son:

  Planificación del proyecto con el cliente

  Diseño del proyecto

 Codificación, donde los programadores trabajan en pareja para obtener resultados más eficientes y de
calidad

  Pruebas para comprobar que funcionan los códigos que se van implementando

2# SCRUM

Se caracteriza por ser la «metodología del caos» que se basa en una estructura de desarrollo incremental, esto es,
cualquier ciclo de desarrollo del producto y/o servicio se desgrana en «pequeños proyectos» divididos en distintas
etapas: análisis, desarrollo y testing. En la etapa de desarrollo encontramos lo que se conoce como interacciones del
proceso o Sprint, es decir, entregas regulares y parciales del producto final.

Esta metodología permite abordar proyectos complejos que exigen una flexibilidad y una rapidez esencial a la hora
de ejecutar los resultados.  La estrategia irá orientada a gestionar y normalizar los errores que se puedan producir en
desarrollos demasiado largos, a través de, reuniones frecuentes para asegurar el cumplimiento de los objetivos
establecidos.

Las reuniones son el pilar fundamental de la metodología, donde diferenciamos entre: reuniones de planificación,
diaria, de revisión y de retrospectiva, la más importante de todas ellas, ya que, se realiza después de terminar un
sprint para reflexionar y proponer mejoras en los avances del proyecto. Los aspectos clave por los que se mueve
el Scrum son: innovación, flexibilidad, competitividad y productividad.

3# Kanban 

La estrategia Kanban conocida como ‘Tarjeta Visual» muy útil para los responsables de proyectos. Esta consiste en la
elaboración de un cuadro o diagrama en el que se reflejan tres columnas de tareas; pendientes, en proceso o
terminadas. Este cuadro debe estar al alcance de todos los miembros del equipo, evitando así la repetición de tareas
o la posibilidad de que se olvide alguna de ellas. Por tanto, ayuda a mejorar la productividad y eficiencia del equipo
de trabajo.

Las ventajas que proporciona esta metodología son:

 Planificación de tareas

 Mejora en el rendimiento de trabajo del equipo

 Métricas visuales

 Los plazos de entregas son continuos

4# Agile Inception  

Está orientada a la definición de los objetivos generales de las empresas. Su meta es clarificar cuestiones como el
tipo de cliente objetivo, las propuestas de valor añadido, las formas de venta. Suele girar entorno al método de
«elevator pitch«, que consiste en pequeñas reuniones entro los socios y el equipo de trabajo en las que las
intervenciones no pueden superar los 5 minutos.

5# Design Sprint, la metodología de Google

En cualquier organización, la estrategia de negocios es lo más importante. Las metodologías agile se llevan
implementando desde hace una década con el fin de mejorar los procesos que llevan a un producto o servicio
mejorado y de calidad en el que los clientes cobran cada vez más importancia. Como ejemplo de innovación en
estrategias de negocios nos encontramos con Design Sprint, una metodología de Google que está favoreciendo a los
perfiles profesionales del mundo agile.

Esta metodología viene de la mano de Google Ventures, un servicio del gigante tecnológico para la innovación y
promoción de startups tecnológicas. Se trata de un proceso que dura 5 días en el que el negocio tiene que resolver
todas las cuestiones relacionadas con diseño, prototipado, testeo de clientes. La idea es que el trabajo se elabora en
etapas de sprints en las que meses de trabajo se pueden reducir en pocas semanas, en vez de esperar a lanzar un
producto para entender si la idea es buena, el prototipo proporciona antes la información para evitar posibles
errores.

Cómo funciona la Metodología Scrum: Qué es y cómo utilizarla

La gestión de procesos y equipos es una de las partes más complicadas para cualquier empresa. No se trata solo de
recursos. La optimización del tiempo, coordinación del equipo, definición de protocolos y la asignación de tareas es
un asunto de peso, que requiere de conocimiento, buen criterio y mucho tiempo para su implementación. Sigue
leyendo, te contamos cómo funciona Scrum, cuál es su marco de trabajo y cómo utilizarla de forma efectiva.

Para saber cómo funciona Scrum, debes tener claro que la falta de planificación conlleva sobrecostes, retrasos en la
entrega de proyectos, conflicto con los clientes u otros departamentos. ¿Y el uso de procesos anticuados? La
diferencia de criterios entre los propios integrantes a la hora de realizar su trabajo, la falta de unificación de
herramientas o la disgregación de procesos de trabajo lleva a malgastar tiempo, dinero y, en último término, a la
desmotivación del equipo.

Como respuesta a esta problemática surgen las metodologías ágiles. Nuevos sistemas de gestión que apuestan por
una gestión dinamizada y muy coordinada de los procesos para llevar a un nivel óptimo el uso que demos a nuestros
recursos.

¿Qué es Scrum?

La metodología Scrum permite abordar proyectos complejos desarrollados en entornos dinámicos y cambiantes de

un modo flexible. Está  basada en entregas parciales y regulares del producto final en base al valor que ofrecen a los
clientes. Dicho en otras palabras: Scrum sirve para mejorar el trabajo colaborativo entre equipos.
Se trata de una metodología que ayuda a los equipos a aprender y organizarse en base a las experiencias a la vez que
aborda problemas e invita a reflexionar sobre los éxitos y fracasos.  Todo ello bajo una serie de herramientas y
recursos que permite a los equipos organizarse con mayor agilidad.

Es una opción de gestión ideal para acometer proyectos desarrollados en entornos complejos que exigen rapidez en
los resultados y en los que la flexibilidad es un requisito imprescindible. Scrum ofrece agilidad y el, resultado,
siempre, valor.

Perfiles de la metodología Scrum

Como decíamos, este método no sería posible sin el concepto de «equipo de trabajo». Entre los puestos de trabajo
Scrum, encontramos a los Product Owner o el Scrum Master. Te contamos cómo trabaja cada uno de ellos:

Qué es un Product Owner

Por una parte, tenemos al Product Owner, que representa la voz del cliente y del resto de interesados no implicados
directamente en el proyecto. Este perfil es el encargado de definir los objetivos del proyecto y de garantizar que el
equipo trabaja del modo adecuado para alcanzar dichos objetivos.

Qué es un Scrum Master

El Product Owner no está solo. El Scrum Master es el encargado de asegurar que el resto del equipo no tenga
problemas para abordar sus funciones y tareas. Guía y ayuda al Scrum Team para garantizar el cumplimiento de
objetivos. En otras palabras, este perfil ayuda al equipo a mantenerse activo y productivo.

Qué es un Scrum Team

El Scrum Team es el equipo encargado de desarrollar y entregar el producto. Su trabajo es imprescindible: estamos
hablando de una estructura horizontal auto-organizada capaz de auto-gestionarse a sí misma.

Qué es un Stakeholder

Y, finalmente, tenemos que hablar de los Stakeholders. Este grupo comprende aquellos perfiles interesados en el

producto: directores, dueños, comerciales. Se trata de perfiles que si bien no forman parte del Scrum Team deben
ser tenidos en cuenta.

Cómo funciona la metodología Scrum

Para saber bien cómo funciona Scrum y qué es la metodología Scrum, debes saber que existe un marco de trabajo
para su desarrollo, que comienza con la elaboración del llamado Product Backlog. Te lo contamos más
detalladamente.

Qué es un Product Backlog

El proceso comienza con la elaboración del llamado Product Backlog. Se trata de un archivo genérico que recoge el
conjunto de tareas, los requerimientos y las funcionalidades requeridas por el proyecto. Cualquier miembro del
equipo puede modificar este documento pero el único con autoridad para agregar prioridades es el Product Owner,
responsable del documento.

El autor Mike Cohn, experto en compañías software, utilizó el acrónimo «DEEP» para referirse a las diferentes etapas
o fases de un buen Product Backlog. Corresponden a las iniciales de:

 Detailed Appropriately: en esta fase se definen los requisitos del producto con las características que
afectan al desarrollo del producto.

 Emergent: esta parte define el Product Backlog como algo que no para de evolucionar y cambiar, ya que
siempre se adaptará a las demandas del cliente y por ende, a las decisiones del Product Owner.

 Estimated: esta parte quiere decir «estimado», ya que se refiere al valor aproximado según el esfuerzo y el
valor que se le de al proyecto.
  Prioritized: esta parte define el hecho de que, en el Product Backlog todos los elementos deben estar
priorizados y repartidos en categorías.
Qué es un Sprint Backlog

Es un documento que recoge las tareas a realizar y quién las desempeña. Es interesante asignar las horas de
trabajo que va a suponer realizar cada una de ellas y asignarlas a un coste. Si su volumen es muy grande, crear metas
intermedias será un acierto.

El Sprint es el periodo en el que se realizan todas las acciones pactadas en el Sprint Backlog , que supone entregas
parciales para ir testeando el producto final.

El ciclo anterior deberá repetirse hasta que todos los elementos del Blacklog hayan sido entregados. Entre los
distintos Sprints no se deben dejar tiempos sin productividad.

Qué es un Sprint Review

Todas las acciones que realicemos han de tener un control. Es en el  Burn Down donde marcamos el estado y la
evolución del mismo indicando las tareas y requerimientos pendientes de ser retratados.

En esta fase final del Sprint, se revisa todo el trabajo, una buena oportunidad para tener feedback sobre el
desarrollo del producto.

Puede ser una reunión informal, siempre y cuando se tenga el objetivo claro del  Sprint Review: brindar
transparencia tanto al equipo como al cliente. Suele durar unas cuatro horas horas para Sprints de cuatro semanas.
Es decir, una hora por cada semana. La persona encargada de realizar este trabajo es el Product Owner, mientras
que el Scrum Master se asegura de que esto sea así y de que se cumplan los tiempos establecidos.

Entonces ¿qué ocurre en el Sprint Review? Dentro de esta fase, en la que ya sabemos que  el Product Owner es el
encargado total de la revisión, se encarga de explicar los items del Product Backlog y asegurarse de que hayan sido
finalizados.

A su vez, el equipo de desarrollo se encarga de hacer la demostración del incremento terminado durante el Sprint y
responde a dudas relacionadas con ello.

A partir de ahí se hace una review del proyecto y se tratan los siguientes pasos a seguir. Si hay una respuesta por
parte del cliente, el Product Owner reorganizaría el Product Backlog.

Por último, se hace una última revisión sobre tiempos, presupuesto y alcance del proyecto.

Sprint Planning Meeting

¿Quién no ha perdido horas de trabajo inútiles en reuniones poco productivas porque estaban mal preparadas? Esto
no tiene cabida en los métodos ágiles. Cada minuto cuesta dinero. Las reuniones han de estar también planificadas,
como una parte más de proceso. En este «Sprint Planning Meeting» el Product Owner prioriza las tareas contenidas
en el Product Backlog.

Con estas tareas en mente se determina el objetivo del nuevo sprint priorizando las tareas a realizar por el Scrum
Team y asignando tiempo a cada una de ellas. El objetivo debe ser alcanzable y el equipo sólo abordará un conjunto
de tareas asumible.

Diariamente se hace un seguimiento del proyecto en esta reunión en la que se controla el cumplimiento de las
tareas asumidas. Quizás has oído hablar de la Daily Scrum, que es el nombre adoptado del inglés. En dicha cita se
pactan los objetivos para el día siguiente y se analizan los posibles problemas que hayan limitado o impedido
directamente el cumplimiento de los objetivos.
Beneficios de la metodología Scrum

Los beneficios de Scrum son amplios y repercuten en el equipo, en los Stakeholders y en la organización en su
conjunto.

Se fomenta el trabajo en equipo, focalizando todos los esfuerzos en alcanzar un objetivo común. Se trata de un
modelo basado en la auto-disciplina y la auto-gestión, lo que repercute positivamente en la responsabilidad.
Respecto al aspecto comunicativo, esta metodología fomenta la comunicación entre los distintos miembros del
equipo.

Los Stakeholders tienen un mayor control y transparencia sobre el proyecto, permitiendo una mejor organización. El
cliente puede hacer seguimiento más cercano de lo que pasa, sin tener que esperar a un resultado final que no le
convenza. Con las metas intermedias se minimizan riesgos.

En definitiva, la adopción de estas buenas prácticas permite reducir el tiempo de desarrollo de productos,
más capacidad de adptación y flexibilidad frente a un entorno y unos requisitos cambiantes aumentando el valor
que se aporta a los clientes.