SCRUM

8. oct., 2019

En este artículo queremos mencionar las principales caraterísticas de la arquitectura ágil resultado de la investigación de diversos artículos escritos por arquitectos y agilistas expertos en éste tema.

Así cómo los arquitectos tradicionales realizan procesos de modelado de construcciones a un alto nivel de abstracción, proveen posibles alternativas frente a la solución de un problema, mejoran la comunicación con los miembros del equipo de construcción a través de modelos, visualizan las generalidades de un  problema, definen los roles y las interacciones entre los componentes de construcción, entre otras tareas. El arquitecto de sofware hace los mismo en los proyectos de TI.  De esta manera se hace imposible pensar que un rascacielos de 300 metros pueda ser construido sin una arquitectura sólida, es imposible pensar que productos de software empresariales y aplicaciones - Apps puedan ser implementados de manera estable sin una arquitectura bien concebida.

De acuerdo con lo que dicen los autores Bass, Clements y Kasman - “La arquitectura de software de un programa o sistema informático, es la estructura o estructuras del sistema, que incluyen elementos de software, las propiedades externamente visibles de esos elementos, y las relaciones entre ellos.” Esta definición nos lleva a concluir que la arquitectura de software brinda una garantía de calidad del desarrollo de software y permite tener un sistema que cumpla con los requerimientos funcionales y no funcionales que el cliente espera. Por otra parte, la arquitectura es clave en la reutilización de artefactos de software en sistemas de líneas de productos de software, es decir, que influye en la eficiencia de manera directa. 

El autor Charlie Alfred dice textualmente : “La arquitectura es el aceite y el filtro que lubrica adecuadamente a Scrum”.

Teniendo presente la importancia de la arquitectura en el mundo del desarrollo de software, mencionaremos las  principales caraterísticas que se debe tener la arquitectura en un entorno Ágil. Dado que en los entornos actuales (VUCA) como ya hemos mencionado en artículos previos las condiciones son un poco diferentes por la velocidad que el cambio trae al mercado.

"Características de la arquitectura Ágil":

1. Arquitectura Incremental: Para iniciar, hay muchas personas que consideran que al iniciar el proyecto se debe contar con todo el diseño de la arquitectura (claro y detallado) antes de iniciar el trabajo por parte de los desarrolladores o el Sprint 1 y tenemos que es por ello que en la metodología tradicional ésto tomaba mucho tiempo de análisis - generando la no producción de ningún entregable en una fase inicial. Al fenómeno de diseñar a la perfección le llaman algunos autores "Big Design Upfront". Este enfoque ha sido  ampliamente criticado en los últimos años por quienes adoptan marcos de trabajo ágiles. Bajo un enfoque ágile se habla de una arquitectura base que tiene evolución a lo largo del proyecto, es decir, una arquitectura incremental. Se desconfía de un gran modelo de diseño y lo que se busca es definir la arquitectura mínima con la cual se podría iniciar la operación del primer entregable o en mejores términos del Mínimo producto viable. De este modo Sprint tras Sprint se pueden ir incluyendo cambios en la arquitectura buscando su optimización. Es importante decir en este punto, que esto no implica que no iniciemos con algunos elementos mínimos de referencia como son : un lenguaje definido, un framework, una base de datos, etc. Es común, también que dentro de una organización tengamos algunos lineamientos, estándares y políticas ya previamente definidas que se deban utilizar y otras que definirá el equipo Scrum de manera colaborativa. Lo que nos deja  abierta la posibilidad de cambiar algo más adelante, si nos damos cuenta que nos conviene para nuestro proyecto.

2. Diseño emergente : Esta es una propuesta respaldada por muchos en los entornos ágiles para el diseño de software, pues considera que el proceso de analisis  y diseño de software emerge cuando sea necesario para entregar los incrementos de cada sprint. Uno de los fundamentos de este enfoque es "la idea del cambio continuo". Aún cuando los requerimientos de software no cambien, en los últimos años la tecnología y la gente sí lo hace, cada vez con más frecuencia. Al finalizar el proceso de desarrollo y entregar los resultados finales, quedará un diseño simple y conforme a lo que fue realmente es necesario, que puede evolucionar con el tiempo siguiendo el mismo método.

