Por muchos años me han hecho la misma pregunta una y otra vez, la cual radica en si las empresas de Latino América y España tienen las mismas características a la hora de comenzar a usar Agile con respecto a las anglosajonas. Por fin he decidido hacerme un poco de tiempo estas dos semanas que me encuentro en España dando formación para tratar de mostrarte 7 de las características que podrían marcar una diferencia importante al implementar las técnicas. Por supuesto que lo que te describiré no es parte de un estudio científico pero sí está avalado por mis años de experiencia, lo que verás a su vez tiene sentido común y puede ser aplicado directamente en la mayor parte de los casos.
Es importante que comprendas primero la situación particular de tu empresa y analices si se podrían dar más de uno de los puntos detallados a continuación:
1. Jerarquías bien definidas
El primer inconveniente que encuentro en Latino América y España es que las compañías cuentan en general con una estructura jerárquica más fuerte, la que tiene varios efectos secundarios a la hora de implementar Agile. La diferencia se ha analizado por varios expertos y pienso que podría ser debido a las distintas características de revolución que han existido en la historia entre Latino América/España y su contraparte anglosajona (revolución gloriosa en Reino Unido, USA, etc), lo que marcó la forma en cómo las sociedades han sido estructuradas. Sin irnos de tema, una investigación realizada por Conway demuestra que la estructura jerárquica de la empresa incide directamente en el código escrito.
«Ley de Conway: La estructura de una Organización se refleja en el código escrito.»
La estructura de organización jerárquica tradicional impactará en la estructura de forma negativa, resultando en código poco claro, mala arquitectura, mantenibilidad y adaptabilidad pobre así como costos elevados y fallas frecuentes. Esto es, en compañías con jerarquías más estrictas el código orientado a objetos será menos óptimo y flexible, lo cual aumentará a su vez la cantidad de fallos y los tiempos desde la idea del cliente hasta su concepción final. Por otro lado la llamada «Deuda técnica» o de diseño/código (todo aquello que deberías hacer pero podrías dilatar para más adelante) es muchas veces omitida, lo que hace que finalmente se enlentezca aún más el proceso de programación y se desmotive a los miembros de los equipos ya que, en muchas generalmente, el trabajo se hace más duro y el riesgo se aumenta.
«Deuda técnica (también conocida como deuda de código o diseño) es una metáfora que se refiere a las consecuencias eventuales de la evolución pobre de arquitectura de software o desarrollo de código»
La relación con los clientes o Propietario del producto también es estructurada de forma jerárquica, lo que conlleva a que los miembros del equipo tengan muchas veces dudas sobre si plantear la necesidad de realizar ciertas tareas de mantenimiento interno por miedo a reprimendas.
Imagínate que el Dueño del producto sugiere un cambio en una base de datos que traerá consigo la necesidad casi obligatoria de optimizar otras áreas del producto o de lo contrario se hará más difícil escribir código en el futuro cercano. Ésta charla podría no ocurrir ya que en muchas ocasiones el último es visto como jefe, lo que dará como resultado que las tareas adicionales no sean llevadas adelante.
Si no hay coraje para hacer lo que se piensa, lo que normalmente es correcto será lo que no se hace.
SOLUCIÓN: Tu eres un profesional
En principio cada individuo que trabaja en sistemas, tanto provenga de una universidad o haya efectuado su formación en la empresa, debería considerarse a sí mismo como un profesional y actuar de acuerdo a ello. Imagínate un doctor dilatando la decisión de indicarle a un paciente el tomar cierta medicación por miedo a lo que pensará de sus efectos secundarios o un arquitecto prorrogando modificaciones en un puente porque luego del estudio de viabilidad se comprobó que hay que adicionar dos nuevos pilares. Obviamente éste tipo de situaciones no ocurre en dichos ámbitos ya que ambos se consideran profesionales.
Ante la duda, actúa profesionalmente siempre informando sobre tu opinión basada en tu experiencia y asegúrate que las personas sean comunicadas y los posibles problemas se hagan visibles, tanto en medios informáticos como en papel (colocando tarjetas o pancartas en las paredes que recuerden los problemas acarreados).
2. Disponibilidad de ofertas de trabajo
En algunos mercados donde el mercado no ofrece muchas oportunidades a nivel laboral o se encuentra en recesión (como es el caso actual de España), los miembros del equipo pueden temer por sus puestos de trabajo. Debido a ello, comienza un círculo vicioso que es muy peligroso para la empresa, el cual se caracteriza por que los empleados no sugieren nuevas ideas o soluciones debido al miedo mayoritariamente irracional de la pérdida del puesto de trabajo. Esto hace que la empresa comience un ciclo de no-innovación en que hunde más a la misma.
SOLUCIÓN: Reafirma la innovación y ofrece un ambiente seguro
La empresa desde el ámbito gerencial deberá ofrecer un ambiente de trabajo que integre de forma implícita los medios para que las sugerencias de nuevas ideas -incluso de aquellas vistas como radicales- sean siempre bienvenidas y canalizadas por un canal que acepte la evaluación dentro de un marco de trabajo que demuestre seguridad y positivismo hacia ellas. Ello asegurará a la compañía innovación y detener automáticamente el circulo vicioso de degradación.
3. Creencias sobre la organización… (La creencia del León)
En muchas ocasiones los empleados tienen la creencia de que no pueden realizar cambios a la estructura o las opiniones serán valoradas. Esto es como la creencia del León, el cual es el rey de la selva en teoría, pero en realidad éste nunca vivió alli. Las creencias pueden ser tan fuertes que los miembros de un equipo pueden seguir indicaciones de forma ciega y sin cuestionar el porqué.
Recuerdo todavía una de las empresas en las que trabajé en donde era necesario enviar un email a una dirección no monitoreada y copiar el mismo a una carpeta de la red con la lista de las Historias de usuario finalizadas. Este proceso que parecía obvio para todos, no tenía sentido alguno y no ofrecía valor de negocio alguno, pero era efectuado de forma casi automática.
SOLUCIÓN: Fomenta la crítica
Fomenta que los miembros de la empresa critiquen los procesos de forma positiva, esto es, preguntando porqué eso está allí, reviendo el valor de negocio y ofreciendo soluciones. Para que esto pase se deberá siempre ofrecer un marco de trabajo informal y estructurado en donde los empleados se sientan confortables y se cuente con una política activa de mejora de procesos activa (como podría ser LEAN).
4. El efecto del paquete cerrado
En los mercados anglosajones cuando ciertas técnicas (como ser Agile) se implementan en la empresa, ella se adapta de acuerdo a las necesidades. El problema que existe en muchas compañías de habla hispana es que la mayor parte de las técnicas con ideas que provienen de mercados más grandes se toman como un paquete cerrado, el que deberá ser seguido de forma estricta. Esto hace que no exista un crecimiento real o crítica y adecuación (inspeccionar y adecuar) lo que deriva muchas veces en el fracaso institucional.
SOLUCIÓN: Piensa en los procesos de forma proactiva
Criticar todo aquello que se implemente una vez visto sus resultados, analizar si existen casos similares en empresas del exterior y rever aquellas medidas tomadas, así como también evaluar las posibles modificaciones siempre y cuando se lleven adelante empleando un modelo empírico (probar y ver los resultados para luego tomar decisiones, así como también compararlos constantemente con el mercado internacional).
5. Formas de expresión diferentes
Los hispanoparlantes suelen comunicarse verbalmente en formas que pueden ser vistas muchas veces como no tan organizadas y alborotadas en comparación con su contraparte anglosajona. Esto que resulta no tan obvio, puede degradar rápidamente la comunicación y hacer que los individuos más tímidos no tengan la ocasión de expresar sus ideas u opinión.
SOLUCIÓN: Asegúrate todos tienen voz
Es aquí que a mi criterio se deberían emplear mapas de interacción (ver artículo sobre Retrospectiva en Agile) y asegurarse que la comunicación entre miembros del equipo y otras partes sea organizada y efectiva. De ser un problema, el Scrum Master o cualquier otra persona en la empresa debería ser capaz de poder identificar y sugerir los cambios necesarios para mejorar la comunicación y efectividad de los mismos.
6. Documentación y traducciones al Español
Muchos años atrás colaboré con la traducción de varios libros técnicos para el mercado hispanoparlante. El problema surge en que aquellos de lenguajes o infraestructura son siempre puntuales y lo que se dice puede ser verificado en todos los casos con el código. Cuando hablamos de metodologías Agile, esto es diferente ya que mayoritariamente involucra gente y procesos. Es así que la diferencia entre una traducción empleada y otra puede dar como resultado una diferencia abismal, cosa que podría ser totalmente captada por el lector, aplicándose posteriormente la idea de forma incorrecta.
SOLUCIÓN: Coteja varias fuentes
Verifica los conceptos con otras fuentes de forma explícita y asegúrate que los mismos son similares a los que se aplican en otros lugares. A su vez, las compañías deberían en mi opinión emplear un «Coach» por el primera año Agile para que de esta forma se puedan “tirar” de las cuerdas correctas sin la necesidad de correr el riesgo de una mala interpretación.
7. Agile mal aplicado
En Uruguay he visto por ejemplo que muchas empresas no emplean Agile por considerarlo como técnicas para proyectos pequeños. Esto es así ya que hace varios años atrás se intentó implementar Agile de forma incorrecta, lo que dio como resultado dicha creencia.
SOLUCIÓN: Analiza seriamente los motivos
Verifica que los mitos y restricciones sean reales y trata de analizar seriamente los motivos de fondo de ellos. ¿Es una restricción institucional? ¿Se han seguido todos los pasos sugeridos o han omitido por creerlos no necesarios? En principio te sugeriría que la empresa siguiese estrictamente todos los pasos sugeridos así como se sometiese a retrospectivas regulares para inspeccionar y mejorar los procesos sobre bases ciertas. Planes de acciones definidos y pruebas empíricas deberían ser empleadas constantemente y como práctica habitual.
Si quieres recibir mis novedades y artículos haz clic en la pestaña SEGUIR de abajo a la derecha; también te podría interesar alguno de mis otros artículos…
10 reglas de oro para medir un proyecto Agile
Descubriendo los problemas de equipos Agile
Resultados de 7ma. encuesta anual del estado de Ágil
Psicología profunda de las retrospectivas Ágil
6 problemas típicos en retrospectivas Ágil
¿Gastar en tecnología o metodologías de gestión de proyecto?
¿Cuándo utilizo Ágil? La respuesta que estabas esperando…
¿Qué hacemos con los recursos humanos en Ágil?
Agilidad y la verdad contundente sobre programación en parejas
Resistencia institucional y cambio hacia Agile (Parte 1)
Resistencia institucional y cambio hacia Agile (Parte 2)
Las 15 preguntas antes de implementar Ágil/Scrum en la empresa
