SCRUM

23. oct., 2019

"La agilidad empresarial es la capacidad de una organización de adaptarse rápidamente a los cambios del mercado de manera tanto interna como externa".

En este proceso de adaptación surgen algunas situaciones que se vuelven obstáculos o barreras para que las compañías logren transformarse y meterse en el tren del cambio que está exigiendo el mundo de los negocios en la actualidad.

En este artículo vamos a mencionar algunos de estos obstáculos que tienen que superar las organizaciones en este camino:

1. El factor cultural es el principal obstáculo de la transformación digital y del ingreso de las organizaciones al mundo de la agilidad empresarial. Cerca de un 62% de las empresas corroborá esta idea según la firma Capgemini en un estudio realizado recientemente. Por otra parte Capgemini en el mismo estudio identifica que existe en muchas organizaciones una completa falta de sinfonía entre la alta dirección y los empleados en todas las áreas que comporta la cultura digital. Por ello en lo primero que se debe trabajar es en los aspectos de cultura y muchas veces estos son ignorados y/o no se les da la suficiente importancia.

Bill Gates afirma que “Para tener éxito hoy en día es necesario querer y ser capaz de reconsiderar, revitalizar, reaccionar y reinventar constantemente”. Esto solo es posible si se cuenta con una cultura orientada al cambio y que este centrada en las necesidades de los clientes.  

Otro de los inconvenientes que se encuentra en este punto, es que en muchos casos las empresas no consiguen que sus empleados participen en el viaje hacia el cambio de cultura corporativa. Implicar a los empleados es fundamental para inculcar una actitud digital efectiva y acelerar la transformación cultural de la organización. La alta dirección y los mandos intermedios son esenciales para traducir la visión digital en resultados tangibles y para incentivar las conductas digitales positivas. El experto Ian Rogers- Chief Digital Officer de LVMH, así lo explica: “El gran momento de una organización ocurre al aceptar que la transformación digital no es una cuestión meramente técnica, sino un cambio cultural”.

2. "Tomar Agile como moda". En definitiva como lo mencionabamos anteriormente no es una moda , sino en realidad constituye una necesidad porque el mundo esta dando giros vertiginosos y cada día con mayor rapidez. Estos cambios hacen que las organizaciones evolucionen y tengan que efectuar procesos de adaptación como resultado de las necesidades de sus clientes - Si quieres ver ejemplos de lo que pasa cuando no haces caso de estos cambios puedes ver empresas como Kodak, Blockbuster y recientemente Wework y Forever21 en algunos países de américa latina.

3.  La falta o disminución de presupuesto- esto está relacionado con la importancia que se le da al proceso de transformación por parte de los altos ejecutivos y por ello los equipos finalmente terminan también desmotivados cuando su presupuesto se ve afectado.

4. Tecnología muy antigua u obsoleta en planta. En realidad esto es un reto, porque al contar con equipos viejos y arquitecturas monolíticas que impiden el desacoplamiento hace más dificil el proceso de cambio. En estos casos es necesario revisar la posibilidad de efectuar un proceso de renovación tecnológica.

5. Incapacidad para determinar un retorno de inversión a partir de la transformación digital. Este punto es un caso de miopia empresarial que debe ser resuelto de manera pronta, porque todos los cambios se generan para dar solución a nuevos problemas y necesidades y los clientes obviamente si no ven resueltas las mismas optarán por productos y servicios de la competencia.

6. Falta de capacidades, habilidades y experiencia en el equipo. Este reto se le asigna a los agile coach y a los Scrum Másters dado que ellos deben facilitar que sus equipos aprendan y participar de la mano del product owner en la selección del personal idóneo para los proyectos a realizar.

7. Falta de visión y compromiso a nivel ejecutivo. Este punto está relacionado con el primer punto y es uno de los más díficiles de sortear por parte de los equipos, porque sin liderazgo los resultados que se pueden obtener no son muchos dado que de allí se derivan las reducciones de prespuesto, cambios de prioridad frecuentes, entre otros obstáculos.

8.Gestión ingenua de recursos:

En este punto, queremos decir que muchas veces se cree que agregar personas a un equipo hará que se aumente el progreso. Esto se veía mucho en la Gerencia de Proyectos Tradicional donde se decía que si una mujer daba a luz un niño en 9 meses, si colocabamos 9 mujeres embarazadas en un mes tendríamos el bebé. Y como esta paradoja se presenta - así ocurre lo mismo en los proyectos Scrum- Esto no es posible. 

El proceso con la asignación de personas no siempre tiene una relación directa, ya que depende de los niveles de capacitación y conocimiento del negocio de las personas que estas añadiendo a tu equipo. En ocasiones traer más personas puede por el contrario restar valor. Lo que se recomienda es agregar equipos y personas a tu proyecto si eres consciente de los recursos intangibles y su conocimiento, para que no frenes el progreso sino que lo impulses y se facilite el derrame de conocimiento al interior de los equipos.

9. Equipos organizados por componentes: Cuando los equipos se organizan por una sola función reducen la capacidad de la empresa para volver a priorizar sus capacidades, aumentan los cuellos de botella de coordinación e introducen riesgos de integración.

El enfoque del equipo de componentes sería eficiente si el desarrollo de nuevos productos fuera tan predecible como la fabricación. En la práctica, lo que ocurre en realidad es que las prioridades cambian y las estimaciones resultan incorrectas, por lo que es difícil obtener el enfoque adecuado de las personas para desarrollar capacidades que afectan a múltiples componentes.

Lo opuesto al equipo componente es el equipo característico. Un equipo de características abarca tanto componentes como disciplinas y, por lo tanto, es capaz de crear características de valor comercial en distintos segmentos y totalmente probados. El enfoque de equipo de características reemplaza el pensamiento de eficiencia del siglo pasado con un concepto de autonomía de equipo, propiedad y responsabilidad. La acumulación de productos de los equipos de características se basa en el valor comercial, no en la dependencia de la tecnología. Si aún vives con los diagramas de Gantt, es probable que todavía no tengas equipos de características.

La creación de equipos de características tiene un coste: los desarrolladores deben aprender nuevas habilidades, lo que inicialmente los ralentizará. Afortunadamente, la mayoría de los desarrolladores disfrutan aprendiendo nuevas habilidades. Las técnicas como la designación de un "tutor componente" técnico para cada área pueden ayudar a medida que los equipos aprenden. Al igual que con cualquier desarrollo escalado, la integración continua (pruebas automatizadas que se ejecutan con mayor frecuencia) es crucial para evitar fallos en pruebas de regresión.

Una vez que una organización ha dominado los equipos de características, un próximo paso podría ser los equipos de funciones de propósito general con afinidad reducida a las áreas de características. Si bien este paso puede tardar años, este siglo pertenecerá a la organización de aprendizaje.

10. Equipos organizados por especialización funcional: Cada equipo requiere una combinación de actividades de desarrollo. Se obtiene agilidad a través del análisis continuo de los requisitos, el diseño continuo, la integración continua y las pruebas continuas, todo lo que se alimenta mutuamente.

11. La distracción: Una organización típica desperdicia mucho dinero en el cambio innecesario de tareas. Esto quiere decir que los equipos carecen de enfoque y es por ello que toman meses en alcanzar una estabilidad. Los equipos deben llegar al estado de autogestión necesario para un alto rendimiento y calidad. Algunas personas se encuentran perpetuamente en múltiples rutas críticas al mismo tiempo, lo que limita gravemente la productividad total. Para una escala efectiva, estas personas deben convertirse en mentores en lugar de ejecutores de tareas. Para aumentar su influencia, deben renunciar a algún control.

Las prácticas de gestión tradicionales que refuerzan la especialización exacerbarán el problema. Cuando un gerente pasa esto por alto al asignar trabajo a un individuo, hay menos posibilidad de asesorar a otros en las habilidades críticas. Un grupo de personas que se están moviendo individualmente no participará en el aprendizaje colaborativo que se espera de un equipo. Las organizaciones profundizan en estos surcos cada día.

