ES/EN

Solo un par de segundos…

Factor 1: La agilidad está basada en la Excelencia Técnica

J. González

14 minutos de lectura

Comparta este artículo

La agilidad, esa panacea que todos quieren pero que pocos encuentran. Algunos lo logran, pero no están dispuestos a pagar el precio. Al final la mayoría se conforma con usar Jira y escalar sin importar los resultados.

Vamos a iniciar una serie de blogs sobre porque la agilidad falla o en general porque se ven tan pocos resultados en las organizaciones. Los factores son variados, desde la excelencia técnica, las certificaciones y hasta al liderazgo. Vamos a ir desgranando los factores, que la experiencia nos dice, son los más relevantes y tienen mayor impacto en la agilidad de las organizaciones y los resultados tan mediocres que se obtienen. 

Veamos el siguiente escenario y exploremos el primer factor que afecta la agilidad en las organizaciones: La excelencia técnica.

solucionando en el camino

Son las 8 de la mañana de un día cualquiera, en una organización típica. El día anterior se completó un cambio relevante que el negocio esperaba con ansias. El equipo se dispone a hacer sus eventos y planificar el siguiente Sprint. A las 8:10 am llega un reporte de un caso de un cliente que no puede llevar a cabo una transacción. Los niveles estándar de soporte comienzan la revisión. A las 9:00 am el equipo ya ha iniciado su Sprint Planning y están discutiendo las historias del Product Backlog que van a tomar para el siguiente Sprint. A las 9:05 el Product Owner y varios miembros del equipo reciben notificaciones de varios casos en producción que impiden a los clientes llevar a cabo una transacción. El Producto Owner recibe una llamada de su jefe y le dice que deben revisar con carácter de urgencia el caso, dado que hay muchas llamadas y reportes. Igualmente, personal de operaciones y producción ha decidido utilizar el sitio alterno, sin el cambio, para evitar un impacto mayor. Luego del altercado y una revisión preliminar del equipo, encuentran el problema en el cambio del día anterior. Un caso de uso que no habían considerado o pensaron que no tenía relación. El Sprint Planning se convierte en una sesión de entendimiento y se replantea todo el siguiente Sprint para entender el problema y desarrollar la solución.

Este es un escenario hipotético de lo que sucede un día si y otro también en diferentes organizaciones que trabajan con equipos y “agilidad”. En muchas ocasiones los Sprints se ven replanteados o cancelados, producto de trabajo emergente y urgente que aparece constantemente. En ocasiones, si el problema se vuelve recurrente, se crea un equipo específico para atender este soporte e intentar que los otros equipos puedan seguir desarrollando y creando valor.

Pero en el fondo, ¿por qué se da esta situación?, ¿por qué a pesar de que estamos trabajando con agilidad esto sigue sucediendo? La respuesta corta es: por falta de excelencia técnica.

Entonces ¿qué es la excelencia técnica? El concepto como tal es bastante amplio, pero revisemos algunos aspectos que deberíamos considerar.

Habilidades Técnicas

aprendizaje continuo

Las personas deben tener el suficiente conocimiento técnico para llevar a cabo su trabajo. Para todos es evidente lo rápido que avanza la tecnología y como esta se ha convertido en un motor de innovación para las organizaciones. Entonces debemos imaginarnos que las personas que están en la organización para implementar o adoptar estas tecnologías también necesitarán mantenerse al día con las tecnologías para entregar valor al cliente. Por ejemplo, Java tiene una versión nueva de su JDK cada dos años. Si hablamos de arquitecturas de microservicios vemos que aplicaciones como Docker surgió en 2013 y Kubernetes en 2014, es decir, hace menos de diez años. CSS4 tiene especificaciones de módulos que se terminaron en 2018 y algunas apenas se terminaron el año pasado. Y así podríamos seguir viendo ejemplos de tecnologías que siguen evolucionando. La pregunta es: ¿Como su organización se asegura que las personas se mantengan actualizadas y al día con estas tecnologías y su uso adecuado? 