3. Definir el propósito del diseño : No debemos olvidar que el propósito del diseño de software es principalmente comunicar de forma técnica las diferentes estructuras y comportamientos de un software, para facilitar su estudio, construcción y mantenimiento, así como la orquestación de los esfuerzos de construcción.

En la academia suele ser admirada y recomendada la notación UML,  que comprende diferentes diagramas y modelos aplicable a distintos niveles del diseño de un software. Esto no significa, que sea necesario diagramar absolutamente todo lo que esté allí definido. En  tanto los ingenieros logren comprender el diseño y construir el software de forma organizada, el propósito habrá sido cumplido. Por tanto, el diseño sólo debe cubrir aquello que sea necesario comunicar y bajo el medio más efectivo y óptimo para hacerlo. No debemos olvidar que a veces "Menos es Más", no quiero decir que no debemos documentar el diseño a lo que me refiero es que lo más importante es tener diseños simples.

4. Flexibilidad: Por la forma en que se construyen las aplicaciones hoy en día, es muy común la adopción de frameworks, el uso de APIs, librerías y de convenciones para facilitar los esfuerzos de construcción. El diseño de estos componentes está previamente definido.

Un desarrollador simplemente debe comprender la arquitectura de estos frameworks y apegarse a las convenciones recomendadas para que su diseño se mantenga consistente, y por tanto, sea fácil de asimilar por alguien más que domine el mismo framework.

Así, muchos aspectos del diseño se reducen a definir la arquitectura del software, sus componentes, aspectos de GUI y UI y UX, estructuras de datos, flujogramas, entre otros elementos estrictamente necesarios para comprender y avanzar.

5. Modelo C4: El autor Simón Brown quien es un consultor independiente en desarrollo especializado en arquitectura de software. Hace aproximadamente 2 años propuso un modelo para diseño de software simple, fácil de navegar y que comunica con más eficiencia.

Su modelo lo llamó Modelo C4, el dice que basta con definir los siguientes cuatro diagramas, relacionados entre sí y navegables en profundidad como si fuese un mapa:

  • Contexto: Visualiza el sistema en la organización, su relación con distintos actores que pueden ser usuarios y otros sistemas.
  • Contenedores: Visualiza la división del sistema en entornos de ejecución o almacenamiento, reflejando mejor la infraestructura.
  • Componentes: Visualiza internamente las piezas que componen un contenedor en particular, como aplicaciones o servicios.
  • Clases: Consiste en un diagrama de clases UML para aquellos casos donde sí sea necesario llegar a ese nivel.

6. Validación continua: Más allá de una visión general de guía, igual que con la funcionalidad, tratamos de dejar una prueba automatizada que nos ayude a validar que logramos el efecto que queríamos al implementar cada pieza de arquitectura: por ejemplo, pruebas de performances, de carga, de extensibilidad, validaciones de nivel de acoplamiento o complejidad, etc. Esas pruebas se ejecutan de manera continua, al igual que las pruebas unitarias o de aceptación. 

Esa validación permanente en el entorno de desarrollo y de QA se extiende también a mediciones en el proceso automatizado de deployment, y al monitoreo de la solución en el ambiente productivo (monitoreo de servidor, clientes, dispositivos, plataforma, etc). Todo ese seguimiento es lo que nos permite entender si nuestra arquitectura realmente está soportando lo que necesitamos en este momento, y también comprobar si cualquier cambio tiene el efecto deseado o no. Ese nivel de feedback es lo que nos permite encarar cambios en la arquitectura sin entrar en pánico y poder tomar mejores decisiones en nuestro modelo de arquitectura.

