Mito 1: Scrum solo funciona con pequeños equipos y no se escala a la empresa
Un equipo de desarrollo de Scrum supone que debe incluir de 5 a 9 personas con las habilidades necesarias para llevar a cabo el trabajo requerido. Esto es para que puedan desarrollar satisfactoriamente un producto completamente funcional y completamente probado que está bajo desarrollo en cada sprint.
Sin embargo, no existen restricciones en el número de equipos multifuncionales que pueda haber para un producto. Un producto complejo puede requerir más de 5 a 9 personas para terminar el proyecto en un tiempo razonable.
La respuesta es utilizar múltiples equipos de 5 a 9 personas, todos trabajando para un Product Backlog común (El primer lanzamiento en la planeación de Scrum) y adoptar uno o más patrones para comunicación a través de los equipos de iteración a iteración.
Por otro lado, escalar Scrum en la empresa puede ser un reto, pero una organización grande no es un obstáculo insuperable para la adopción de Scrum. La cuestión tiene más que ver con la cultura de la organización que con el requisito de utilizar equipos pequeños.
Mito 2: Scrum no funcionará en una agenda y presupuesto establecido
Este mito es muy común y entendible, debido a que la filosofía de Scrum, que es planear y ejecutar a través de una “Elaboración Progresiva” o “Rolling Wave”
La planeación de una “Rolling Wave” es una forma de elaboración progresiva donde el trabajo que debe ser completado en un tiempo cercano es planeado a detalle, y el trabajo más lejano es planeado en un alto nivel, pero los detalles se van haciendo conforme va pasando el periodo actual.
Este enfoque está en contraste con un enfoque tradicional, donde se construye un plan elaborado por adelantado que contiene los detalles de todo el trabajo que hay que hacer, y la salud y progreso del proyecto se mide por la desviación de este plan previsto.
Scrum está basado en un conjunto de supuestos completamente diferentes. Scrum asume “Si algo es seguro es el cambio. El mundo que estamos planeado hoy no existe mañana”. Scrum reconoce que no se puede determinar razonablemente todos los detalles de la obra por adelantado y no vamos a tener una comprensión total sin importar cuánto tiempo hablamos de ello, hasta que empezamos a construir algo.
Scrum: Un enfoque que agrega valor
Scrum provee su propio conjunto de métricas (basadas en observación empírica de los resultados del sprint) que permite a los planeadores estratégicos a monitorear la salud de proyecto y el progreso, mejor que con los métodos tradicionales.
Scrum pone el énfasis en la entrega de valor, eliminar las características que afecten negativamente al ROI y evaluar continuamente qué es lo más importante en el proyecto. Scrum entregará el mejor producto posible, en tiempo y dentro del presupuesto con la gente que se tiene. Además, Scrum no nos hace esperar hasta la mitad del proyecto para decirnos si estamos bien o mal.
Cuando es apropiado Scrum
El determinar si Scrum es apropiado para nuestros proyectos requiere de dos factores: aceptación de requerimientos y la certidumbre de la tecnología.
Ralf Stacey, profesor de negocios y teorista de dinámica organizacional ilustra esto con la Matriz de Complejidad de Stacey, que divide problemas en diferentes categorías basados en qué tan cerca estamos en los acuerdos sobre los problemas y que tan seguros estamos. Cuando consideramos problemas de desarrollo de software, las variables son qué tan cerca estamos en aceptar los requerimientos y que tan segura es la tecnología que deseamos utilizar.
La Matriz de Stacey
En la parte baja izquierda de la Matriz, estamos en la posición donde los requerimientos están cerca del acuerdo y que la tecnología que planeamos utilizar es segura (esto es, que sea estable, madura y que tenemos mucha experiencia utilizándola) Esto corresponde a los problemas simples. En otras palabras, un proceso definido con un enfoque de planeación ayudará en este tipo de problemas.
De otro lado del espectro, cuanto tenemos poco o nada de acuerdos sobre los requerimientos y la tecnología es mayormente o casi incierta, tenemos “anarquía”. En esta categoría, no hay un proceso o política que podamos tomar para evitar “desintegración y caos” y debemos básicamente evitar la situación por completo.
Scrum, es entonces apropiado para problemas que viven entre la simplicidad y anarquía. Esto, cuando nuestros acuerdos y requerimientos es la variable desconocida, y la tecnología es algo o completamente certera, deberíamos considerar Scrum como un enfoque útil, y es donde normalmente la mayoría de los problemas de desarrollo de software viven.
La clave del éxito de SCRUM
- Debemos tener un problema a resolver.
- Asumiendo que lo que hacemos no está funcionando, Scrum es el deseo de nuestra gente y la organización de querer cambiar, ya que requiere un cambio en nuestra forma de pensar.
- Necesitamos apoyo de todos los niveles de la organización. Gente que reconozca que se necesita un cambio y esté dispuesto a hacer las cosas de una forma diferente.
