¿Gastar en tecnología o metodologías de gestión de proyectos?

Hoy justamente hablaba con una empresa en Uruguay sobre la implementación de cursos de metodología Agile para capacitar a sus jefes de proyecto. Durante la conversación me comentaban que normalmente no capacitaban a estos últimos pero sí inviertían en nuevas tecnologías.
Ésta es una característica que he visto en varios lugares en Latino América donde se asume que tan pronto como la rueda gire, entonces no hay necesidad de cambio; y por supuesto que es una opción parcialmente válida. Cuando has utilizado una forma de trabajo por un tiempo, se tiene la percepción que  ese círculo de confort es la opción más correcta, lo que da como resultado una inercia institucional en donde muchas compañías solamente pueden ser expulsadas la trayectoria si la competencia comienza a emplear técnicas más efectivas.

Por ello siempre digo cuando todo lo que tienes es un martillo, todo a tu alrededor se ve como un clavo 😉

Quizá sea también la finalización inminente del «status quo» (o estado de confort) como indicaba Satir hacia uno de cambio (y consecuente «caos»), pero ello estará por verse…

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

Implementar Ágil en paises hispanoparlantes vs. anglosajones

Resultados de 7ma. encuesta anual del estado de Ágil

Psicología profunda de las retrospectivas Ágil

6 problemas típicos en retrospectivas Ágil

¿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)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

¿Cuándo utilizo Agile? La respuesta que estabas esperando

He escuchado ésto una y otra vez a lo largo de los años y espero aquí responder la pregunta del millón o por lo menos darte una orientación firme. En entradas anteriores te hablé sobre la importancia que tiene en el software la forma y el caudal de los requerimientos a la hora de analizar la posibilidad de utilizar las metodologías Agile/Scrum o seguir con los métodos tradicionales. Ahora te demostraré porqué…

Sistemas con requerimientos estables
En un sistema donde los requerimientos son efectivamente estables (como ser quizá una aplicación bancaria), el emplear los métodos tradicionales es una buena idea. No obstante, hay que tener en cuenta que la percepción sobre estabilidad puede ser errónea ya que el sistema se clasificaría como  estable pero quizá un elemento externo (la competencia) podría inesperadamente forzar a un cambo de rumbo (nuevo producto lanzado al mercado, etc). De acuerdo con la ley de Ziv’s, el desarrollo de software no es predecible.

«Ley de Ziv: el desarrollo de software no es predecible»

Por el otro lado, el sistema puede parecer estable pero el cliente no realmente conocer lo que quiere y la única forma de confirmar lo que finalmente desea es mostrándole la aplicación funcionando.

«Ley de Humphrey: el cliente no sabe lo que desea hasta que no lo vea implementado y funcionando en una aplicación»

La ley de Humphrey dice que «El cliente no sabe lo que desea hasta que no lo vea implementado y funcionando en una aplicación»; cosa que parece ser sistemáticamente ignorada cuando nos enseñan en la Universidad y por la mayor parte de los jefes de proyecto. Piensa por un segundo… ¿Cuantos de tus trabajos se han llevado acabo exactamente de la forma estipulada?

Si finalmente sorteamos estos dos obstáculos de forma positiva, hay un tercer factor a tener en cuenta… la estructura de la empresa.

La estructura de la empresa y su impacto
Uno de los problemas no incluidos a la hora de estimar un proyecto de software es lo que se expresa mediante la ley de Conway. Ésta indica que la estructura de la organización está reflejada en el código; sería algo así como ignorar que tu personalidad influirá en tu relación amorosa.

«Ley de Conway: La estructura de la organización se refleja en el código»

Una jerarquía de empresa poco flexible impactará negativamente en el diseño orientado a objetos, resultando en fuentes más rígidos y poco resistentes a los cambios.
Por otro lado, el ser poco flexible implica que se darían casos de «ellos y nosotros», sistema aplicado históricamente por muchas empresas para responsabilizar a una persona en vez de aprender proactivamente sobre el error. Esto último evidentemente crea problemas en el resto de la organización y es un ejemplo claro donde forzar el uso de las metodologías Agile sin un cambio de pensamiento puede causar un dolor de cabeza.

Metodologías Agile como visión global
Cuando finalmente encontramos una salida a los temas anteriores, tendremos que focalizarnos en que las metodologías Agile sean realmente comprendidas por la totalidad de los individuos en la empresa y no solamente seguidas por mandato divino, esto es, todos desde desarrollo, pasando por la parte gerencial, ventas, etc conocen los beneficios y trabajan proactivamente con una meta común empleando las reglas de transparencia,  confianza mutua y respeto por las personas. Todo el mundo en la empresa debe ser re-educado a la nueva filosofía y optimizar los procesos de forma constante, inspeccionando y adaptando cada vez que se encuentre un problema, o lo que es igual, aprendiendo efectivamente y brindando los resultados a los colegas para un cambio real.
La visión del producto y las reglas de trabajo tienen que ser claras, no se deben contar con políticas que obstruyan a los individuos de ser productivos así como se debe embarcar en un proceso de comprensión y cuestionamiento positivo de los problemas .

«Los valores Agile nos guiarán en tiempos de poca claridad y ambiguedad y nos harán sustentar porqué hacemos algo de una forma determinada»

Los 4 tipos de proyecto
Finalmente me gusta inculcar a las personas que asisten a mis seminarios  la idea que ha sido plasmada en el libro «Strategic Management and Organisational Dynamics, segunda edición» de Ralph Stacey.

Image

En ella se indica que los proyectos pueden ser clasificados en 4 ramas:

1. Simples
2. Complicados
3. Complejos
4. Anárquicos

Los simples son aquellos que están llenos de cosas conocidas, esto es, sumamante parecidos a muchos que hemos realizado anteriormente, sabemos exáctamente que se necesita, conocemos las herramientas y el funcionamiento de la relación con los clientes.
Tan pronto como nos alejamos de la zona de confort, los requerimientos, la tecnología o ambos dejan poco a poco de ser conocidas, lo que agrega inestabilidad al sistema. Quizá no conocemos alguna de las herramientas o los usuarios no tienen claro lo que efectivamente desean. Ello hace que los proyectos sean mas difíciles de predecir y estimar.
Sin llegamos al tipo de «Complicados», tendremos más y más agujeros negros, donde no sabremos las respuestas y trataremos de adivinarlas (gracias a nuestro ego y… ¡Asumiento que las respuestas son correctas por supuesto!). Quizá sea una tecnología que no utilizamos anteriormente en nuestros equipos o desconcemos el área de producto. Al llegar al 4to tipo (Anárquico), éste contendrá cientos de dudas.