7. La arquitectura no es solo una tarea del arquitecto: Como mencionabamos previamente, dado que no se diseña la arquitectura por completo desde el inicio y que no es un tema que atañe solo al que tiene el título del "Arquitecto" sino que es un tema discutido por todo el equipo e incluso con el Product Owner y los involucrados del negocio. Y dado que las decisiones se realizan de manera colaborativa, teniendo en cuenta todos los puntos de vista. Nos encontramos también con que las decisiones tampoco suelen ser finales, sino que se diseñan experimentos, con métricas asociadas y un objetivo a alcanzar, que se va validando en la implementación. Ahora bien, no quiere decir esto que si tu compañía tiene un equipo de Arquitectura Corporativa o Empresarial esto está mal. La diferencia es que esos grupos se ocupan más de entender las restricciones generales necesarias para el negocio, la plataforma común, el ecosistema de diferentes aplicaciones (propias y de terceros), y actúa como un participante frecuente en las reuniones de planificación de los equipos, no para imponer definiciones, sino para tener feedback y colaborar en las definiciones de cada aplicación apoyando al equipo y ayudando a tomar mejores decisiones.

Todas estas ideas tienen mucho más contexto y trasfondo. Quisimos en esta pequeña recopilación de información - mostrar un breve resumen de lo que investigamos de algunos artículos revisados y con base en nuestra experiencia en proyectos de TI llevados a cabo bajo  marcos de trabajo ágiles y utilizando Scrum como framework principal.

Si te gustó esta información compártela con familiares, colegas y amigos.

Visita nuestos otros blogs en el siguiente link : http://www.pmpmedellin.com/431433692.

Autor : Ing. Javier León Reyes

Fuentes consultadas:

Paper “Software Architecture in the Agile Life Cycle”  2013. Lo puedes revisar en este link:

https://www.dropbox.com/s/ho52huc71ewe6tz/Arquitectura%20en%20el%20Ciclo%20de%20Vida%20Agil.pdf?dl=0

https://martinalaimo.com/es/blog/arquitectos-agiles

https://jonathan.vargas.cr/es/temas/desarrollo/18287-arquitectura-y-diseno-de-software-en-el-mundo-agil

https://sg.com.mx/revista/30/el-papel-la-arquitectura-software-scrum

https://www.codeandbeyond.org/2018/09/3-elementos-para-una-arquitectura-mas.html 

26. sep., 2019

En el siguiente link podrás descargar el informe completo que contiene las tendencias para esta profesión de los Scrum Master emitido en este año 2019 por la Scrum.org

Link: 

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2019-02/2019%20Scrum%20Master%20Trends%20%282019-02-06%29.pdf

26. sep., 2019

Muchas veces me he puesto a reflexionar sobre lo que significa para el Marco de trabajo "SCRUM" que significa "Generar Valor". Luego de leer un artículo simple pero muy significativo del ingeniero informático Fabian Aguilar encontré sentido a la frase "Generar Valor en un equipo ágil".

Es claro para todos que luego de finalizar una iteración en Scrum o un Sprint, se debe entregar un incremento de producto o un entregable que genere valor. Sin embargo, lo que vemos en un porcentaje alto de los casos es que no siempre es así. El Product Owner es el responsable de la situación porque es quien debe velar porque éste sea generado.

Sin embargo, hay un falso mito en los ambientes laborales y es que debemos generar "Software Funcionando", a veces generamos en los equipos software funcionando pero no generamos valor para el cliente o usuario final.

Es por ello que es clave definir que es "Generar Valor" antes de continuar, para ello debemos apoyarnos en 3 tipos de indicadores que nos permiten identificar donde hay "valor". Ellos son Output, Outcome y el Impact. Ahora bien , revisemos cada uno de ellos...

1) Los Outputs: Son las funcionalidades, módulos o entregables que ponemos en manos de los clientes/usuarios tanto internos como externos.

