Psicología y Scrum: desarrollo ágil de equipos (1ª PARTE)
Pin It
+10.02.58.png)
Scrum no es gestión de proyectos:
+10.02.58.png)
Jose Ramón Diaz es emprendedor, Ingeniero de Software y Agile Coach. Twitter nos unió al interesarse por alguna de las metodologías para grupos con las que vengo trabajando en el diseño de reuniones participativas. Luego vinieron un café y un par de reuniones en las que nos hemos conocido mejor y esbozado diferentes soluciones (pueden consultarse aquí) para ayudar a los equipos a implementar la cultura y metodología ágil que les permita desarrollar software innovador y creativo a través de Scrum.
Scrum no es gestión de proyectos:
A nuestro juicio introducir esta marco de trabajo en una organización a través de un equipo, supone afrontar un cambio cultural y de paradigma importantes. Por todo ello se hace necesario un análisis previo para descubrir si se dan los condicionantes para iniciar este viaje cultural y ayudar a que se desarrollen y mantengan dichos condicionantes.
Las personas del equipo, acostumbradas a trabajar de otras formas (seguramente bajo la directriz de un jefe de proyecto) tienen que hacer suyos unos nuevos valores. Estas nuevas formas de pensar y actuar (y veremos en otra entrada que también de ser) están relacionadas con los siguientes:
Transparencia:
- que va mucho más allá de aprender a utilizar elementos visuales (taskboards, burndown charts, etc.)
- requiere mostrar feedback útil
- desplegar la humildad necesaria para aceptar juicios sobre el propio desempeño en el equipo así como
- elevar la consciencia para gestionar las conversaciones privadas convenientemente haciéndolas públicas cuando sea necesario
Compromiso personal:
- vinculado a mostrar un interés genuino por la tarea y por alcanzar resultados de manera conjunta
- el victimismo no es excusa, se requiere una actitud responsable o protagonista que exige impecabilidad en el cumplimiento de los compromisos individuales
- donde el “tú me dijiste que lo hiciera” no tiene ya cabida
- y no omitir ningún paso a la hora de ofrecerse o aceptar un compromiso
Confianza:
- creer y demostrar que se cree que los demás hacen las cosas lo mejor y máximo que pueden hacer
- considerar y apreciar que las personas en el equipo son bienintencionadas, sus acciones y propuestas tienen un motivo válido, aún si en el momento no es clara
Valentía
- para aceptar los errores y hacer notar los errores ajenos
- para entregar juicios, feedback y opiniones fundadas con transparencia
- esperar transparencia para comprometerse y pedir compromiso,
- as como para confiar y no descuidar la confianza depositada.
En esta entrada destacamos una serie de principios que tienen que regir el comportamiento de las personas del Equipo Scrum. Este próximo viernes me detendré a considerar porqué fracasan los intentos de implantación o porqué no se logra explotar todo el potencial de orientar el trabajo de los equipos desde este marco aún cuando han recibido una exquisita formación.
¿Intuís por qué pueden no fructificar la implementación, no alcanzar los resultados esperados o que el cambio inicial no sea sostenible en el tiempo?
¿Intuís por qué pueden no fructificar la implementación, no alcanzar los resultados esperados o que el cambio inicial no sea sostenible en el tiempo?
Más info:
El post cruzado de Jose Ramón: Metodologías Ágiles y Coaching
La segunda parte de este post puede consultarse aquí.
Comentarios
Me explico,Cuando aplicar una metodología de trabajo es el objetivo organizacional, se podrían estar perdiendo de vista los objetivos de las personas que allí trabajan, ofrecen su fuerza laboral, que entregan su tiempo diario para los objetivos que muchas veces no comprenden y con las metodologías que en la mayoría de las ocasiones no comparten.
Esto es así por cuanto los líderes no comprenden Agiles desde sus principios y valores, sino desde la rentabilidad que presuponen una mejora tecnicista basada en el ahorro por acortamiento del método de trabajo, con la creencia de que todo irá mejor por que ahora las entregas son pactadas para ser más cortas en iteraciones evolutivas e incrementales.
Así obligan al Ingeniero a entrar en un "Agile-Footing" donde es más complicado demostrar valor en las actividades que se llevan a cabo. Ahora no solo tienes que hacer lo que hacías antes, sino que también lo tienes que hacer de esta otra manera. Y sino, si no comprendes que son las iteraciones cortas y que todo debe ser en resumidas cuenta mejor, entonces no estás trabajando en equipo. Ojo si eres un revelado, si pides que te expliquen por que ahora tienes que entender el trabajo del otro y "reportar a diario", y ser polifacético y generalista, y empezar a venir de jeans y zapatillas en lugar de tu camisa y pantalón de vestir.
Otras exigencias se ponen a tono también en otros niveles. Pero podríamos hablar de ello luego.
El error estuvo en la base, en cuando "un par de gatos de alcurnia" decidieron implantar esto de Agile cuando asistieron a una conferencias de algún pseudo-gurú y lo que el tipo dijo les pinto genial para una propuesta de plan para Black-Belt-SixSigma..."cómo le ahorro 100 grandes a la compañía".
Así, deciden que si antes habían implantando CMMI-5, más ISO9000, más ITIL y otras yerbas, ¿que tan difícil podría ser implantar SCRUM? un framework tan fácil que hasta ellos lo entienden :P
El error está en el mindset, por que creyeron siempre que los drivers se diseñan y modelan con herramientas y se los difunden con la Intranet... "mirá pibe, vos que sos nuevo tienes que hacerte todos estos trainings... aquí están los links". Al poco tiempo ese pibe es un Scrum Master por que entendió los diagramas (esquemas) y luego viaja a USA y sigue la corriente de gente que no piensa, no entiende, no siente que SCRUM no es liderar gente como una cachetada, sino solo una herramienta de trabajo, y no entiende que solo puedes ser líder si entiendes y aplicas principios y valores Agiles.
El error está al inicio de todo, cuando a la gente le evitas los drivers adecuados que no son más que otra gente. No cualquier otra gente, sino aquella con experiencia, con claridad en cada una de las acciones esperadas en el flujo del marco de trabajo que se elije.
¿Por la implantación de Agile falla muchas veces? Simplemente por que se desarrollo un cuerpo sin espíritu.
Saludos, Javo
Porque aprender el método es fácil. Entenderlo también. Incluso verbalizar que uno se compromete a utilizarlo de la mejor manera. Sin embargo, lo complejo y necesario para sacarle todo el valor de manera continuada y sostenible es realizar un ejercicio sincero para revisar paradigmas y modelos mentales.
A nuestro juicio, involucrar a la cabecera de la organización y reforzar las competencias de los líderes para traccionar del cambio es uno de los hitos, junto con un diagnóstico cultural previo, para iniciar este tipo de proyectos.
Otra opción es convertir al Team Scrum en una minicultura con entidad propia, no para hacer guerrilla, sino que sepa gestionar esa doble ciudadanía con éxito. En los comentarios de la entrada de Jose Ramón estamos hablando sobre ello.
Feliz evangelización, Javo,
Pienso que la falta de Mentoring (Coaching-Agile) que es bueno para la culturalización y adopción, explica perfectamente lo que había comentado a cerca de "la falta de los drivers adecuados". De hecho creo que se dilucida bastante bien "por que falla en la adopción-implantación de Agile" (independientemente del marco de gestión).
Cuando hice referencia a las personas que pueden colaborar y dirigir los cambios culturales, ciertamente estoy hablando de expertos fuera del ámbito técnico, es decir consultores, quizás externos, lo cual no quita que puedan existir técnicos-pragmáticos (consultores técnicos internos???).
La adopción viene primero (consultores-drivers-coaches/mentores) y la implantación después (técnicos y especialistas). Quizás por esto no creo demasiado en el término "Scrum de guerrilla", dado a que 'los equipos llegan con la idea delirante de un nuevo marco de trabajo', para aplicar técnicas minimalistas de gestión de tareas. ¿Pero a donde está el valor de lo que hacen?.
Allí pega bien tu comentario:
"El truco está en que el equipo ofrezca a la cabecera de la organización los resultados que espera y en que se sepa gestionar la 'doble ciudadanía' con realismo y practicidad (no pueden ignorar las exigencias de la organización en cuyas manos se encuentra su futuro laboral y permanencia pero tampoco traicionar al equipo)".
Podría creen quizás en "Agile de Guerrilla", donde se discuten Valores y Principios, y se contrastan con la cultura organizacional actual y nos contrasta a nosotros mismos en nuestro modo de funcionamiento.
No podré creer nunca en las discusiones basadas en la defensa de un mecanismo de trabajo restrictivo en cualquier medida, como Scrum u otros.
Entonces, según mi perspectiva del 'estado del arte de Agile', hay suficiente evidencia para decir que el problema de una cultura 'buttom-up', donde la iniciativa es de los equipos, podría ser que tal vez los equipos solo buscan alivio a su sobrecarga, pero no entregan valor;
Es lógico, están cansados de los sistemas de trabajo pesados y burocráticos y de los malos resultados, por supuesto. Pero ésta cultura de guerrilla es la que los inhabilita, por cuanto pasan años en discusiones vanas desde la falta de conceptos claros (missconceptions) y falta de entendimiento (lack of undurstanding) de esos conceptos, y pueden dejar a la organización huérfana de prácticas ingenieriles y provocar caos, solo por no entender que todo se trata del cliente y no del individuo trabajador y/o de la organización.
Hace poco Tobías Mayer y yo discutíamos en Twitter a cerca de que las organizaciones que no son Agiles no son competitivas. Recuerdo haberle dicho que no existe un beneficio real en capacitar a la capa operativa, sin que previamente se capacite el upper-management.
Tobías me hablaba de capacitar a la gente y transformar a la organización completa en Agile, o "dejarla morir...".
Claro, al decir capacita a la gente, se refirió a Managers, Owners, Leaders, y todos los que conforman una organización.
Entonces, estoy convencido que nos encontramos en una 'Etapa de Madures de Las Metodologías Agiles', lo suficientemente evolucionada como para evitar la aparición de silos, equipos de guerrilla, y proporcionar principios y valores Agiles, desde el convencimiento cultural de los managers.
Nada de esto tiene que ver con un framework que puedas elegir para gestionar el trabajo. Todo esto tiene que ver con un nuevo paradigma.
Saludos, Javo.