«Cuando las compañías se encuentran en el modelo de proyectos anárquicos, deberían centrarse en solucionar primero los problemas que la pusieron en este estado en vez de comenzar a construir un sistema de software»

Ésto nos demuestra que en cualquier lugar donde se esté a excepción del «Simple», se tendrán cientos de cambios durante la vida del proyecto, tanto sea a nivel de requerimientos, tecnológicos o quizá ambos. Aquí es donde las metodologías Agile se especializan… absorver cambios y tener la certeza de que el rumbo cambiará frecuentemente.

«Entendiendo que los cambios serán inebitables es un buen comienzo para comprender porqué se debe profundamente cambiar la forma de pensar y emplear Agile.»

Como siempre digo, las metodologías Agile son fáciles de comprender pero difíciles de poner en práctica; en teoría, teoría y práctica son iguales, pero en la práctica son diferentes. Espero te sea de utilidad ésta entrada.

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

Implementar Ágil en paises hispanoparlantes vs. anglosajones

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?

¿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)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Implementar Ágil en paises hispanoparlantes vs. anglosajones

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 recusos 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)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

¿Qué hacemos con recursos humanos en Agile?

Hace unos días atrás, una persona no relacionada con la industria del software me preguntó sobre en que consistía el role de Scrum Master (del cual trabajé en el Reino Unido antes de convertirme en Scrum Coach). Una vez finalizada mi explicación, ella me indicó varias similitudes con el papel de Recursos Humanos. Y es cierto, hay muchas tareas que eran anteriormente realizadas por HHRR y que ahora son llevadas adelante por el role de Scrum Master. No obstante, HHRR deberá comprender ampliamente las metodologías Agile antes de comenzar la transformación de la empresa hacia este marco de trabajo, ya que existirán nuevos elementos que deberán ser implementados con excelencia de conocimiento de la metodología.

Recursos Humanos

«La capacitación de HHRR hacia el mundo Agile comienza tan pronto (o incluso antes) que la empresa decide moverse en dicha dirección y no después»

Scrum Master y HHRR el posible conflicto
Veamos primero algunas de las tareas que son hoy en día realizadas por el role de Scrum Master y podrían verse como un conflicto entre ambos roles:

1. Mantener un registro de los días que las personas del equipo no se encontrarán disponibles (vacaciones, etc).
2. Mantener un registro de que días y quién ha estado enfermo o no disponible por otras causas y ser el primer punto de contacto.
3. Agendar cursos y rever activamente si algunas de los individuos requieren formación adicional.
4. Organizar las reuniones con el dueño del producto (Product Owner) o cualquier otro requerido.
5. Para el caso de haber un conflicto en el grupo de trabajo, buscar una solución y contactar a las personas adecuadas.
6. Si existe un Scrum Coach que trabaje con los desarrolladores, coordinar con él/ella las reuniones o recursos que este necesite.

Incluso en una de las empresas la persona que oficiaba de Scrum Master organizaba los cumpleaños del equipo en sitios particulares. Por supuesto que he excluido aquí todas las tareas propias de éste role relacionadas con cuidar que las metodologías Agile sean seguidas correctamente. No obstante, debe recordarse que la existencia del Scrum Master comienza en conjunto con la creación del equipo, lo que indica que alguien deberá concretar las actividades y requisitos anteriores, especialmente los relacionados con la transformación de la empresa hacia el mundo Agile.

Las nuevas tareas de HHRR en Agile
Veamos entonces las nuevas tareas de HHRR, las que pueden diferir con lo que se hacía anteriormente:

1. Contratar a las personas adecuadas
Recursos humanos deberá pensar en individuos o grupos de personas que conozcan las metodologías o estén dispuestas a trabajar con éste marco de trabajo en actitud proactiva de equipo. Lo importante es que quien es contratado sea compatible con la cultura de la empresa y Agile. Para el caso que el equipo ya esté formado y sea simplemente una adición, yo recomiendo que siempre se realice una segunda entrevista con alguno de los miembros del equipo para dar su aceptación.

2. Tomar las medidas para mejorar la comunicación e interacción
Debe asegurarse que los espacios físicos apoyen la comunicación de los individuos, por ejemplo, apostando a que sean abiertos para el trabajo en pares  (sin mayores separaciones físicas) y planeando a su vez espacios donde puedan llevarse adelante las reuniones de planificación de ciclo o de día a día. Si parte del equipo estará remoto, cerciorarse que los PC u otros ordenadores portátiles (tablets, etc) tengan instaladas las aplicaciones necesarias para la comunicación efectiva así como otro software requerido.

3. Redefinir los roles y apoyar a aquellos que se sientan amenazados
Cuando se comienza la implementación hacia Agile, muchos de los roles se verán modificados hacia la nueva perspectiva y es común que las personas se sientan amenazadas por su existencia en la empresa. Por ejemplo, los jefes de proyecto podrán sentir que su role no es más válido durante Agile, no obstante, está en Recursos Humanos el redefinir el mismo, tanto sea como Dueño de producto (Product Owner), Scrum master o cualquier otro role que oficie de punto de contacto (por ejemplo Especialista) con el cliente. En definitiva, debe asegurarse que los individuos se sienten confortables con su nueva posición y estén dispuestos a trabajar fuertemente representando a ellos.

4. Identificar las políticas de la empresa que no concuerden con Agile
Es importante cuando se mueve al mundo Agile que las políticas estén de acuerdo con las metodologías y no existan conflictos que puedan llegar a dañar al rendimienton ni a la auto-estima de los equipos. Para ello deberá realizarse un análisis por menorizado de las mismas para efectuar los ajustes necesarios. La persona de recursos humanos deberá también contar con la libertad de poder críticar a la empresa con el fin de mejorar o modificar sus políticas. Por ejemplo, el trabajo en horario flexible puede ser una de las medidas a tomar para aumentar el rendimiento del equipo y debería ser definido de antemano.