2) Los Outcomes: Son más métricas que indican cambios que mejoran los comportamientos de los clientes/usuarios. Es decir, son temas relacionados con  alguna tarea o actividad que realiza el usuario que se vea influenciada por un Output.

3) El Impact: Son las métricas de impacto en el negocio. Es decir, representan el mediano y largo plazo. Temas como: Rentabilidad, Ingresos, Costos. Y estos son modificados o impactados en el tiempo por los Outcomes.

De primera mano, no es tan simple. Veamos algunos ejemplos para que puedas entenderlo mejor.

Primer Ejemplo: Imaginate que tienes como meta o deseo vender más en tu sitio web - entonces, creas una funcionalidad que registra la historia de compra de tus clientes en tu sitio y sus artículos más visitados, con el fin de enviarles promociones posteriormente con base en esa información recolectada  ¿Cuál es el outcome? que se provoque un cambio del comportamiento de los clientes que visitan el sitio al recibir ofertas de interés y que  aumente la probabilidad de compra ¿Cuál es el output? Una funcionalidad plasmada en una historia de usuario que contiene el record de la historia de compra y la generación de  promociones con las estadísticas halladas.

Segundo Ejemplo: Imaginate que quieres reducir costos entonces, creas una funcionalidad o un proyecto que hará que los usuarios se demoren menos tiempo en realizar una tarea "x" identificada, al tomar menos tiempo el costo por tarea se reduce y se acumulara una reducción de costos en el mediano y largo plazo. El output en este caso es el proyecto o funcionalidad, el outcome es la reducción de tiempo para el usuario y el impact es la reducción de costos para la compañía.

Tercer Ejemplo: Imaginate que quieres reducir costos entonces, se tiene que  las transacciones online son más económicas para la compañía que las transacciones offline entonces se crea un proyecto para digitalizar las 3 transacciones mas importantes en el canal web. El OutCome sería el cambio de comportamiento de los clientes que en vez de ir a la sucursal utilicen el  canal digital (canal web habilitado) y el Impact en el mediano y largo plazo es el ahorro dado que las transacciones online son más económicas.

Ahora bien, con estos ejemplos lo que podemos ver que en las organizaciones se está generando un problema porque se está prestando más atención a la medición del Output y se deja de lado  el Outcome y el impact. Por ello muchos indicadores resultan como métricas vanidosas y si quieres ver un ejemplo podemos mencionar estas métricas para que reflexionemos un poco: Número de proyectos terminados, Número de pasos a producción en el mes, Número de pasos a producción con Devops, Nuevas funcionalidades implementadas. Les voy a poner ironicamente una métrica vanidosa del Agiles 2019 Rosario Argentina recientemente publicada ¿ 60 mil post-its ? . Cuando yo la ví me pregunté y eso genera valor ? Les dejo la inquietud porque eso nos dice mucho de lo que pasa en las organizaciones con los Agile Coach que lideran los procesos de transformación y los Scrum Másters que apoyan la misma tarea.

Siento que cuando las organizaciones se enfocan en el Output como métrica de éxito, generan al final equipos infelices y sin sentido. Porque son equipos que gastan más, se sobrellenan de proyectos o iniciativas, sobrecargan a sus personas y en general logran menos. A mi modo de ver comparto la opinión del autor, las organizaciones y equipos necesitan enfocarse en los Outcomes - enfoque en el resultado. Allí está el valor y es lo que tiene impacto en las métricas de salud del negocio.

Y bueno, ¿ cómo defino entonces un buen objetivo para mi equipo ?

Quiero decirte mi amigo lector, que cuando a un equipo le pones como meta 10 funcionalidades pre-establecidas por semestre o 2 funcionalidades por Sprint lo que tienes como efecto es que mermas la innovación, destruyes el aprendizaje del equipo y limitas el feedback del cliente/usuario. En cambio, cuando la meta es un Outcome, por ejemplo, aumentar las transacciones online de los clientes en un 10%. Entonces con ello das pie para que se genere innovación colectiva, se presta para que haya investigación y conexión con el cliente, porque entonces el equipo tendrá que explorar cuales Outputs provocan ese Outcome.