En los rangos más altos, los problemas de la multitarea, la distracción, la ansiedad y la incapacidad de ganar influencia al abandonar el control son aún peores.

La comunicación lateral efectiva entre los equipos ayuda a los propietarios a concentrarse con calma en las responsabilidades, como priorizar el trabajo y ser el árbitro final de los requisitos.

12. Renuncia a priorizar: En el desarrollo de productos, el nuevo descubrimiento es el objetivo. Para gestionar esta realidad, el product owner debe llevar a cabo una reunión de refinamiento del portafolio de productos con el equipo en cada carrera. A medida que surgen grandes elementos del portafolio de productos, encuentra los aspectos de alto valor de ellos y divírlos en elementos más pequeños separados (generalmente "historias de usuario"). El product owner  del producto controla el alcance al decidir qué elementos encajarán en la proyección de lanzamiento, dadas las tendencias históricas de descubrimiento y de alcance.

13.Deuda técnica : Los problemas de administración de una organización son finalmente visibles en el código fuente. Esta "deuda técnica" causa problemas de producción y un alto coste de cambio. Idealmente, las pruebas de regresión se automatizan utilizando el mismo lenguaje de programación que nuestro código de producción, en lugar de herramientas propias que refuerzan la especialización. En el siglo XXI, se esperarán habilidades de ingeniería de cualquier desarrollador. Los equipos que inicialmente no tienen estas habilidades deben intentarlo hasta que las hayan aprendido.

14. Falta de compromiso con la transformación: Se requiere coraje, imaginación y apoyo de la gerencia. Muy pocos prestan la debida atención, y la administración a menudo no apoya a quienes lo hacen.

Como vemos hay muchos retos por superar  en este proceso de transformación y son múltiples las situaciones que se presentan, alguna por ignorancia, algunas por malas prácticas y otras situaciones por la misma forma como están conformadas las organizaciones en el hoy que no están preparadas para éste cambio. Sin embargo, lo importante es tener consciencia de que es algo inminente y que debemos afrontar de la mejor manera. Así que debemos estar dispuestos a aprender, a desaprender y sobre todo tener la mente abierta a que la cultura que se tiene hoy no será la misma del mañana, las necesidades de nuestro cliente cambian y nosotros debemos colocarlo en un lugar céntrico por ello debemos cambiar a su ritmo.  

Si te gustó este artículo no dudes en compartirlo con amigos, colegas y familiares. PMPMedellin contribuye cada día con llevarte nuevos conocimientos y contenidos actualizados.

Autor: Ing. Javier Mauricio León Reyes

Twitter e Instagram: @PMPMedellin

Fuente de la imagen:

https://arbolabc.com/imagenes-de-animales/guepardo

Fuentes consultadas:

22. oct., 2019

¿ Qué es la Deuda Técnica?

El concepto de deuda técnica no es un concepto fácil de explicar, dado que es algo intangible. Es decir, es algo que no se ve, pero que se sabe que está allí presente, acumulándose y evolucionando para convertirse en un problema que puede desencadenar reprocesos, sobrecostos, atrasos y problemas en el equipo de desarrollo de un proyecto Scrum.

De donde tomó su nombre la "Deuda Técnica" ?

El término surgío de la analogía utilizada por Ward Cunningham, en el año de 1992. Él comparó un desarrollo de software que presenta carencias a nivel técnico por entregarlo de manera temprana, con la petición de un crédito financiero.

Así como el crédito permite obtener liquidez a corto plazo, a costa de generar unos intereses a liquidar en un período de tiempo prolongado, las carencias en el desarrollo de software nos dan un entregable a corto plazo, pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado, sumando un esfuerzo extra - que son los intereses. Entonces las carencias de calidad en el desarrollo de software generan una deuda técnica igual a los intereses que genera un crédito bancario.

Origen de la Deuda Técnica

Ahora bien, la deuda técnica tiene 2 orígenes según menciona el  autor Steve McConnell:

  • Deuda añadida de forma involuntaria debida a trabajos de baja o poca calidad. Se atribuye normalmente al desconocimiento del equipo.
  • Deuda añadida intencionadamente para recortar tiempos haciendo las cosas mal. Se atribuye a un bajo sentido de la responsabilidad o de visión a largo plazo del equipo.