5. Identificar las carencias
Cuando se forma el equipo es importante identificar las carencias y trabajar en ellas para lograr un grupo funcional. Por ejemplo, si el nuevo proyecto requerirá fuertes conocimientos de base de datos, entonces se debe cerciorar que todos los miembros cuentan con el concimiento o de lo contrario,  organizar su formación.

6. Identificar necesidades especiales
Como en todo grupo de personas, pueden existir necesidades específicas, ya sean físicas, relacionadas con temas culturales o religiosos. Por ejemplo, se podría dar cierta flexibilidad de trabajo bajo ciertas circunstancias (embarazo, requerimientos de personas con discapacidad para acceder a áreas de trabajo y tener espacio para codificación en pares, horario diferente durante jornadas religiosoas tales como Ramadán, etc).

7. Comunicación activa con Scrum master
Una vez que el equipo esté formado, debería haber una comunciación activa con el Scrum Master donde se coordinen requerimientos necesarios del equipo o transmita de antemano todo aquello que pueda afectar al rendimiento (vacaciones, viajes, etc).

Es importante a su vez que la persona de recursos humandos focalice el análisis de rendimiento de grupos y conexiones efectivas (o densidad social) pero no puntual (día a día en vez de un evento anual, personas, etc.).
Espero que esto pueda servir a mis amigos de recursos humanos a evacuar alguna de sus dudas.

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

Implementar Ágil en paises hispanoparlantes vs. anglosajones

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…

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)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Agile y la verdad contundente sobre la programación en parejas

Agile ha integrado de las técnicas de Programación Extrema (XP) las tareas de codificación en pareja. Todavía recuerdo cuando por allá por el 2004 en Londres el lider de equipo me mostró la forma en las que se trabajaba en pares… lo primero que pensé fué que no iba a funcionar y que era una empresa de locos de atar.

¿Cómo funciona?
Básicamente cada grupo (y no la empresa) define sus reglas, las que deberán ser llevadas adelante a rajatabla hasta que el equipo realice alguna modificación al  marco de trabajo original. Algunas de los mandatos que he visto para trabajo en parejas en los últimos años son los siguientes:

1. Llevar adelante solamente las tareas de mas de N puntos de esfuerzo (u horas si se emplean las mismas).

2. Las tareas o historias específicas, por ejemplo de base de datos u otro sector crítico.

3. Cada 2 historias, una debe ser llefada adelante en pareja.

4. Las tares que involucran tecnologías o codificación de la cual no todos los miembros están al tanto.

5. Todas las historias, sin importar la carga horaria.

6. Se marcan de antemano las historias que deben ser llevadas adelante en pares.

7. Con juegos (¡mi predilecto!), por ejemplo el que pierde el partido de futbolín o no es capaz de responder la capital de un país debe trabajar de a dos.

Image

Esto por supuesto son algunos ejemplos que he vivido pero hay muchos más; los equipos pueden ser creativos, siempre y cuando esto funcione para ellos, aumente la calidad del código y disminuya el riesgo para la empresa

«El trabajo en parejas no puede ser mandatorio desde fuera del equipo pero tiene que ser comprendido y llevado adelante como algo importante para el crecimiento del equipo y organización «

Si el equipo no desea realizar el trabajo en pares, debería poder demostrar que tiene una opción fiable y superior que permita esparcir conocimiento y aumentar la calidad del código.

La idea entonces detrás del trabajo en equipo es hacer concer a todos los miembros las tecnologías y código, así como también disminuir el riesgo para el caso de que solamente parte del grupo se encuentre disponible. Recuerdo un invierno en Londres donde 4 de los 6 miembros se encontraban enfermos, elevando solamente a 2 el número de programadores disponibles.

Los problemas de trabajo en equipo
Cuando se sugiere a las personas ésta forma de trabajo, es posible que no comprendan su significado o quieran (en forma explícita o implícita) trabajar en pareja con ciertos miembros del equipo. En este caso se pueden dar 6 situaciones claras:

1. Que esté acostumbrado a trabajar en solitario y piense que de esta forma se obtedrá el resultado más veloz y de mejor calidad.

2. Que no desee trabajar por no tener una buena relación con su par.

3. Que no se sienta cómodo  trabajando con alguien que en el pasado fue su superior o tiene más experiencia (o al revés)

4. Que no desee trabajar con alguien que no conoce o solamente tiene contacto esporádico

5. Que no desee realizar la tarea en conjunto con alguien que no se encuentra físicamente en el mismo lugar; por un lado por no contar con las herramientas necesarias para el manejo remoto o exista una diferencia de cultura/idioma.

6. Que piense que se bajará el rendimiento y no se llegarán a los objetivos pautados para el ciclo.

Una cosa que he notado en mi día a día es que en Latino América y España muchas personas tienden a tomar  decisiones basadas en la primer experiencia de contacto. Por ejemplo ante una codificación casual en parejas, las personas puede sentirse incómodsa ante la primer impresión, los hábitos o la forma de hablar/mirar de su par. Esto puede ser fácilmente remediable si se establecen sesiones informales de cohesión de equipos (Team Building) antes de que se comience con el ciclo de trabajo. En muchas ocasiones basta con salir por algunos tragos y hacer que los integrantes socialicen y se conozcan.
También existen varios juegos que pueden ser efectuados al conformar al equipo, los que evidentemente mejoran la comunicación y relación a futuro.

«Siempre que sea posible, evita que los miembros que codifican en pares tengan su primer contacto durante éste proceso»

Lo más típico es que exístan temores de que trabajar en pares pueda  disminuir el rendimiento y hacer que no se puedan cumplir las metas. Esto es un punto importante y hablaré más adelante sobre las investigaciones científicas al respecto y sus resultados.

«Si quieres que la codificación en pares sea efectiva y duradera, tienes que asegurarte que el equipo disfrute el día a día, de forma similar a que fuese un gran juego»