Recuerda que en el Outcome está el Valor y se puede medir desde que es puesto en manos del cliente el Output. Para terminar esta disyuntiva quiero mencionar que el enfocarse en Outputs muchas veces destruye valor más que el que se genera. Cuando un equipo corre por lograr la meta de 10 funcionalidades en un plazo determinado, puede sacrificar experiencia y calidad, lo que provocara un Outcome negativo en el cliente. Si para un cliente la experiencia de compra o transacción online es demorada , tiene un mal performance, es complicada, enredada no se producida el Outcome deseado. Lo que obtendrás será todo lo contrario y tu cliente abandonará la experiencia online o buscará esa experiencia en otro sitio web.

Por otro lado, no nos olvidemos del cliente interno, el talento de la organización, cuando pones en sus manos herramientas engorrosas y complicadas para hacer su trabajo, el Outcome también será negativo y probablemente busquen la forma de hacer su trabajo sin usar la herramienta o dándole un mal uso a la herramienta para saltarse pasos, validaciones, etc. Esto me lleva a pensar en otra reflexión que hacía hace pocos días sobre el hacer las cosas simples y maximizar el trabajo no realizado , esto lo que quiere decir , en palabras castizas es que muchas veces desgastamos a nuestros equipos obligandolos a utilizar patrones de desarrollo y de diseño o patrones de arquitectura que simplemente están de moda pero que muchas veces no se amoldan a nuestra organización  o a la arquitectura que tenemos y por ende codificar con ellos lo que hace es la vida más dificil para los desarrolladores. Por ello te invito a pensar en hacer las cosas lo más simples y prácticas. Piensa en el objetivo que buscas y como poder lograrlo de la forma más sencilla posible y no implementar cosas por implementarlas, porque allí perdemos valor en lugar de ganarlo.

Si te detienes a revisar, hay aplicaciones informáticas, Apps y herramientas que tienen muchas funcionalidades pero que en realidad los usuarios no las utilizan, y si no me crees vamos a algo más simple... Mira el control de tu televisor y piensa de todas las opciones que tiene ¿ Cuales son las que más utilizas a diario ? ... Si no me crees, revisa las Funciones que puede tener tu lavadora o un microondas en tu casa , tienen muchas funciones cierto y cuales utilizas en realidad - ¿ cuales te agregan valor? . Espero que con ello reflexiones un poco y cada vez que hagas las veces de Product Owner pienses en estos tres conceptos y en su aporte al negocio.

Si te gustó el artículo compártelo con amigos , colegas y familiares. Visita nuestros Blogs de Tecnología, videojuegos y  Social Media donde publicamos información de interés y actualidad.

Autor: Ing.Javier Mauricio  León Reyes

Twitter e Instagram: @PMPmedellin

 

19. sep., 2019

En la semana en curso estamos dictando un curso de Certificación para Scrum Mastér - SMC  y SFC y en una de las sesiones del curso un alumno me preguntó si conocía el término "Spike" aplicado en Scrum.

En realidad me quedé pensativo un momento, dado que esta terminología no la había escuchado en mi tiempo de experiencia en el mundo del agilismo y me dí a la tarea de investigar un poco sobre el tema para poder atender su pregunta y conocer un poco más. Resulta que a pesar de que no conocía el término como tal, porque de forma particular en mi organización lo llamabamos con otro nombre particular - "Tareas Habilitadoras" si lo he utilizado en la vida real en varios proyectos en los cuales he trabajado en los últimos 4 años.

