Es habitual que lectores del blog y alumnos de los cursos de Scrum y cursos de Kanban me escriban para preguntarme dudas sobre la forma en la que implementan Scrum y Kanban en sus organizaciones. Hasta ahora, siempre he respondido en privado. Estas ideas se agrupan en dos secciones: #ScrumClinic y #KanbanClinic. Si tienes una consulta, mandala a través del formulario de contacto
En el curso aclaramos que son los equipos de desarrollo los que acuerdan las prácticas a emplear y que las «buenas maneras» están bien para comer en una mesa, pero encorsetan a los equipos y limitan su autogestión. En el caso del banco, que ya sabemos que no es un buen ejemplo, al ser líneas ocupadas de elementos distintos, pero englobados dentro de un mismo objetivo (reingeniería de procesos de pagos o cobros), ¿no podría resultar conveniente el articular un marco de trabajo común, aunque fuera laxo? eso facilitaría que los miembros de los equipos pudieran cambiar de proyecto con el fin de prestar apoyo concreto o expandir conocimiento.
Los proyectos bajo scrum, como todos, tienen un comienzo y un final. Cuando el proyecto satisface los objetivos, ¿cómo se articula el mantenimiento de la aplicación?, y hablo de mantenimiento, no de evolución. No veo que tenga mucho sentido el conformar un equipo scrum para dar respuesta reactiva a los problemas que pueda presentar un producto. Por otra parte y abundando en el párrafo anterior, si es un área definida de una organización la que se encarga de esta tarea, el contar con un esquema definido, con una arquitectura congruente entre aplicaciones podría tener la seguridad de que se enfrenta siempre a proyuectos con una estructura homogénea, lo que redundaría en un ahorro de coste al ser el tiempo necesario para familiarizarse con el produco, menor.
Jorge Alarcón, alumno del PSM
Marcos de trabajo comunes
Con respecto a la primera cuestión, hay dos preguntas que responder:
- ¿Si Scrum permite la autoorganización y la capacidad de autogestión de los equipos de desarrollo, cómo fomentamos la participación transversal?
- ¿Cómo evitamos que cada equipo termine usando tecnologías o prácticas distintas que no tienen conexión entre sí?
Veámoslo desde tres puntos de vista: Nivel equipo, nivel producto y nivel organización.
Nivel Equipo: La perspectiva del Product Owner
He publicado en múltiples ocasiones que la labor del Product Owner va mucho más allá de tomar requisitos y que es una pieza fundamental en la optimización de valor y retorno de la inversión que hacemos en el desarrollo de productos.
Una de las herramientas estratégicas de un buen Product Owner es el Total Cost of Ownership: Cuanto me cuesta mantener mi producto vs cuanto me reporta. Mirando la imagen que encabeza este texto, se puede apreciar que los productos que nos interesan son aquellos con un bajo TCO que estén alienados con la estrategia de IT y de Negocio.
Desde la perspectiva del Product Owner, esto supone promover que el desarrollo de producto se alinee con la estrategia global de IT de la organización. Por ejemplo, de establecer el uso de marcos y herramientas comunes a lo largo de toda la organización. Sólo así el Product Owner puede obtener un ROI mayor de la inversión que hace cada Sprint en el desarrollo de producto. Y eso se hace a través de una gestión estratégica del Product Backlog.
El TCO está extraido del libro Managing IT Innovation for Business Value de Intel Press.
Nivel Producto: Desarrollo de productos a escala
Durante el PSM, aprendemos como aplicar Scrum a un equipo de desarrollo. Al final del curso, tocamos brevemente el tema de escalado. Cuando escalamos Scrum -entendido como tener más de tres equipos desarrollando el mismo producto con el mismo Product Backlog– tenemos que extender las técnicas de Scrum más allá de un sólo equipo.
Este es el caso con la autoorganización. En un entorno a escala, la autoorganización y la capacidad de decisión de un equipo están limitados por el resto de los equipos. Por ejemplo cuando usamos Nexus. Hay dos elementos que nos ayudan.
- El primero es una Definition of Done común: La DoD en Nexus es un mínimo común denominador para todos los equipos del Nexus. Luego cada equipo puede restringirla aún más. Eso asegura que se pueda entregar un incremento integrado cada Sprint.
- El segundo es el NIT: El Nexus Integration Team es accountable por la integración del producto. Esto significa que es necesario que las prácticas de los equipos no vayan en contra de otros equipos.
Nivel Organización: Modelos de gobierno ágiles
Una de las razones del éxito de Scaled Agile Framework (SAFe) es que proporciona un modelo de gobierno donde todos los elementos existentes previamente en la organización se ven claramente representados.
SAFe lidia con la incertidumbre inherente a los cambios organizacionales proporcionando respuestas a nivel jerárquico y de gobierno, mientras que LeSS o Nexus no lo hacen. Disciplined Agile Delivery también lo hace. La gente de DAD y SAFe saben que las grandes organizaciones se preocupan menos por Sprints y Retrospectivas. Su foco está puesto en como gobernar el barco.
Scrum.org está apostando por el recién nacido Scrum Studio para el área de gobierno que hasta ahora ni Scrum ni Nexus habían tocado.
Dentro de Scrum Studio, uno de los elementos fundamentales es el SDK (Scrum Development Kit), una amalgama de directrices de desarrollo de Software, herramientas de desarrollo y despliegue que son las que marcan ese marco común en una gran organización.
Ese marco común permite mantener el desarrollo de productos alineado con las estrategias de IT y de Negocio, un TCO controlado y un delivery en candencia, mientras que sigue existiendo un amplio margen para la autoorganización y la autogestión.
Si quieres saber más sobre Scrum Studio, puedes echarle un vistazo a esta presentación de Dave West, CEO de Scrum.org.
Proyectos en Scrum
Ahora la segunda cuestión: Proyectos y mantenimientos en Scrum.
Durante muchos años, se ha utilizado el paradigma del proyecto para el desarrollo de Software. El problema es que el desarrollo de software no acaba nunca. Por eso el enfoque que utilizamos desde Scrum.org es el del paradigma del producto.
Las tres métricas de éxito de un proyecto son Coste, Alcance y Tiempo. ¿No es posible que un proyecto cumpla esas métricas y aún así sea un desastre, que no genere valor alguno? Sí, y hay muchos casos de los que tirar para esta situación.
En cambio, al hablar de productos, nuestro enfoque de métricas cambia hacia ¿Generamos valor o no? Dedicamos los dos días del PSPO a entender como funciona Scrum a partir de la perspectiva del valor generado y no de si se ha hecho en tiempo, alcance y coste.
Scrum sirve para la gestión de proyectos: Un proyecto en Scrum tiene una duración de un Sprint, y todas las fases del proyecto ocurren dentro de ese Sprint.