Codificación en pares y pre-conceptos I
Cuando se habla de codificación en pares, se entiende la existencia de 2 roles, uno llamado el codificador y otro el navegador. El primero es quien tiene siempre el teclado o ratón, mientras que el segundo es quien verifica o sugiere ideas. Ambos roles pueden ser intercambiados cada ciertos minutos y debería ser así para que se considere una tarea exitosa.
Originalmente la bibliografía indicaba que el codificador y el navegador trabajaban en diferentes niveles de abstracción; el navegador actuaba con un pensamiento más estratégico revisando, prestando atención a los defectos y en cierta forma marcando el rumbo del codificador, mientras que éste último solamente escribía el código (Dick A.J., Proceedings of XP; Jenser R., A Pair programming Experience). Trabajos más recientes indican que esto no es así y que ambas personas rotan su trabajo sin diferencias en los niveles de abstracción.

Trabajo en parejas exitoso
De acuerdo a un estudio realizado por L. Plonka (2011), para que el trabajo en pares se considere sano, cada persona debería codificar entre un 40 a 60% de su tiempo y la media de rotación debería ser de 10 a 15 veces por hora. Este porcentaje a su vez se ve incrementado en desarrolladores con mas experiencia.

«La codificación en pares debería ser de entre 40 y 60% del tiempo de cada individio.»

A su vez, se debe asegurar que todos los equipos cuenten con las mismas herramientas y similar capacidad de computador. Para el caso de que uno de los desarrolladores se encuentre remoto, herramientas tales como Skype y escritorio remoto deberían estar disponibles.

Codificación en pares y pre-conceptos II
Los equipos al comenzar inicialmente con Agile tienen miedo de no cumplir con las historias aceptadas para el ciclo debido a la «pérdida de tiempo» del trabajo en equipo. Este temor es normal y te brindaré una investigación científica al respecto para que puedas tenerla en mente. En un estudio realizado por Alberto Sillitti y L. Plonka (2011) se vió que cuando el desarrollador trabaja solo, éste ocupa únicamente una media de 33.3% codificando y 67.7% pensando sobre las diferentes opciones o buscando una solución en Internet  (esto último sobre todo en desarrolladores menos experimentados).

«Un desarrollador codifica solamente 33% de su tiempo cuando lo hace solo»

Por su parte, cuando se trabajan en pares, el tiempo de codificación se ve aumentado a casi el doble y de acuerdo a un estudio de Alberto Sillitti (2011), la calidad del código se ve aumentada. Un ejemplo interesante es que los programadores novatos trabajando en pareja pueden obtener niveles similares de calidad a los mas experimentados (Senior).

La siguiente tabla (Alberto Sillitti, 2012) muestra una comparación de tiempos de codificación:

Image

Tiempos de no-codificación
Los tiempos de espera han sido también estudiados y es interesante ver que pasa con el tercio restante:

1. Tiempos de espera
El desarrollador deberá esperar por el computador a que termine con un proceso (compilación, ejecución de pruebas, etc), esperar a que se integren los cambios, etc

2. Discusiones o explicaciones
Se discuten o analizan las diferentes opciones, se ven las líneas de código y se ve cual es la mejor opción.

3. Utilización de medios tradicionales
Los desarrolladores prefieren rever la estructura de código en una pizarra, dibujar la secuencia en un trozo de papel para comprender mejor la tarea y las posibles opciones.

4. Búsqueda o consejo de alguien más
Dialogar con una tercera persona que tenga más conocimiento o diferente punto de vista para ver como solucionar el problema.

5. Interrupciones externas
Los desarrolladores son interrumpidos por llamadas telefónicas, otros desarrolladores con consultas, etc

Es decir que cuando se trabaja en pares, el tiempo de escritura se incrementa al doble, así como también la calidad del código. La codificación en parejas debería ser adoptada por todas las empresas de software y serciorarse que se realiza de forma divertida e interesante.

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

Implementar Ágil en paises hispanoparlantes vs. anglosajones

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?

Resistencia institucional y cambio hacia Agile (Parte 1)

Resistencia institucional y cambio hacia Agile (Parte 2)

Lo que no se dice de Ágil

Las 15 preguntas antes de implementar Ágil/Scrum en la empresa

Resistencia institucional y cambios hacia Agile (parte 2)

En la entrada anterior vimos que alcanzar un cambio duradero en la empresa depende de muchos factores. En principio, los marcos de trabajo Agile contienen normas que provienen del sentido común ya que simplifican mucho la tarea, no obstante, las personas no aceptan los cambios por motivos nobles sino que deben tener otros estímulos, los que estén relacionados con una ganancia personal de algún tipo y que evidentemente sosiegue la pérdida de la formas de trabajo anteriores.

Cambio y aceptación
Te comenté sobre los 8 tipos diferentes de perfiles que podrás encontrar a la hora de que las personas traten de ganar más agilidad. No obstante, sin importar en que grupo se encuentran, experimentarán un proceso llamado de cambio y aceptación al exponerse a una modificación al proceso.

Reacción 1era. Se deniegan
Las ideas le parecerán genial al grupo o persona, pero en definitiva, quedará solamente en ello…  una buena idea a ser llevada adeltante en un futuro lejano.

Reacción 2nda. Se enojan
Las personas ridiculizarán a las metodologías, como ser el indicar que no tiene sentido una reunión de parado a la mañana o una pizarra con las historias.

Reacción 3era. Negocian
Se aceptan parte de las metodologías para su uso pero se negocian por un periodo determinado o proyecto específico.

Reacción 4ta. Se entristecen
Durante la utilización de Agile se tienen miedos ya que se ha salido del circulo de seguridad y ahora no se sabe si todo saldrá como se planeaba y empiezan a cuestionar el porqué de elegir este camino.

Reacción 5ta Aceptan
Ha pasado la tormenta, todo salio un poco mejor de lo esperado pero hubieron problemas. Se sienten ahora que pueden seguir adelante con más confianza.

Ten en cuenta que estos sentimientos son una generalización, y pueden no seguir este orden o tener duraciones diferentes cada período.

Como te decía, identificamos en mi entrada anterior los siguiente 8 tipos de perfil que actuarán a favor o en contra a la hora de querer implementar cualquier marco de trabajo:

1. Los seguidores de bajo consumo
Aquellas personas que se sienten cómodas con el sistema porque les permite seguir los procesos, no están interesados en aprender y al final siempre optan por la forma más fácil de llevar adelante su día, lo que normalmente es la vía que ya conocen.

2. Los miedosos jerárquicos
Aquellos que creen que el implementar un cambio les hará perder su jerarquía o beneficios.