Ahora bien, ¿ Qué es un Spike?  Un spike es un término que se utiliza en desarrollo ágil para incluir una tarea en un sprint que no pertenece necesariamente a una historia de usuario. Es una de esas prácticas ágiles poco conocidas pero muy útiles. Aunque como todo en la vida tiene detractores y tiene fans. Los spikes tienen una característica particular y es que su duración puede ser como máximo el tiempo de la longitud de la iteración o del sprint en el cual sea incluído.

Y ¿Para qué sirve un Spike? Un spike sirve para incluir en un sprint tareas que NO implican desarrollar una historia de usuario particular y por tanto NO aportan directamente al incremento del producto que se está desarrollando. Pero que son necesarias para poder estimar una historia en el próximo Sprint y para poder trabajarla en el próximo sprint.

¿Qué otros usos se le podrían dar a los spikes dentro de un sprint de Scrum?

-Documentar partes muy críticas del código o del producto: Como todos conocemos, las metodologías ágiles no son muy partidarias de la documentación exhaustiva - es más, los equipos le huyen a la misma en la vida real cuando no debería ser así. En este caso se podría incluir un spike en un sprint.

-Adquirir nuevos conocimientos: Muchas veces el ritmo de la tecnología va muy rápido y cuando ya dominas una tecnología cae la maldición china y aparece una nueva que la reemplaza. Con los desarrolladores no es la excepción ya que cuando dominas un lenguaje aparece el otro nuevo que te simplifica tareas o facilita su mantenimiento. Es por ello que adquirir conocimiento contínuamente es una necesidad. Dedicar unos días a actualizar conocimientos es algo que se puede hacer en Scrum con un spike.

-Formación interna: Parar uno o dos días, juntar al equipo de desarrollo y que se compartan conocimientos es algo muy beneficioso y es además necesario sobre todo cuando tienes módulos o necesitas integrar sistemas. Entonces, la tarea es incluir dentro de la planificación del sprint un spike para dicha acción.

En mi opinión particular, tiene como ventaja que facilita la estimación de una historia de usuario futura y en segundo lugar que hay tareas de investigación del equipo que son necesarias para aportar al a mejora continua (fin último de scrum), pero también tiene una desventaja y es la siguiente si todo el equipo scrum se volca a trabajar Spikes en un Sprint la velocidad del equipo va a bajar y la razón es porque se está trabajando en tareas que no aportan valor directamente a los entregables de ese sprint. Entonces, bajo ese orden de ideas distorsionan los indicadores del equipo y representan trabajo que no se refleja de alguna manera, pero que implica esfuerzos.

Si utilizas Spikes , permitenos conocerlo y conocer tu opinión en nuestro sitio con un comentario en la página principal. Esperamos tus aportes.

Autor : Ing.Javier León Reyes

Twitter e instagram : @PMPMedellin  

11. sep., 2019

En PMPMedellin hemos escrito últimamente una serie de artículos sobre el tema de la #TransformaciónDigital o Transformación ágil y en el proceso de investigación sobre el tema hemos encontramos un escrito que nos ha llamado la atención y que quisimos tomar como base para escribir el presente artículo que les compartimos en el día de hoy.

Dicho artículo original es del autor "Luis Ferrándiz" quien es socio de la firma consultora internacional McKinsey & Company y cuyo título es: "Los siete pecados capitales de la transformación agile".

Como hemos mencionado en artículos anteriores el mundo está cambiando y la forma de actuar de las organizaciones tiene que sincronizarse y ponerse a tono con dicho cambio. Es por ello, que las compañías tradicionales deben cuestionarse la manera como están actuando frente a sus clientes y cómo deben pararse en el mercado para competir con las mismas condiciones que su competencia. En muchos casos la respuesta radica en "Ser más ágil" como lo propone el autor del artículo original que mencioné.