Principales causas de la deuda técnica en Scrum:

1. Definición previa insuficiente, este punto se le puede asignar a una mala labor del product owner.

2. La principal causa de la deuda técnica son las presiones en fecha y planes que impone el Negocio y los sponsors. En muchos casos, el equipo de desarrollo toma “atajos” para poder llegar a cumplir su compromiso dentro del plazo(Sprint).

3. Falta de colaboración: No compartir conocimientos hace que el software desarrollado no sea de calidad.

4. Falta de documentación: Por no disponer de tiempo se puede perder una forma común de desarrollar.

5. Falta de comprensión: Si la organización no conoce el concepto de deuda técnica, no podrá conocer las consecuencias de desarrollar un software de mala calidad.

6. Falta de procesos o entendimiento.

7. Componentes fuertemente acoplados. Es por ello que se propone con Scrum el uso de algunos patrones de diseño , arquitectura y de desarrollo que facilitan el desacoplamiento del código.

8. Baterías de pruebas incompletas. Un mal proceso de testing puede desencadenar deuda técnica porque los errores ingresarían al product Backlog como HU para ser implementadas.

9. Posponer procesos de refactorización.

10. liderazgo técnico pobre.

11. cambios en las especificaciones a última hora.

Y ¿ Cómo gestionamos la Deuda Técnica?

No debemos perder de vista que Scrum se basa en tres pilares: Transparencia, inspección y adaptabilidad. Estos pilares deben estar presentes en cada sprint del proyecto dentro del equipo del proyecto. Por ende tendremos el control sobre la deuda técnica y sus consecuencias si seguimos estos sencillos consejos:

1. Aprovechar al máximo la reunión Daily Meeting: Cada día el equipo de desarrollo puede detectar de manera rápida los posibles errores que se van presentando y tomar decisiones sobre su solución de forma individual o en conjuntos de errores para evitar problemas de calidad en el software.

2. Incluir dentro de las estimaciones HU y tareas (así como en la planeción) que sean relevantes como testing,  documentación y refactorización.

3. En caso de que sospeches que hay deuda técnica, utilizar futuros Sprints para refactorizar y no seguir heredando problemas en el desarrollo del software. "Recuerda que al mal tiempo darle prisa".

4. Involucrar a la organización. La mejor manera de hacer entender a los directivos es con hechos y datos. Estimar las horas extras que se necesitan en caso de que haya deuda técnica y llevar esas horas a dinero ya que normalmente ellos entienden mejor cuando se habla de  beneficios o pérdidas económicas.

5. Involucrar al scrum Máster : El SM es quien se encargará de evitar la deuda técnica y defenderá al equipo de eventos o fechas que puedan dañar la calidad de los entregables.

6. Cuidar el DOD - Definition of Done,  cualquier factor que elimine la deuda técnica debe estar incluído y nunca olvidar que el DOD debe estar siempre actualizado.

7. Si dentro de tu quehacer diario encuentras código que necesite ser refactorizado, documenta la situación para que éste la evidencia de esta deuda técnica. Este papel deberá ser tenido presente en la planning para ser estimado.

8. El equipo nunca debe trabajar en una funcionalidad que tenga deuda técnica sin solucionarla, esto porque se añadiria deuda sobre la deuda ya generada.

9. La decisión de realizar una nueva funcionalidad de una Historia de Usuario  y/o pagar deuda técnica no es responsabilidad del equipo de desarrollo , debe ser binaria con el Product Owner.

Esperamos que esta información haya sido útil para tí y tu equipo. Si te gustó el artículo compártelo con tus colegas, familiares y amigos que trabajen en proyectos de TI o de ingeniería y con metodologías de trabajo ágiles.

Autor: Ing.Javier Mauricio León Reyes

Twitter e Instagram: @PMPMedellin

Fuentes consultadas: 

http://scrumizate.com/post/61/cmo-luchar-contra-la-deuda-tcnica

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