3. Los segudores del cuadro de football
Aquellos que se adjuntarán a la mayoría, sin importar cual sea la opción, ni tampoco evaluan firmemente las nuevas ideas. Ellos ven el cambio como una pérdida y debido a ello el adjuntarse a las mayorías los hará sentirse más seguros y de alguna forma ser ganadores.

4. Los del circulo de seguridad
Aquellos que piensan que si se ha hecho algo por mucho tiempo entonces no se deberá modificar; no quieren experimentar lo nuevo y son pesimistas sobre el futuro.

5. Los Escépticos
Aquellos que no creen en el cambio de rumbio, en general la resistencia se establece como la coexistencia de varios de los puntos anteriores. Ellos expondrán argumentos como que Agile removerá la estructura jerárquica de la empresa hasta casi una anarquía o que estas metodologías no son las más adecuadas para los proyectos actuales (ej. Agile es solamente para proyectos pequeños…”)

6. Los temporales
Siempre creen que es un mal momento para implementar un cambio, que puede ser dejado para más adelante ya que hoy es crítico y el mañana lejos en el futuro será mejor.

7. Los funcionales
Creen que si algo está y funciona es siempre la mejor opción, entonces por que cambiarlo.

8.  Los seguidores del cambio
Aquellos que creen en el cambio o por lo menos son abiertos a la evaluación, pero a veces pueden tomarse todas las nuevas cosas a la ligera. Ellos son verdaderos evangelizadores de tu idea.

Antes de pensar en la agilidad
Es entonces que se requiere un plan con cierta estructura para poder reinar en el caos de opiniones y posiciones. Los siguientes 7 puntos deberían apoyarte activamente:

1. Establecer una relación de confianza con todas las personas, independiente de si creen o no en tus ideas.
2. Oficiar por ratos de «Abogado del diablo», esto es, ponerte en su lugar y ver la situación desde su punto de vista y ostentar posibles soluciones.
3. Evalúar todas todas las opiniones pero tener siempre claro los conceptos Agile.
4. Mantener la calma; al final del día no es personal, es simplemente la resistencia al cambio
5. Negociar la utilización de las metodologías en algún proyecto
6. Involucrar a todas las personas que se ven afectadas por los cambios
7. Prepárarte mentalmente para aceptar que algunos individuos cambiarán su opinión y revertirán su posición.

Una vez aceptado que se deberá cambiar continuamente
Acuérdate de los principales motivos (que nombramos en la entrada anterior) de porqué las personas aceptan un cambio y asegúrate de tenerlo presente. Una vez que se ha aceptado que el cambio será constante, los siguientes 6 puntos deberían apoyarte a consolidar el mismo:

1. Crear una visión sobre porqué la agilidad es necesaria y el cambio constante
2
. Comunicar la visión y aceptar las opiniones
3. Planear la inserción del marco de trabajo o nuevos valores
4. Poco a poco utilizar los mismos y comparar acciones utilizando uno u los otros valores
5. Tener una forma sencilla de analizar el avance
6. Evaluar los resultados, integrar las sugerencias y volver al punto 1


El Modelo Satir durante la utilización de Agile

Virginia Satir fué una psycoterapista americana del siglo pasado que observó un ciclo de experiencias por las cuales transita un individio o equipo cuando se expone a algo nuevo. De acuerdo a ella, las 5 siguientes fases son vividas como reacción a un cambio:

1. Cuando recién se adiciona el cambio
La persona se siente contenta y ansiosa por probar lo nuevo. No existe todavía una reacción adversa al mismo.

2. Resistencia
La persona o grupo se siente negativa sobre los cambios, se ofrece resistencia y se comienza a sentir no tan confortable al salirse del circulo de seguridad; lo que en nuestro caso es la  metodología Agile.

3. Estado de Caos
Se experimenta el cambio, las personas comienzan a sentirse menos confortables y de alguna forma confundidas sobre que hacer y como reaccionar.

4. Transformación hacia la idea
Se comienzan a encontrar algunas soluciones  por momentos pero en otros decepciones; algunos días pensarán que Agile es fantástico y otros que nunca funcionará, pero la maquinaria del cambio está en marcha.

5. Nuevo estado
Una vez pasado este proceso, todo se estabiliza, las personas aprenden y comienzan a sentirses confortable sobre el nuevo estado.

Si el cambio es concebido de forma correcta, el grupo se unificará y el rendimiento se estabilizará con un mayor nivel de unidad de equipo. Incluso se podrán observar cambios a nivel corporal (posturas más erectas), mejor comunicación y más seguridad al transmitir ideas. El hecho de haber logrado un objetivo en común hace que los cambios sean ahora estables.

Satir

En esta etapa, no debes olvidarte ver que motiva a los otros para que puedan querer explorar los imbalances internos y externos que amenacen al equipo. Ello se puede hacer activamente mediante los procesos de retrospectiva y adecuación constante, lo que dará como resultado empresas más flexibles a los cambios.

Luego de varios ciclos de trabajo observarás también que tu compañía se hará más permeable a cambios frecuentes, lo que brindará más tolerancia, flexibilidad y motivación a la hora de absorver nuevos conceptos, sin verse amenazados por ellos.

Comprender el modelo Satir de antemano es de mucha utilidad ya que te permitirá identificar en que etapa te encuentras y aceptar al mismo como un proceso natural, el cual es el resultado de la introducción de cambios.

Pero recuerda que es siempre un modelo para darte ideas, pero no es una lista de pasos a seguir.

Marco de trabajo para aliviar los cambios
Otro punto que es importante es como gestionar el cambio; verás que al buscar más agilidad, tendrás equipos y personas que serán muy receptivas y desearán emplear la totalidad de las prácticas o nuevas ideas, mientras a que otras les llevará más tiempo adaptarse. El problema mayor es que tienes que contar con todos ellos de forma simultánea, ya que de lo contrario se producirá una fractura.
Una de los puntos que debes tener en mente efectivamente es el contar con un marco de trabajo para aliviar el peso en las personas y grupos que se encuentren desfazados. Por ejemplo, algunos estarán muy avanzados y con deseos de probar más mientras que otros se quedarán aletargados y requerirán más tiempo.

Margen00