Ahora bien, es claro que algunos movilizadores de la innovación son la implementación de los principios Agile, otros son tener la capacidad de desaprender y aprender de forma rápida y la adaptación como un medio de supervivencia. El agilismo junto con sus metodologías arrancaron como un grupo de principios para el desarrollo de software - es decir- pensando en escribir código y hacer su despliegue de forma reiterativa sin tener que esperar muchos meses e incluso años para lanzar nuevas funcionalidades a los clientes y usuarios. A pesar de que el agilismo se ha escalado dentro del desarrollo de soluciones e incluso en otras industrias y se han visto notorias ventajas como son: tener desarrollos de producto de forma iterativa e incrmental, desplegar con una mayor frecuencia, centrarse en el usuario y lograr la cooperación y colaboración entre equipos cross-funcionales de alto desempeño, siempre priorizando bajo el esquema de prueba-error. Pero como en la vida no todo es color de rosa, así como hay una serie de ventajas se han identificado algunas disfunciones – que hemos querido llamar pecados que deben tenerse presente si las organizaciones quieren repensarse de una manera correcta.


Pecado Número 1: No alinear las aspiraciones con el valor real de una transformación agile

Para cualquier organización una transformación ágil consta de un cambio cultural y un rediseño de su modelo operativo y uno de los mayores errores a la hora de embarcarse en tal viaje reside en no alinear en primer lugar las aspiraciones y el valor potencial del cambio a nivel de líderes de la organización. La premisa fundamental que ha de guiar la implementación de Agile es la coordinación de un enfoque y velocidad únicos entre la dirección y los equipos. Hay que crear una voluntad de cambio de status quo y romper con el "business as usual" a todos los niveles.

Pecado Número 2: No considerar agile como una prioridad dentro de la Estrategia

Esto sucede con líderes inmediatistas que quieren ver de la noche a la mañana los cambios implementados, dejando de lado que ésto en el fondo implica un cambio de cultura organizacional que no se puede alcanzar en una semana. Es muy común ver que las compañías terminan limitando agile a pruebas piloto dentro de una pequeña parte de la organización, restringiendo su potencial éxito a pocos equipos o un grupo de tecnólogos. Si limitamos la naturaleza del piloto de esta manera, restringimos también el campo de visión del equipo directivo con respecto al alcance real del cambio. En este sentido, es clave brindarle continuidad y ‘anchura’ al proyecto, dejando que vaya más allá de la prueba piloto y cale a mayor escala para evaluar los beneficios reales. Bajo el lente del autor Luis Ferrándiz Agile debería propargarse no en zonas dentro de la organización sino implantarse en Big Bang a toda la organización. Yo apoyo la idea de que de esta manera la alta gerencia puede tener una mayor visual de lo que se puede alcanzar pero hacerlo en algunas vicepresidencias inicialmente o en algunas áreas facilita el tema del aprendizaje (Prueba y Error) y permite conocer como será la resistencia al cambio , identificar barreras de entrada en la organización para hacer una mejor masificación y poder lograr identificar el mejor modelo operativo en pequeño. Como vemos son dos formas de hacer las cosas y bueno el autor tendrá sustento para apoyar su idea. Sin embargo, aislado del como lo haga - Contar con el apoyo de la alta gerencia es clave, bien lo vemos en los resultados del último informe de agilismo a nivel mundial que la falta de apoyo gerencial es una de las principales barreras con las cuales se cuenta para adoptar agilidad, donde se menciona que el 44% de los encuestados así lo manifiestan.

Pecado Número 3: No priorizar la cultura como el principio fundamental del cambio

Como ya lo mencioné anteriormente, es imposible llevar a cabo una transformación agile sin considerar su impacto a nivel de la cultura empresarial. Ignorar este hecho es uno de los mayores errores que puede cometer una compañía embarcada en un proceso de cambio. Si bien ello implica la transformación de formas de trabajo, hay otras implicaciones profundas a nivel operativo del equipo ejecutivo - recordemos que "Culture is the king".

Pecado Número 4: No invertir en el talento

