¿Por qué no aplicar Scrum en toda la empresa, considerando a la organización en su conjunto como un todo sistémicamente relacionado?
¿Por qué acomodar la empresa a la «forma» del modelo? Sea la forma de Scrum o de DSDM o de CMMI, ¿Por qué no considerar a las formas como lo que son y emplear los fondos de conocimiento que hay tras ellas para componer el modo de trabajo más apropiado a las características de la empresa y de sus proyectos?
Poner un scrum master en el área de programación de una empresa cuya visión y cultura apunta en otra dirección o sencillamente sin visión, con un área de RR.HH. no alineada hacia una gestión de personal ágil (gestión del conocimiento), con un departamento de marketing o de producto sin implicación en roles de propietario de producto y con áreas administrativas y comerciales trabajando sobre patrones de contratos de planificaciones cerradas… es una combinación peligrosa que suele producir empresas fragmentadas.
Más que implantar scrum en el área de desarrollo, se trata de gestionar la empresa en su conjunto desde los principios de agilidad. Es más una tarea de «Scrum Manager» que de «Scrum Master».
¿Por qué no trabaja el departamento de marketing en un campo de scrum? ¿Por qué los directivos de la empresa no tratan la estrategia de la organización en un campo de scrum? ¿Por qué no es ágil toda la empresa?.
Las siguientes son las líneas directrices de esta visión sistémica en cuyo desarrollo colaboro con Claudia (buena amiga y consultora de procesos de software) y que compartimos aquí con todos a los que os puedan resultar útiles.
El fondo de esta gestión scrum es la síntesis de conocimiento producida por la resolución dialéctica de las iniciativas de procesos (CMMI, ISO, PMI) y de agilidad.
No emplea prácticas de áreas de procesos o patrones ágiles de forma cerrada.
Sobre la base de los entornos de trabajo definidos a finales de los 80, plantea principios que ayudan a la gestión para determinar la forma más apropiada a su organización y su proyecto.
Bases de la gestión Scrum:
- Campo de Scrum» como entorno de trabajo
- Reconsideración del concepto de «personas» y «procesos».
- Flexibilidad para determinar el grado de previsibilidad y valor óptimo para el proyecto, y las posibilidades de la organización.
- Gestión sistémica.
1.- “Campo de Scrum” como entorno de trabajo.
Campos de Scrum, con el significado de este término acuñado por Nonaka y Takeuchi a finales de los 80, para definir nuevas formas de gestión en el desarrollo de productos.
En 1996 Jeff Sutherland y Ken Schwaber definieron un modelo de trabajo que aplica estos principios ágiles de Nonaka y Takeuchi en el desarrollo de software.
Este modelo formal para software definido por Jeff Sutherland y Ken Schwaber marca un protocolo de trabajo para desarrollar software de forma iterativa e incremental, con solapamiento de fases, equipo multidisciplinar y auto-organización.
Este es también el patrón base de Scrum Manager, aunque añadiendo algunas consideraciones:
2.- Visión propia de los procesos y las personas
Tanto la visión de procesos como la de agilidad se desarrollan sobre la premisa de tres elementos: personas – procesos y tecnología. Para los primeros, el valor de los resultados es consecuencia principalmente de los procesos empleados.
Para los segundos, la variable más influyente en el valor del resultado son las personas.
¿Quién tiene razón la tesis (CMM, ISO 15504, PMI…) o la antítesis (XP, Scrum, DSDM…)?
Ambos la tienen, y lo que su síntesis revela es que los procesos y las personas —que cada uno gestiona de forma diferente— encierran dos aspectos diferentes en cada caso, y no uno sólo.
Para nosotros todo lo que se etiqueta como “procesos” no es siempre lo mismo. En algunos casos las personas «ayudan» al proceso, y en otros son los procesos los que «ayudan» a las personas.
En el primer caso el proceso es el protagonista, el que sabe cómo hacer el trabajo y la persona se integra en el sistema como instrumento. Como operario de apoyo.
En el segundo el artífice es la persona y el proceso una ayuda, una herramienta que simplifica aspectos rutinarios para que pueda lograr más eficiencia y no diluir el esfuerzo en rutinas mecánicas.
La principal diferencia entre unos y otros es el tipo de conocimiento con el que trabajan. La clasificación de Nonaka y Takeuchi entre conocimiento explícito (contenido en los procesos y la tecnología) y conocimiento tácito (contenido en la persona).
Otro elemento de producción necesario para desarrollar los productos o servicios son las personas. La tensión entre la producción basada en procesos y la agilidad revela que ambas tienen razón. La primera tienen razón al verlas como mano de obra para asistir a los procesos y las segunda también la tiene, al ver a las personas como talento.
El error es considerar cuál es el modelo de gestión adecuado para este elemento, porque no es uno, sino dos.
Los procesos pueden ser procesos o rutinas. El valor que el sistema necesita de la persona puede ser trabajo o conocimiento.
3.- Flexibilidad entre agilidad y procesos
Considerar que una persona puede intervenir en un entorno de producción como trabajo o como conocimiento, o que un un procedimiento puede considerarse como “proceso” o como “rutina” es una simplificación en blanco y negro de una realidad en color. Son raros los sistemas que encierran todo el conocimiento sólo en procesos y tecnología o sólo en las personas. Por eso mismo también son minoría los entornos de producción en los que puede encajar como solución de talla única la forma de un modelo de procesos o ágil «tal cual».
4.- Considera a la gestión con visión sistémica
Las organizaciones son sistemas interrelacionados e interdependientes.
¿Cuál es el mejor modelo de procesos para el desarrollo de software?
¿La cultura de empresa más adecuada?
¿Las mejores técnicas de gestión de RR.HH:?
¿Las mejores plataformas de progrmación?
¿La mejor estrategia de marketing?
Gestionar de forma independiente y aislada cada parcela produce tensiones y empresas fragmentadas.
La implantación de un sistema de producción Scrum, Extreme Programming o CMMI no es una cuestión del responsable de programación ajena al resto de la empresa.
Las técnicas empleadas, los modelos de calidad, la tecnología, la cultura de la empresa, la gestión de las personas… deben ser coherentes, de forma que se potencien y no se contrarresten.
Un “know-how” adecuado, basado en el conocimiento tácito de las personas, compaginado con equipos desmotivados o implantado en organizaciones verticales no es una buena combinación.
Un método ágil puede resultar idóneo para el tamaño de equipos y de empresa, pero si sus procesos no cubren las facetas contractuales de la adquisición, generará problemas en la validación del producto.
A modo de síntesis, algunas claves para conseguir organizaciones eficientes de desarrollo de software son:
– Personalidad de la organización.
El primer punto de atención es conocer la visión y misión de la empresa y el tipo de proyectos que realiza. Esta es la principal referencia con la que deben alinearse y sincronizarse todas las variables de gestión.
Cuanto más nítida sea la visión, misión, estrategia segmento de mercado y objetivos de la organización, con mayor tino y precisión se podrán combinar los componentes del sistema y orientar la gestión de su funcionamiento.
– Conocimiento de la organización.
Sus objetivos, debilidades y fortalezas. Relevancia del capital estructural y del capital humano para el tipo de proyectos que realiza, y valores actuales de cada uno.
– Conocimiento y visión objetiva de modelos de procesos y prácticas de la industria del software: ISO, CMMI, Métodos ágiles…
– Gestión sistémica.
Huir de soluciones de «receta» basadas en la aplicación de formas o protocolos procedimentados. Trascender al fondo de cada modelo, diseñar acciones estratégicas para la organización evaluando su idoneidad más allá del corto plazo y su coherencia con la organización en su conjunto.
– Revisión y adaptación.
Análisis continuo de los propios métodos y vigilancia del entorno para investigar, desarrollar e innovar tanto en productos como en los propios procesos y formas de trabajo.