Gran parte de ser ágil tiene que ver con las personas, su capacidad de aprender y evolucionar rápidamente. No es fácil mantener el ritmo de evolución de muchas de las tecnologías que se usan actualmente, pero no hacerlo significaría que pronto la organización tendría problemas para entregar el valor que se requiere. Se generaría un efecto en cadena en donde el time-to-market y la deuda técnica aumentarían y en el largo plazo cada cambio sería más costoso y tomaría tanto tiempo que las aplicaciones quedarían en obsolescencia. Mantener estas aplicaciones significa que la agilidad no sería posible, sin importar, las prácticas, frameworks o certificaciones que las personas tengan.

Para propiciar las habilidades técnicas puede tomar en cuenta estas recomendaciones:

  • Plan de capacitación permanente para el personal técnica(developers): Las capacitaciones deben darse justo a tiempo, si se reciben antes de entender las necesidades en la organización se pierden y si se dan muy tarde se corre el riesgo de generar un aumento importante en la deuda técnica.
  • Técnicas de desarrollo colaborativas: Este punto lo desarrollamos más delante. 
  • Promover el aprendizaje continuo en las personas.
  • Incentivar a las personas a actuar con profesionalismo y excelencia técnica.

Hiper-especializacion

deep knowledge

A las personas les encanta dedicarse solo a una cosa o tema. La hiper-especialización es la idea que promueve que cada persona solo conozca y haga una cosa, asumiendo por lo tanto que esa especialización significará una mayor productividad. En general las especializaciones no tienen nada de malo. Sin embargo, la especialización de una persona puede verse como una optimización local, mientras que la agilidad busca una optimización que cruce las barreras de la organización. De ahí la importancia que, además de su especialización, las personas estén dispuestas a aprender una o dos habilidades adicionales.

No necesariamente de manera profunda o tan especializada, pero si lo suficiente para darle al equipo la mayor flexibilidad posible. Cuando en los equipos tenemos personas muy especializadas y que no quieren o pueden hacer otra cosa tendemos a buscarles trabajo que hacer, sin importar si ese trabajo aporta valor o está alineado con los objetivos del equipo. Es decir, la excelencia técnica significa que como personas tenemos la habilidad de aportar en diferentes campos en diferentes niveles de especialización. No significa que todas las personas en el equipo deban poder hacer de todo, pero tampoco que solo puede hacer una cosa. En el medio de estos dos extremos está el estado que buscamos para el equipo.

Lograr que las personas aprendan de otros campos fuera de su especialidad es algo que el mismo equipo puede lograr. Una de las formas más efectivas de hacerlo es a través de algunas practicas de desarrollo como pair-programming o mobbing.

Para evitar que la hiper-especialización se convierta en un problema tome en cuenta estas recomendaciones:

  • Promueva la figura T (T-shaped) en todo el personal. De incentivos a aquellos que aprenden una nueva habilidad dentro del equipo.
  • Promueva el aprendizaje continuo y a aquellas personas que están dispuestas a enseñar de su especialidad.
  • Introduzca prácticas de desarrollo colaborativas.

Prácticas de Desarrollo Colaborativas

trabajo en equipo

Una de las formas más efectivas para promover la excelencia técnica en los equipos es adoptar prácticas de desarrollo colaborativas. No solo mejoran la calidad de los productos, si no, que además promueven el aprendizaje continuo.

Dos de las técnicas de desarrollo colaborativo que tienden a dar mejores resultados son el Pair-Programming y el Mobbing.

El pair-programming o programación en pares o parejas no es algo nuevo. Básicamente se trata de desarrollar una solución entre dos personas al mismo tiempo en una computadora, por ejemplo, una digita código mientras la otra solo la ve, a una persona le dicta el código y otra digita, etc. Las personas cambian constantemente de rol. En general esta técnica permite compartir conocimiento, mejora la calidad y en general disminuye el tiempo de entrega, aunque signifique más horas-persona.

El mob-programming o mobbing es similar solo que en esta técnica no solo dos personas participan, si no, que lo hace todo el equipo. Es decir, todo el equipo, al mismo tiempo, con el mismo código y la misma computadora. Constantemente cambian de rol y no solo pueden realizar programación, también se aplica para cualquier otro trabajo que el equipo necesite hacer, como documentación, pruebas, despliegues etc.

Para muchas organizaciones estas técnicas no son adecuadas. Tienen todavía el pensamiento tradicional de optimizar las horas-persona y no la entrega de valor. Prefieren tomarse uno o dos Sprint de “estabilización”, en lugar de intentar alguna de estas técnicas y mejorar la calidad.

