El tema del problema de tener muchas reglas, que juntas llegan a formar una Metodología, con M mayúscula, lo hemos tratado varias veces, desde muchos puntos de vista diferentes. Sabiendo el peligro del exceso de reglas es curioso como en nuestro sector, muchas empresas y personas son amantes de tener muchas normas y reglas, todo lo quieren escribir y procedimentar.
Hoy quería tocar el tema de nuevo con una síntesis te problemas de las reglas, incluso puedes tomar este post como una segunda parte de aquel de en vez de reglas y normas por defecto… ausencia de reglas por defecto.
Organizaciones deterministas
Cuanto más reglas pongo más hago que la gente haga sólo lo que dicen las reglas, la improvisación se reduce. Y la responsabilidad de crear respuesta a nuevas situaciones recae en agentes externos, los metodólogos, muchas veces ajenos a la realidad, que tienen que crear nuevas reglas, siempre tiempo después, siempre después de una improvisación.
Mermar la capacidad de improvisación y respuesta de todo el grupo a los problemas inesperados… es un problema.
Elude la responsabilidad de pensar y manda el mensaje de que no eres lo suficientemente listo
Las reglas y metodologías pormenorizadas vienen a decir cómo alguien ha pensado que otros deben trabajar, con independencia de quien esté haciendo una tarea y lo listo, o no tanto, que sea. A gente menos capaz quizá tenga sentido más reglas. En trabajos de alto componente intelectual, como el nuestro… ¿tiene tanto sentido pensar por otros cómo deben hacer las cosas hasta el detalle?
Que alguien haya pensado por nosotros cómo hacer las cosas nos quita la responsabilidad de pensar cómo hacerlas de la mejor manera. Lo cual puede llevar a trabajar no de la mejor manera. Y manda el mensaje de que quizá no somos tan listos como aquel que pormenorizó aquella regla… lo cual es desmotivador.
La búsqueda de que todos trabajemos igual
Un clásico en la defensa de tener Metodologías pormenorizadas y muchas reglas es aquello de que «así todos trabajarán igual» y eso hará que las cosas se hagan más rápido, con menos errores y reutilizaremos buenas prácticas, escritas, que otros podrán usar. Hasta cierto punto gran parte de lo anterior, repetir buenas prácticas, puede ser una buena estrategia… pero escribir reglas y metodologías no es la única ni la mejor manera de lograrlo.
Escribir reglas y Metodologías provoca rigidez, difícil adaptación, y por definición es algo escrito en el pasado, que hay que mantener, que sólo unos pocos actualizan.
En agilidad, y en la época pre-ágil, ya aparecieron muchas maneras de distribuir buenas prácticas, buscar uniformidad, sin necesidad de escribir y detallar: dojos, katas, pair programming (¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?), pair review, mob programming (Mob Programming: un único ordenador para todo el equipo), comunidades de conocimiento, retrospectivas en grupo, etc. No dejes que los anteriores no existan… por tener un documento de reglas.
Terminando
Ya te lo he dicho muchas veces, esto no significa que no haya reglas… significa que debe haber las mínimas. Significa que controles las reglas de nivel superior, las «constrains» que le llaman (difícil encontrar una buena traducción) las reglas de mínimos no las reglas por defecto y para todo.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Hola Javier, estoy de acuerdo en casi todo lo que comentas.
Yo creo que el problema no está tanto en las «metodologías», sino en el «para qué se usan». Como sabes, nosotros nos dedicamos a esto y desde hace años he intentado ayudar en las organizaciones por las que he pasado, siempre con la idea de la metodología como una ayuda y no como un stopper.
En la PAM16 hice una exposición de algo que hemos llamdo el «Cubo de metodología» y allí expliqué las diferentes línea de actuación que llevamos a cabo; no las hacemos por amor al arte, está claro, pero sí las hacemos intentando ayudar a nuestros clientes, somos honestos en esto (http://www.angellozano.com/pam-2016-cubo-metodologia/).
Tu sabes mejor que nadie, los caos que hay montados en muchas compañías, hay tres (o cuatro) que trabajan bien, el resto es caos. Y en este sentido, nosotros llegamos y les ayudamos a entender sus problemas y les plantemoas alternativas de solución.
Nuestro cliente no es el banco o la telco de turno, nuestros clientes son sus áreas de desarrollo, y ahí es donde podemos aplicar nuestro conocimiento y experiencia.
Abrazo!
Por otro lado, estoy en contra de metodologias rígidas, recetas mágicas para hacer las cosas. Quiero marcos, conjuntos de buenas prácticas, enseñanza. Quiero que las personas utilicen bien las recetas, que las cambien y las alteren para su beneficio.
Me gusta mucho Discipline Agile de Ambler, te propone marcos, te propone buenas prácticas y te deja elegir. Cada organización, cada equipo, cada persona tendrá que elegir qué es lo mejor para su situación.
Abrazo (2)
Lo siento Javier, pero no puedo estar más en desacuerdo. Una cosa es imponer reglas, no tener en cuenta la opinión del equipo y tomarlos por tontos; y otra muy diferente es que ellos participen en la elaboración, las revisen en ciclos cortos (cada sprint por ejemplo), forzando un ciclo PDCA rápido, y que esas reglas se documenten.
Escribir reglas y metodologías es sano, permite que la información fluya, promueve la mejora continua y evita volver a caer en los errores del futuro.
Totalmente de acuerdo
Totalmente en desacuerdo en estar de acuerdo. Tu desacuerdo es un acuerdo con el desacuerdo anterior por ende el desacuerdo genera un acuerdo tácito de contraforma y metodológicamente es un acuerdo en el desacuerdo planteado.