Es claro que el desarrollo del agilismo se puede notar en muchas de las start-ups de Silicon Valley . Pero ellas no habrían progresado, si no se hubieran centrado en encontrar y fichar al mejor talento. Éste es el verdadero petróleo de la máquina Agile y solo con buen talento las compañías son capaces de crear equipos verdaderamente multifuncionales y de alto desempeño, equipos empoderados que ejecuten e implementen la nueva hoja de ruta. Lidiar con talento conlleva una serie de cuestiones críticas relacionadas con aspectos como capacidades, gestión y transición, rendimiento o formación. De forma adicional a lo que menciona el autor, nosotros agregariamos que aparte del contar con un buen talento, el no tener clara una estrategia de gestión del cambio también puede convertirse en un pecado dentro de este proceso de transformación. Ya lo habíamos mencionado en un artículo anterior, que muchas empresas se dedican a pensar en abaratar costos de cuenta de la contratación de personas que atienden múltiples proyectos a la par o que practican el outsourcing solo pensando en el costo y no pensando en tener unas mejores capacidades y ello se puede volver un pecado. Lo otro relacionado con el talento humano es que a veces como estamos en esta ola de cambios las empresas piensan que los empleados deben autocapacitarse solos y se está dejando de lado temas de formación dentro de las organizaciones (ésto lo considero como otro pecado). Esta bien que los equipos son autoorganizados y autosuficientes y aprenden de forma colectiva con su quehacer, pero ayudarles a crecer también es responsabilidad de los Scrum Máster y Agile Coach y esto se logra con negociaciones dentro de la misma empresa para buscar capacitaciones o formaciones.

Pecado Número 5: Dejar de lado el pensamiento estratégico a la hora de escalar el cambio

A la hora de escalar la transformación, hay que tener en cuenta planificación previa de procesos y tiempos. Es clave la preparación de la organización, las restricciones de recursos, el "ancho de banda" de liderazgo y, en consecuencia, el ritmo de la transformación, entre otras cosas. Estos planes deben ajustarse en base a los aprendizajes a través de la implementación. El autor Ferrándiz propone lo anterior pero le añadiria que la alta gerencia debe conocer su organización y saber que los cambios no se dan a la voz de mando sino que toman un tiempo y ésto debe ser tenido en cuenta a la hora de planear la transformación y dentro de los tiempos en los cuales se espera el retorno sobre la inversión que se esta llevando a cabo.


Pecado Número 6: No tener una columna vertebral para soportar agile

Con cierta frecuencia "Agile" se interpreta solamente como un enfoque para gestionar los proyectos, pero también es crítico tener en cuenta que la implementación del cambio requiere de una transformación de procesos de gestión y herramientas que utilizan los equipos. Los equipos ágiles necesitan poder implementar los activos tecnológicos con rapidez, por lo que disponer de una base de acceso y contar con recursos acelera la innovación y reduce el "time to market" que se espera alcanzar.

Pecado Número 7: No fusionar el cambio junto con el ADN de la organización

En agile hablamos a menudo de desarrollo iterativo. Si bien esto es algo natural para una start-up, que no tiene un producto establecido – por ende necesita probar y aprender a desarrollarlo –, es más complejo entenderlo para una organización con muchas líneas de productos ya introducidos en el mercado.

Es necesario asumir que el cambio forma parte del ADN de la organización y sus valores y que por tanto es un proceso que demanda tiempo, cambios en las formas de pensar, de operar y probablemente tendrá cambios en los procesos y en las herramientas que se emplean en el día de hoy y que necesitarán reformularse para poder brindar mejores experiencias a los clientes y dar respuesta a los cambios que el mercado está dando.

Autor : Ing. Javier Mauricio León Reyes

Twitter e instagram : @PMPMedellin

Fuentes consultadas:

https://forbes.es/business/44752/los-siete-pecados-capitales-de-la-transformacion-agile/

Fuente de la imagen:

Tomada de:   http://www.rtve.es/alacarta/videos/conexion-tdp/usain-bolt-jamas-podria-ganarle-carrera-guepardo/2195709/