scrum studio

Scrum Studio, una breve introducción

Esto de la transformación digital no es nuevo. Es simplemente la última forma de denominar la búsqueda de ciclos rápidos de feedback y la adaptación hacia y en torno al cliente. En esa línea, todo es transformación digital. Y nada lo es.

Más allá del debate filosófico, lo que es una realidad es que la tecnología juega un papel fundamental dentro de esa transformación digital. Y para eso hay que escalar las iniciativas tecnológicas. No es fácil cuando IT ha sido vista como un centro de coste -un mal necesario- durante los últimos 20 o 25 años en la mayoría de las organizaciones.

Las conversaciones en torno al escalado y gestión de los productos de Software cuando hay involucradas 20, 30 o 100 personas han sido frecuentes en la comunidad y han generado un debate airado. En el video más arriba, introduzco los conceptos de escalado vertical y escalado horizontal y como Nexus o Scrum Studio pueden ayudar a resolverlos.

Lo que está por venir en corporaciones ágiles: Bimodal IT y Scrum Studio

En Febrero del año pasado, Gartner sorprendió con el anuncio de Bimodal IT, una herramienta que ya han estado usando en clientes como Luxottica. Para quien no sepa qué es Gartner, aparte de una consultora muy potente, es uno de los grandes think tanks en innovación relacionada con IT; un nombre en el que muchos confían para poner en marcha cualquier aspecto relacionado con su tecnología.

En el fondo, las grandes consultoras no están más que dando a sus clientes algo que muchos esperaban y que Scaled Agile Framework ha sabido capitalizar muy bien: Un modelo de gobierno que les permita simplificar y entender los cambios que sus clientes demandan.

Pero esto no es todo. A finales de 2016, Deloitte sorprendía con su mapa de metro de prácticas ágiles. Un cajón de sastre donde todo cabe y parece que se puede escoger voluntariamente que prácticas implementar. ¿Alguien recuerda RUP? (Por cierto, creación también de Dean Lefingwell).

Sin embargo, esto no es nuevo. Hace 10 años, Deloitte también anunciaba el conjunto de prácticas ágiles para la gestión de la vida del software. ¿Alguien lo conocía?

Una de las críticas más interesantes ha sido la de Ethar Alali, que con buen fundamento explica que las prácticas ágiles son mucho más difusas de lo que se transmite con el mapa de agilidad de Deloitte.

Bimodal IT

La premisa en torno a Bimodal IT es que las grandes organizaciones pueden funcionar en dos modos: Un Modo 1, tradicional, orientado a todas las operaciones del día a día, que es seguro y fiable, cumple con las expectativas del negocio y además es crítico para estas. El Modo 2 es ágil. Cumple con la premisa de que el mundo digital es cambiante y necesita de exploración. Simple. Lo que hemos hecho siempre es el Modo 1 y lo nuevo entra en el modo 2.

Las críticas no se han hecho esperar. Desde el daño que el modelo hará a iniciativas existentes hasta la acusación de que destruirá corporaciones que no podrán adaptarse. No creo en ninguna de las dos.

Jez Humbley ha escrito un artículo sobre los tres fallos del modelo de Gartner. Su crítica principal es una que parece estar muy asentada en la industria: Para poder ser ágiles hay que perder seguridad y estabilidad.

Creo que hay una necesidad en el mercado. Una necesidad que ha sido cubierta en parte por SAFe y que muchas corporaciones siguen buscando como cubrir. Es la de tener un modelo de gobierno que permita tomar decisiones estratégicas y mantener la agilidad.

Aquí se puede descargar el paper de Bimodal IT (requiere registro). Merece la pena echarle un vistazo porque desgrana las necesidades de las corporaciones actuales, más allá de lo que nos guste o no del modelo. Parece que el mercado está suficientemente maduro para entender que una organización no se transforma en semanas o meses.

Scrum Studio

Por otro lado, Ken Schwaber y Dave West anunciaron en Scrum Day London la formalización de Scrum Studio como herramienta para construir una organización ágil en un sistema ya existente. La idea es, en lugar de transformar toda una organización, crear una capacidad interna que sea ágil y que, al final, tenderá a engullir a la antigua organización.

Scrum Studio nace con la idea de proporcionar a esas mismas organizaciones que ahora miran a SAFe® o a Bimodal Studio una solución que parte de un corazón ágil. Para formalizar un Studio, necesitamos partir de un Head of Studio que tenga financiación propia e independiente. Una serie de servicios compartidos. Uno o más equipos haciendo Scrum o Nexus. Por último, métricas con EBM y un Scrum Development Kit (SDK).

El Studio es independiente de la capacidad existente de la organización para desarrollar software y se rige por un código ético y de calidad que asegura una alta calidad de software a la vez que agilidad. Eso permite a una corporación en un proceso de transición poder mejorar su capacidad de innovación y adaptación al mismo tiempo que hace (o no) su proceso de transformación interna.

En Junio del año pasado estuve en Boston, colaborando con Ken Schwaber, Dave West y el resto del equipo de Scrum.org para intentar darle una vuelta más a Scrum Studio antes de un lanzamiento al mercado. Eso supone, al igual que con Nexus, ponerlo a prueba en clientes reales que quieran adoptar un modelo de Innovation Studio.

Similitudes y diferencias

Las similaridades entre Scrum Studio y Bimodal IT son palpables y personalmente tengo que ver más antes de tener una opinión clara. Durante mi labor como Agile Coach en la transformación digital de Capital One Bank UK, utilizamos el modelo de Scrum Studio extraído del libro Software in 30 days de Schwaber y Sutherland; tiene muchas ventajas y algunos inconvenientes.

Por ejemplo, la velocidad de arranque. No tener que modificar estructuras ya existentes. Encaja perfectamente en organizaciones que han tendido al outsourcing.

Está claro que existe una necesidad -siempre ha existido- de proporcionar un modelo de gobierno a las organizaciones que deciden adoptar agilidad. La realidad es que en una organización de 5, 10 o 20.000 personas es harto complicado manejarse con equipos Scrum. Estos modelos toman lo aprendido de organizaciones que llevan 1.000 años adaptándose, las de defensa.

Para todo aquel que haya pasado por el servicio militar, esto no le sonará a nuevo. El modelo del ejército es un modelo de alineación en la estrategia y descentralización en la táctica. Mientras que un Nexus o un equipo Scrum pueden adaptarse para tener éxito, un Studio permite tener una alineación estratégica con el resto de la corporación.

En cualquier caso, es interesante ver como la agilidad ha llegado, por fin, al mundo de la corporación. Se avecinan tiempos interesantes. Este año hablaré más de Scrum Studio por aquí.

Si quieres leer más sobre Scrum Studio, te recomiendo este artículo de Barry Overeem. También tienes la presentación que dio Dave West en Scrum Day Europe.

Por último, un artículo muy elaborado de Juan Quijano sobre todo lo que conlleva la agilidad hoy día.

#ScrumClinic: Marcos de trabajo en grandes organizaciones y proyectos en Scrum

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.