La principal recomendación en este aspecto es abrir la ventana de oportunidad para que el equipo pueda experimentar con estas técnicas en un ambiente seguro. Donde pueda adaptarse y fallar mientras estabiliza y aprende la nueva forma de trabajo.

Sin estas técnicas es difícil que los equipo y organizaciones logren los beneficios de la agilidad.

Estrategias de Desarrollo

test driven development

Es sorprendente que muchas organizaciones que se dicen ágiles no usan técnicas de desarrollo como el desarrollo orientado a pruebas (TDD). TDD básicamente consiste en:

  • Escribir primero el código de una prueba. 
  • Ejecutar la prueba y que falle. Aún no hemos implementado el código con la solución.
  • Luego escribir el código con la solución.
  • Volver a ejecutar la prueba y corregir el código de la solución si esta falla.
  • Refactorizar el código para hacerlo más eficiente, estándar, simple, etc.
  • Repetir los pasos anteriores.

Es fácil entender que para muchos desarrolladores crear pruebas antes de la solución es algo difícil. Alrededor de un 40% indica que es difícil de aprender y practicar (https://collaboration.csc.ncsu.edu/laurie/Papers/TDDpaperv8.pdf). Además, la mayor parte de la administración de las organizaciones no entienden el beneficio y si a esto le sumamos que aplicar TDD representa una inversión, cuyos frutos tardan alrededor de dos años en verse podemos entender las razones por las cuales esta técnica es descartada.

Sin embargo, el mismo estudió encontró entre un 40% y un 90% en la disminución de errores antes de las liberaciones(releases) cuando se usa TDD. Otro beneficio de usar TDD es que el diseño general de las soluciones se vuelve más sencillo y efectivo.

Entonces, en resumen, podemos decir que la falta de visión de las administraciones de las organizaciones, la dificultad inicial de adopción y el tiempo necesario para ver resultados hacen que la mayoría de las organizaciones no utilicen una técnica como TDD.

Esto dificulta la automatización de pruebas, la cultura de calidad y refactorización y al final de cuentas el time-to-market y la agilidad como un todo.

La recomendación es sencilla, la organización debe adoptar y practicar TDD hasta que ya no duela hacerlo.

Automatización

automatización

Hoy en día la automatización ha avanzado a pasos agigantados. Muchas de las labores mecánicas o repetitivas ya pueden ser fácilmente automatizadas por los equipos. Esto les permite tener más tiempo y enfoque en la entrega de valor y al mismo tiempo pueden aplicar las técnicas descritas anteriormente.

Pretender que una organización logré agilidad de negocio sin automatización, es como querer conducir un carro sin gasolina. La famosa promesa del doble de trabajo en la mitad del tiempo no se puede lograr sin implementar conceptos como DevSecOps. La constante refactorización del código necesita igualmente de constantes pruebas. La entrega de valor de los equipos debe ser lo más cercana al usuario y sin sistemas automatizados que lleven los cambios hasta las manos de estos usuarios, estaremos lejos de lograr agilidad.

La excelencia técnica significa que estas capacidades están establecidas y son constantemente mejoradas. Entre menos procesos manuales existan, menos posibilidades de errores humanos, más calidad y mejor time-to-market.

Podemos mencionar o identificar otras prácticas que apoyen la excelencia técnica, pero en general ya tiene una idea de lo que se busca y requiere para alcanzarla. También es importante recalcar, una vez más, que sin excelencia técnica la agilidad no será posible y por lo tanto debe ser un imperativo en la búsqueda de la agilidad empresarial.

¿Qué le pareció
este contenido?

Una respuesta

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Suscríbase para potenciar su conocimiento

Este sitio utiliza cookies

Utilizamos cookies para personalizar el contenido y los códigos, mejorar la usabilidad, proporcionar funciones de redes sociales y analizar nuestro tráfico. También compartimos información sobre su uso de nuestro sitio con socios de redes sociales, publicidad y análisis, que pueden combinarla con otra información que les haya proporcionado o que hayan recopilado del uso que haga de sus servicios. Usted acepta nuestras cookies si continúa en nuestro sitio web.
ES/EN