Para resolver este problema de forma efectiva, tendrás que establecer un bloque o margen de cambios, algo así como poner a todos los integrantes en un mismo vagón a velocidad constante sin posibilidad de que cada uno conduzca un coche independiente.

Margen01

Los márgenes traseros y delanteros del límite de cambio aplican los conceptos explicados. Por ejemplo, se podría indicar que en el ciclo 1 se van a realizar reuniones de actualización en la mañana (stand up), se deberán anotar todos los requerimientos en historias y adicionarlas al  «backlog», lo que demarcará el límite inferior. Esto forzará a las personas que se encuentran aletargadas a que se muevan dentro del bloque de cambios. Por el otro lado, deberías indicar que la integración continua no será parte de esta etapa, lo que impondrá el límite superior, adicionando así la restricción a los más avanzados.

Así centrarás todo el equipo en sostener las prácticas y administrar la absorción de conceptos de forma unificada, lo que dará como resultado el latido del equipo sea unificado.

Te dejo entonces que lo pienses y veas como podrías aplicar las ideas a tu empresa y equipo.

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…

Gracias por escucharme,

Erich

Resistencia institucional y cambios hacia Agile (parte 1)

En mi entrada anterior te mostré una forma precavida de buscar consenso en la empresa a la hora de querer introducir formas de trabajo ágiles. Ahora vamos a conocer uno de los problemas con los que te encontrarás habitualmente… la resistencia institucional.

Falsas creencias sobre el cambio
Cuando se cree fuertemente en algo se piensa también que es sencillo el convencer a un grupo de personas para adoptar las mismas. Por ejemplo, si has utilizado con éxito las formas de trabajo ágiles o el marco de trabajo de Scrum, entonces estarás convencido que bastará con explicar sus beneficions para que los demás la adopten. No obstante, te estarás olvidando de uno de los puntos fundamentales… las empresas están compuestas por personas las que siempre tienen una fuerte resistencia al cambio.
Tratar de concretar exitosamente un conjunto de cambios y que sean durables en el tiempo es una tarea difícil. Los individuos se acostumbran a los procesos y eso hace que los mismos sean más rígidos, lo que da como resultado que se tenga más resistencia al cambio.
Un proceso en definitiva está diseñado para resistir los agentes externos. Imagínate si siempre que realizases una tarea tuvieses que llevar adelante un nuevo proceso ¡no te darían los días de tu vida para completar un par de ellas!.

La resistencia y los procesos
Los procesos han sido creados para (de alguna forma) facilitarnos las tareas. Te puedes imaginar un proceso como un túnel guía por el que si sabes por donde entrar, sabrás también por donde salir.

Proceso estructurado = Resultado esperado = Tiempo estimable

Existen numerosos desafíos a la hora de introducir una nueva forma de trabajo en la empresa. Que la agilidad sea derivada del sentido común y luzcan no demasiado complejas no quiere decir que sean fáciles de implementar o que las personas automáticamente adopten las mismas.

Una de las primeras consecuencias que verás es que los individuos podrán comprometerse  a probar algo nuevo, pero esto no será un indicador fiel de que el mismo sea perdurable. He visto casos donde se ha cambiado la metodología de trabajo hasta encontrar una incidencia grave, para allí volverse a las formas anteriores.

«Cambio hoy no significa que sea sustentable hasta mañana»

La gente realmente necesita estar convencida de los beneficios de las nuevas metodologías o nuevos valores, pero esto no es suficiente. Las personas necesitan invertir tiempo y esfuerzo, lo que hace que sea un tema bastante más delicado. Es por ello que en la entrada anterior te comenté de lo importante que es buscar consenso y efectuar charlas de verdadera ida y vuelta en la empresa.
Encontrar resistencia a nivel personal o profesional es normal, estamos constantemente rodeados de publicidad, y filtrar es parte de una de las tareas innatas del cerebro. ¡Imagínate si comprases todas las ofertas que aparecen en el catálogo del supermercado simplente porque están alli!

«Cuestionar los métodos existentes es siempre un buen comienzo, la resistencia también»

Los tipos de individuo
Aunque no he realizado una investigación científica de alto nivel y lo siguiente es solamente basado en miexperiencia personal, puedo estar ciertamente convencido que encontrarás varios perfiles en la empresa a la hora de empujar el cambio.

1. Los seguidores de bajo consumo
Aquellas personas que se sienten cómodas con el sistema porque les permite seguir los procesos, no están interesados en aprender y al final siempre optan por la forma más fácil de llevar adelante su día, lo que normalmente es la vía que ya conocen.

2. Los miedosos jerárquicos
Aquellos que creen que el implementar un cambio les hará perder su jerarquía o beneficios.

3. Los segudores del cuadro de football
Aquellos que se adjuntarán a la mayoría, sin importar cual sea la opción, ni tampoco evaluan firmemente las nuevas ideas. Ellos ven el cambio como una pérdida y debido a ello el adjuntarse a las mayorías los hará sentirse más seguros y de alguna forma ser ganadores.

4. Los del circulo de seguridad
Aquellos que piensan que si se ha hecho algo por mucho tiempo entonces no se deberá modificar; no quieren experimentar lo nuevo y son pesimistas sobre el futuro.

5. Los Escépticos
Aquellos que no creen en el cambio de rumbio, en general la resistencia se establece como la coexistencia de varios de los puntos anteriores. Ellos expondrán argumentos como que Agile removerá la estructura jerárquica de la empresa hasta casi una anarquía o que estas metodologías no son las más adecuadas para los proyectos actuales (ej. Agile es solamente para proyectos pequeños…»)

6. Los temporales
Siempre creen que es un mal momento para implementar un cambio, que puede ser dejado para más adelante ya que hoy es crítico y el mañana lejos en el futuro será mejor.

7. Los funcionales
Creen que si algo está y funciona es siempre la mejor opción, entonces por que cambiarlo.

8.  Los seguidores del cambio
Aquellos que creen en el cambio o por lo menos son abiertos a la evaluación, pero a veces pueden tomarse todas las nuevas cosas a la ligera. Ellos son verdaderos evangelizadores de tu idea.

«Preocuparse y comprender verdaderamente a los problemas de la gente es una tarea primordial para remover los obstáculos a la hora de pensar en un cambio sustentable»

El cambio como herramienta positiva
Explicar las ventajas de las nuevas formas de trabajo no traerá cambio alguno. El cambio debe ser planeado y se incluido dentro de una estrategia clara y estructurada. Recuerda que diferentes grupos tienen distintas perspectivas del cambio; un gerente verá motivos económicos mientras que un jefe de proyecto evaluará si los mismos harán mermar el riesgo.

«Esperar que todo el mundo sea receptivo a los cambios nos deja sin estrategia. Ser receptivo pero cauto es la mejor opción»

Dado los 8 tipos de individo que hemos visto, las posibilidades de rechazo pueden ser incontables. No onbstante, existen ciertas afirmacions que pueden traducirse en un apoyo masivo:

1. El cambio se vea como una ganancia en seguridad, autoridad o prestigio.
2. Una mejora de las condiciones de trabajo (por ejemplo trabajar mejor o más cómodo).
3. Hacer el trabajo mucho más divertido. Todo proyecto con esta característica aumenta la motivación del individo.
4. Reducir los tiempos de lo que se hace o de los requerimientos desde que el cliente lo solicita hasta que se da a luz.
5. Finalmente cuando los cambios son propuestos por jerarquías superiores (ej. el director de la empresa). En este caso normalmente no se cuestiona.

En la próxima entrada te mostraré algunas técnicas que puedes utilizar para introducir cambios en la empresa de forma efectiva. Como vez, introducir Agile no es sólo sobre tecnología pero sí sobre entender a las personas.

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…

Gracias por escucharme,
Erich.

Lo que no se dice de Agile

El cambio es una experiencia que puede ser muy grata para algunas personas y difíciles para otras; la empresa no es una excepción ya que esto ocurre de la misma forma y con miedos similares.
Dependiendo de cual sea tu rol en la compañía, será como vivirás la experiencia de los cambios.

Por ejemplo, si eres un desarrollador, tu punto de vista estará centrado en la visión tecnológica, esto es, las nuevas posibilidades que te brindará el marco de trabajo para resolver los problemas  a la hora de implementar la aplicación. Si a diferencia estás a cargo de un proyecto, tu punto de vista estará regido en base a si estarás menos expuesto al riesgo (¡lo que implicará menores dolores de cabeza para ti!) y si finalmente podrás entregar el proyecto en tiempo y forma. Si eres el director de la empresa, estarás más preocupado por las evaluaciones económicas o posicionamiento del producto en el mercado. Te guste o no, para adoptar cualquier cambio en una compañía deberás demostrar primero que se tendrá un beneficio económico importante.
Durante muchos años me he visto involucrado en diferentes metodologías de proyecto como ser la programación en Cascada, Scrum, formas de pensamiento Ágil y DSDM, y he visto la forma en que ellas impactan sobre las personas

El camino al cambio Agile y la Gran Charla
Antes de evaluar cualquier cambio, es mandatorio que los miembros de tu empresa, sin importar su posición/rango, comprendan integramente al mismo. El difundir no implica simplemente explicar sino que deben ser charlas orientadas hacia la discusión, analizando posteriormente las distintas opiniones e integrándolas al resultado final.
La empresa debe ser entonces concevida como un grupo global de trabajo, incluyendo a desarrolladores, gerentes, interesados en el producto, etc.; cada uno de ellos deben ser integrados a lo que yo llamo la «gran charla». Por un lado entonces, esta conversación te servirá para informar e incluir todos los puntos de vista, y por el otro, te ayudará a obtener el apoyo y los aliados necesarios a la hora de integrar la metodología. El estar convencidos hará:

Directores – propiciar el cambio y remover obstáculos para conseguir el financiamiento o las condiciones para que Agile pueda ser implementado.

Jefes de proyecto – Convertir su posición a la de mentor/evangelista, lo que hará correr la voz y ayudará a los equipos de desarrollo a conectar con los ejecutivos de la compañía.

Equipos de desarrollo – Estar convencidos y tener un ojo constante en que las reglas de la metodología o forma de pensamiento sean seguidas por todos los integrantes.

Cuando cambiar
Si una organización es realmente exitosa en sus procesos, tanto sean estos formales o informales, te sugeriría evaluar otros aspectos a la hora de pensar en Agile como una opción.

Por supuesto que algo funcione y que se haya utilizado por muchos años no significa que sea la forma más óptima. Quiza la mejor alternativa en este caso sea siempre ver que procesos pueden ser mejorables y poco a poco (de forma iterativa) comenzar a realizar pequeños cambios (lo que es llamado Kaizen en Lean) con el fin de realizar una mejora y evolución constante.
Si este es finalmente el camino a seguir, entonces tendrías tambien que evaluar la secuencia completa de  pasos desde que el cliente sugiere un cambio hasta que el mismo se hace realidad (Value Network o red de valor). Ello se debe hacer como una cadena global de sucesos y nunca como sus procesos aislado o a optimizar. Y siempre observando si algunas de las metodologías nuevas pueden ser integradas para la mejora del proceso.

¿Cómo y dónde Agile?
Por supuesto que las metodologías Ágiles puede ser excelentes, pero no obstante, existen casos donde lo que el cliente requiere es mayoritariamente estático; en este caso otras formas de trabajo podrían ser más adecuadas.
Idealmente las sugerencias de cambios en la forma de trabajo deberían ser comenzadas siempre en paralelo, esto es, desde puestos gerenciales y desde equipos de desarrollo, confluyendo así en una gran charla, que propicie un ámbito común que beneficie a la compañía, su alineamiento, valores y metas.

Agile como una respuesta externa
Cabe destacar que Agile también puede ser forzado por factores externos, como ser que se tenga un proyecto que involucre un alto riesgo tecnológico (nuevas herramientas), fechas de entrega apretadas, o que finalmente tu competencia sea una compañía más flexible. Ello hace que estos tengan menores tiempos desde la concepción de la idea hasta la puesta en producción, cosa que aumentará tu riesgo si no te mueves en la misma dirección.

«El error mas claro es siempre instrumentar los cambios a metodología Agiles, sin que los integrantes de la empresa finalmente comprendan porqué caminan en esa dirección»

La realidad del mercado
Por supuesto que todas las empresas tienen un margen de mejora, y las que desarrollan software parecen ser las que más lo necesitan. En los últimos años solamente 16% de los proyectos se han terminado en tiempo y/o con el dinero estipulado, el 31% se han cancelado y el 53% han excedido largamente su costo estimado (de acuerdo al informe de la compañía Standish). Es por ello qur la agilidad se ve como un candidato ideal, ya que se ha demostrado recienemente con simuladores y modelos matemáticos que mejora ampliamente los tiempos de entrega, así como también, se brinda la flexibilidad de efectuar un cambio de rumbo luego de comenzado el proyecto.

El cambio y su precio
El moverse hacia el mundo de las metodologías Agile implica cambios en la estructura de la empresa, en la forma en las que se toman las decisiones, en como interactúan las personas y equipos y finalmente como se negociacia y se arriba a consensos. El precio inicial a pagar podría ser buscars un proyecto mediano o pequeño donde realizar la «primera implementación», con el fin de que todas las partes puedan aprender e integrar las metodologías en su día a día, así como aprender que es la mejora continua

Los pasos a seguir deberían ser los siguientes:
1. Análizar la estructura actual de la empresa
2. Realizar varias sesiones de «Gran charla»
3. Análizar como afectarán los cambios y sus resistencias
4. Implementar un plan de adopción de alguna metodología Ágil en un proyecto inicial
5. Evaluar el rendimiento al finalizar el proyecto y su aprendizaje, y volver al punto 1.

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

Implementar Ágil en paises hispanoparlantes vs. anglosajones

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

Las 15 preguntas antes de implementar Agile/Scrum en la empresa

Existen varias aproximaciones cuando se piensa implementar Agile en una empresa, no obstante, antes de iniciar cualquier movimiento es necesario conocer plenamente el contexto y la realidad.

He elaborado algunas preguntas, las que te servirán para guiarte a la hora de fundamentar la decisión y comprender mas claramente como implementar Agile/Scrum.
Recuerda que cuando finalmente se decida cambiar de forma de trabajo , tu empresa debería entender los criterios que implican la  mejora de los procesos y la calidad del software producido, el aumento de la velocidad desde que el cliente sugiere la idea hasta que la misma se concreta, el incremento en la creatividad y la gestión adecuada de los proyectos, así como también los costes asociados al mantenimiento del producto final y la idea que tiene la empresa de las personas que la integran.
Por supuesto que todo esto se traduce en dinero, por lo que finalmente tendrás que comprender las motivaciones, visión y forma de trabajo de tu organización.

Bueno, aquí te dejo algunas preguntas para que las vayas pensando; luego veremos que hacer con ellas.

1. Observa a los ingenieros/programadores, ¿Trabajan en varios proyectos en forma simultánea a tiempo exclusivo?
– Si se quisiera trabajar en forma exclusiva, ¿Qué pasos debería dar la empresa y cómo se instrumentaría?
– ¿Sería visto por los empleados como una mejora o detrimento de sus valores?

2. ¿La organización de la empresa es meramente jerárquica o mas bien plana?
– En caso de ser jerárquica ¿Existen valores explícitos que apoyen a las personas, las jerarquías o ninguno de ellos?

3. ¿Los roles están bien definidos y limitan o aumentan las posibilidades de las personas?
– ¿Todos conocen el alcance de cada role o ellos son flexibles?

3. ¿Los proyectos anteriores han sido entregados en tiempo y forma o han sufrido retrasos?
– Para el caso de tener retrasos, ¿Podrías conocer si el motivo ha sido debido a las personas o el proceso?

4. ¿El cliente final está contento con el producto?
– ¿Se ha generado confianza entre el cliente y la empresa?
– ¿Se podría haber hecho mejor?

5. ¿Las personas de desarrollo interactúan con sus superiores u otros colegas o trabajan de forma independiente?
– A su vez ¿Existen limitaciones dentro de la organización con respecto a la libertad de opinión y las personas la utilizan frecuentemente?

6. ¿Las interacciones entre diferentes roles del proyecto se producen constantemente o existen etapas bien definidas?

7. Que tipo de metáfora podría describir tu empresa: ¿Una máquina que se compone de partes reemplazables? ¿Una cárcel psiquiátrica? ¿Un conjunto de elementos complejos sin patrones aparentes donde nada se puede predecir? ¿Un conjunto de fuerzas donde todo puede ser planificado a la largo plazo pero no a corto?

8. ¿El equipo de desarrollo y jefes de producto están físicamente en la misma área?
– De no ser así, ¿Cuál es el motivo? ¿Es este conocido por todos los integrantes de la empresa? ¿Qué pasaría si estuviesen todas las partes interesadas en el mismo lugar?

9. ¿Los desarrolladores conocen la visión completa del producto o tienen miopía institucional?

10. ¿Las decisiones de cambios son discutidas con el equipo de desarrollo o  tomadas meramente por la parte gerencial?

11. ¿Existe rotación de las personas y roles o cada individuo trabaja en su especialidad?

12. ¿La compañía invierte activamente en capacitación o es el propio desarrollador el que debe buscar su camino?
– ¿Cuál es el motivo real de la capacitación?

13. ¿Existe una vía formal para canalizar nuevas ideas?

14. ¿Cuál es la idea que tiene la empresa sobre las personas de la organización?

15. ¿Se pueden detectar tareas innecesarias a simple vista o reglas de la empresa que limiten el valor generado al cliente?
– Si existe un proceso de eliminación de este desperdicio, ¿Ello se hace potenciando las reglas de la empresa que apoyan la no acumulación de desperdicio o disminuyendo aquellas que lo generan?

Mi recomendación es que no te las tomes las respuestas a la ligera, conversa con tus colegas y demás integrantes de la empresa para concoer su opinión y presta particular atención a las diferencias con tus respuestas y porqué.
Puedes leer también mi artículo sobre los 7 sitios de quien certificarte en Ágil/Scrum aquí.

Recuerda que me puedes contactar si necesitas ayuda en cursos a medida, sobre Como implementar Agilidad en empresas de 20 a 20.000 empleados, Escalando Ágil,  Requisitos Ágiles, o charlas orientadas a Jefes de proyecto, CEO´s, etc.

EMAIL: ErichBuhler@AgileIB.org
LinkedIn

Gracias por escucharme,

Erich.