Se pueden emplear técnicas scrum, sin cultura scrum

El resultado de scrum depende del grado en el que se compaginan sus dos componentes:

• Técnicas y prácticas empleadas para producir el resultado de forma incremental y continua.
• Valores y  cultura de la organización.

Usar técnicas y prácticas ágiles en una organización sin cultura ágil, no es propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de vida incremental, o lo que se podría llamar “agilidad técnica”.

La agilidad técnica es adecuada para trabajos en los que por su mecanicidad resulta más eficiente basar la calidad y homogeneidad del resultado en ingeniería de procesos, que en el conocimiento profesional de las personas que lo realizan. En este sentido, la agilidad técnica resulta apropiada cuando la entrega temprana y el incremento continuo son un valor relevante para el cliente.

scrum_o_ingenieria_concurrente

Agilidad técnica y scrum

Sin embargo, hay entornos profesionales donde la innovación y el ingenio son imprescindibles para aportar verdadero valor al producto. En estos casos, el conocimiento profesional de las personas que realizan los distintos procesos es fundamental, y un ambiente scrum potencia el talento de equipos compuestos por personas competentes y motivadas. Esto es lo que se conoce como Agilidad.
La potencia de scrum radica en cómo gestiona el ciclo de vida de vida y la aportación de valor al producto:

Ciclo de vida

Scrum no tiene como objetivo entregar el producto completo y terminado en el tiempo y con el coste previsto, sino suministrar lo antes posible un producto mínimo viable e incrementar su valor a través de iteraciones de desarrollo breves y continuas.

Valor del producto

El valor del producto depende y es proporcional al conocimiento profesional de las personas que lo desarrollan, a diferencia de la producción industrial que confía el valor del resultado al “know how” explicitado en los procesos y la tecnología empleados.

 

La gestión de un ciclo de vida que incremente el producto de forma continua e iterativa, se consigue aplicando determinadas técnicas y prácticas.

Sin embargo la aportación del conocimiento necesario a través de las personas, no se logra por emplear determinadas técnicas, sino creando ambientes de trabajo scrum para atraer y hacer brotar el talento.

Técnicas y prácticas:

El ciclo de vida ágil se caracteriza por la entrega temprana de valor, y su incremento continuo en periodos breves.

Los retos que plantea el ciclo de vida ágil son:

1.- Definición del producto mínimo viable: Funcionalidades suficientes para lanzar el producto, y forma en la que se deben integrar.
2.- Gestión de la evolución continua de los requisitos.
3.- Monitorización y mantenimiento de un flujo de entregas de valor constantes.

El conjunto de prácticas y técnicas ágiles proporciona el inventario de recursos profesionales para gestionar estos retos.

Así por ejemplo, para representar y gestionar la visión del producto, es habitual el uso de pilas de producto, estimación en la pared, mockups, etc.
Las prácticas para la definición y gestión de avance en sprints, o las empleadas para mantener un flujo continuo de tareas con técnicas de gestión visual kanban, resuelven la monitorización del avance y el mantenimiento de un flujo constante de entregas de valor, etc.

Valores:

Que el principal responsable del valor entregado al cliente sea el conocimiento profesional de las personas, implica rasgos culturales de la organización importantes:

1.- Entrega de valor como objetivo.

Un ambiente scrum no centra el objetivo en el valor propio, sino en el entregado al cliente. No quiere esto decir que la organización no obtenga beneficio por su trabajo, sino que éste se considera una consecuencia, no un fin; es la consecuencia de la entrega continua de valor al cliente.

2.- Trabajo en equipo.

La interacción de los miembros del equipo, la difusión del conocimiento compartido y la fertilización cruzada de las ideas multiplica la potencia del aporte de las personas: el talento.

3.- Excelencia profesional.

La motivación y el perfil profesional de las personas de la organización, debe ser lo más alto posible.

Implicación del cliente.

Para mantener un ciclo de vida incremental con un flujo continuo de producción es necesario emplear prácticas ágiles.
Si además se necesita potenciar el talento de las personas, también son necesarios determinados rasgos culturales en la organización; pero siempre es imprescindible la implicación del cliente.
La comunicación e implicación del cliente con el equipo del producto es necesaria, porque la entrega continua requiere feedback continuo de su parte.
Si además no se trata de agilidad técnica, sino de agilidad, el equipo debe conocer y compartir la visión del cliente.

 

tecnicas_valores_implicación

 

Lo que entendemos por Scrum

1.- Rugby

rugbyFormación de rugby.

Scrum es el término que define a la formación más reconocible del rugby, en la que ambos equipos, agazapados y atenazados entre sí, empujan para obtener el balón, y sacarlo de la formación sin tocarlo con la mano.

2.- Gestión

2.1.- Ambiente de trabajo ágil autoorganizado

nonaka

En 1986 Nonaka y Takeuchi dan dimensión polisémica al término deportivo Scrum al emplearlo para bautizar los principios de desarrollo que identificaron en las empresas tecnológicas más innovadoras(1).
Scrum, en la concepción original de Nonaka y Takeuchi, se caracteriza por el protagonismo de equipos brillantes, autoorganizados y motivados, que abordan el desarrollo sistemas complejos y por tanto imprecisos, solapando las fases del desarrollo.

2.2.- Metodología para desarrollo de software

scrum

 

En 1995 Ken Schwaber presentó en OOPSLA (Conferencia anual “Object-Oriented Programming, Systems, Languages & Applications”) una metodología de desarrollo de software, basada en un ambiente scrum y a la que también denominó scrum.

 

 

 

2.3.- Marco para desarrollo de software basado en la metodología scrum de Ken Schwaber

marco_scrum

En 2005 Mike Cohn, Esther Derby y Ken Schwaber constituyeron la organización “Scrum Alliance” para definir un marco de trabajo específico para desarrollo de software, basado en la metodología Scrum, y al que también denominan Scrum.

 

En Scrum Manager empleamos el término Scrum en el significado original de Nonaka y Takeuchi, como un ambiente de trabajo caracterizado por la composición de equipos autoorganizados que trabajan de forma ágil: con autonomía, solapamiento de las fases de desarrollo, y compartiendo el conocimiento y aprendizaje de forma abierta.

(1) 1986 The New New Product Development Game, Harvard Business Review

Escalar Scrum a toda la empresa

Modos de escalar la agilidad a toda la empresa

Escalabilidad Scrum Manager

Scrum ha demostrado que es capaz de duplicar la eficiencia del trabajo del equipo, y el valor de sus productos, y ahora se enfrenta al reto de aportar esa mejora al conjunto de la empresa, escalando de “modelo de equipo” a “modelo de organización”.

Muchas empresas tradicionales quieren ser “empresas Scrum”, pero sin alterar su cultura y métodos. A este tipo de empresas los equipos y las formas de Scrum les inquietan, porque les parecen más próximos a la idea de comuna, que a la de empresa.

Por eso las propuestas de un Scrum escalable que les ofrecen los asesores son marcos híbridos de procesos-agilidad: SAFE, Nexus, Disciplined Agile… que sobre el formato de “proceso-de-siempre” y con una aparente fachada de agilidad, aportan dos beneficios notables:

  • Incorporan prácticas y técnicas ágiles, con las que se obtienen las ventajas de la ingeniería concurrente o “agilidad técnica,” que es prima hermana de la agilidad, y que para muchas empresas resulta más que suficiente.
  • Imagen de agilidad. Algunas es lo único que pretenden.

Sin embargo las empresas de nueva hornada, con estructuras planas, ven en estos marcos híbridos “CMMIs” con pieles de cordero, y prefieren el concepto original y flexible de Scrum, por lo que no optan por este camino de escalar Scrum, sino por el de “desescalar” o  “fractalizar” la organización.

La escalabilidad fractal, es la forma de llevar Scrum a toda la empresa sin sacrificar su verdadera potencia: los valores y flexibilidad del Scrum original.

Para que esto sea posible, los equipos scrum tienen que ser equipos fractales, y la organización, una organización fractal.

Equipos fractales es un modelo de empresa desarrollado por Michel Henric-Coll.

Más información: Equipos FractalesLa Organización Fractal.

Scrum funciona con capacidad, trabajo y compromiso.

Es posible que en determinados trabajos se necesiten personas con una de estas fortalezas:

Su capacidad de trabajo:
Dame gente trabajadora, dispuesta a echar horas o fines de semana“.

Su talento:
No necesito gente para calentar la silla; quiero brain time, no body time“.

O su nivel de compromiso:
Quiero gente que sienta los colores, que se sienta empresa“.

Sin embargo un equipo Scrum no funciona por su dedicación, talento o compromiso, sino por la combinación equilibrada de los tres.
De hecho no es otro el motor de Scrum: gente capaz, comprometida y laboriosa, trabajando en equipo.

perfil_equipo_scrum

 

Diferencias clave entre un “proyecto tradicional” y un “proyecto scrum”

diferencias_scrum

Descargar en formato pdf

Targeted Scrum

Esta es una personalización del marco estándar de scrum, propuesta para mitigar sus dos debilidades principales: poca atención a la visión global del producto, y dificultad para implicar al propietario del producto.

Los autores son David P. Harvie y Arvin Agah, y es el modelo de personalización de scrum que enseñan en el curso Agile Software Development en la Universidad de Kansas con el nombre “Targeted Scrum”, y que presentarán el mes que viene en el 19th ICCRTS: “Conceptual Design of Targeted Scrum: Applying Mission Command to Agile Software Development

Las debilidades de scrum, que evita esta personalización son:

  • Escasa atención a la visión del producto:
    • Scrum centra la gestión de los requisitos en la gestión de la pila del producto, con la única condición  para comenzar de disponer de historias suficientes para el primer sprint. (1)
    • La estrategia del producto tampoco se contempla en las reuniones de planificación de sprint, cuyo foco es preparar el sprint, pero sin atender a la estrategia del producto y su evolución. (2)
  • La otra debilidad puede ser (es con frecuencia) la insuficiente participación e implicación de la persona que desempeña el rol de propietario del producto.(3)

Tomando ideas del nuevo concepto del  ejército americano “Mission Command” (4) los autores personalizan el marco estándar de scrum introduciendo:

  • Dos nuevas reuniones o eventos: “Diseño inicial de producto” y “Diseño de producto”
  • Un nuevo artefacto: “Estado final del producto y líneas de esfuerzo”.

 

targeted scrum framework

 

Targeted Scrum

 

(1) Hochmüller, E., Mittermeir, R.T. (2008). Agile process myths (págs.5-8). ACM – New York. ISBN 978-1-60558-021-0
(2)Drury, M. Conboy, K. Power, K. Obstacles to decision making in Agile software development teams (2012)
(3) Hochmüller, E. (2011) The requirements engineer as a liaison officer in agile software development. ACM – New York. ISBN 978-1-4503-0890-8
Hoda, R. Kruchten, P. Noble, J. Marshall S. (2010) Agility in context. ACM – New York. Publicado en OPPSLA’10 págs. 74-88 ISBN 978-1-4503-0203-6
(4) Más información “Mission Command: Un concepto de moda en el Ejército de EUA

 

Ideas para componer un tablero kanban

Las tareas que hay en el tablero ¿son independientes y se pueden completar en cualquier orden, o están relacionadas y corresponden a diferentes fases que deben completarse en un orden determinado? Por ejemplo: diseño, programación, pruebas, integración.

¿El tablero gestiona un avance y entrega al cliente en flujo continuo, o en “pulsos” de sprints?.

Estas son las variables que condicionan el formato general de un tablero kanban para la gestión visual de tareas.

Infografía: Tableros kanban: patrones de composición

 

 

Safe Creative #1401129808482

 

Kanban: claves para mejorar el flujo

Los tableros kanban muestran los trabajos previstos y la situación de los que están en curso. En el desarrollo evolutivo de proyectos TIC, la gestión ágil usa tableros kanban  para gestionar visualmente un flujo de tareas continuo, sin atascos ni tiempos muertos (o al menos para intentarlo 😉
En foros de gestión ágil son habituales los términos: lean y wip, ambos como “claves” para el trabajo con gestión visual kanban. También es  frecuente relacionar kanban con  la filosofía “start-up” y su concepto de “mínimo producto viable” por el que los clientes o los gestores de producto deben priorizar los trabajos que necesitan para, con los recursos de que disponen, desarrollar el mayor valor de producto en el menor tiempo.
Este ideograma muestra a modo de mapa de situación las relaciones entre kanban, lean, WIP, priorización de tareas y la teoría de gestión de colas.
Kanban

Los tres conceptos básicos que hay detrás de: cascada, agilidad, agilismo, scrum, kanban, cmmi, pmi acp, lean, etc.

Desde los años 80 se han desarrollado tantos modelos de procesos, marcos y prácticas de trabajo para mejorar la calidad y la eficiencia en los proyectos de software, que resulta útil trascender las etiquetas y llegar a la base de los principios que subyacen, y las estrategias con las que los desarrollan; de forma que con tres conceptos (desarrollo, trabajo y conocimiento) y dos modelos de gestión (predictiva y evolutiva) se despeja y simplifica el aparente laberinto de modelos de procesos, marcos o prácticas de trabajo a los que nos referimos: CMM-SW, CMMI, PMBOK, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, LEAN, KANBAN, TDD, etc..

 

diagrama_conceptos

Los conceptos que se combinan en los distintos marcos y estrategias son:

1.- Desarrollo

desarrollo

  • Completo: La descripción de lo que se desea obtener está disponible al inicio del proyecto, es completa y detallada, sirve de base para estimar el plan del proyecto: tareas, recursos y agenda de trabajo. Durante la ejecución se gestiona su cumplimiento.
  • Incremental: La descripción de lo que se desea obtener no está disponible de forma completa y detallada al inicio: se complementa y evoluciona en paralelo al desarrollo, que genera el resultado de forma incremental y que se puede gestionar con dos tácticas diferentes:
    • Desarrollo incremental continuo: Empleando técnicas para lograr y mantener un flujo continuo de desarrollo de funcionalidades o partes del producto que entrega de forma continua al cliente.
    • Desarrollo iterativo: El marco de producción emplea técnicas de tiempo prefijado o timeboxing para mantener la producción de incrementos del producto de forma cíclica y continua. Este es el marco de producción empleado en scrum estándar, que define como sprint a cada iteración de desarrollo al final de la cual se produce un incremento del producto.

2.- Trabajo

trabajo

  • Secuencial (cascada): Secuencia las tareas en fases, cada una de las cuales comienza al terminar la anterior y con el resultado que se ha obtenido en ella. El ejemplo más habitual es el ciclo de cascada definido en Ingeniería del software con las fases de requisitos, análisis, diseño, codificación, pruebas e implementación.
  • Concurrente: Solapa en el tiempo los diferentes tipos de tareas. Siguiendo con el ejemplo de ingenería de software, la definición de requisitos, el análisis, la codificación y el despliegue del resultado se realiza y revisa de forma simultánea y continua.

3.- Conocimiento

conocimiento

Principal conocimiento empleado,  protagonista de la calidad del resultado.

  • El conocimiento o know-how protagonista de la calidad del resultado se encuentra en mayor medida en los procesos y la tecnología empleada. “La calidad del resultado depende de la calidad de los procesos empleados“.
  • El conocimiento o know-how protagonista de la calidad del resultado se encuentra en mayor medida en el conocimiento tácito de las personas que lo consltruyen.

 

Gestión predictiva

gestion_predictivaModelo de gestión de proyectos cuyo objetivo es ofrecer resultados predecibles: desarrollar el producto previsto en el tiempo previsto e invirtiendo los recursos previstos. Emplea una estrategia de desarrollo completo con prácticas de planificación tradicional los principales referentes en el desarrollo de conocimiento para este tipo de gestión son PMI e IPMA y los modelos desarrollados (CMMI, ISO 15504, SPICE entre otros) emplean ingeniería secuencial y producción basada en procesos.

 

Gestión evolutiva

gestion_evolutivaModelo de gestión de proyectos cuyo objetivo es la entrega en el menor tiempo posible un producto mínimo viable, e incrementar su valor de forma iterativa y continua. Emplea una estrategia de desarrollo incremental, que puede obtener con tácticas iterativas o de mantenimiento de flujo continuo, y un modelo de trabajo de fases solapadas. Puede emplearse con producción basada en procesos (ingeniería concurrente) o con producción basada en personas (agilidad).

Es importante esta distinción porque sin ella se generan situaciones confusas que llegan a considerar agilidad a la simple aplicación de un marco de desarrollo estándar de scrum (ciclo de incremento iterativo con roles y artefactos definidos), o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de tareas.
Safe Creative #1307145429864

Scrum Manager y Scrum Alliance: dos estilos diferentes de hacer Scrum

dos_estilos_de_scrum_scrum_manager_590

 

Las dos iniciativas (Scrum Alliance y Scrum Manager) desarrollan y difunden marcos de Scrum para trasladar al sector TIC la forma de trabajo ágil, iterativo e incremental identificada en 1986 por Nonaka y Takeuchi (1) en la industria de manufactura electrónica y tecnológica, y que bautizaron como “avance en campos de scrum” por la similitud con el avance en formación “scrum” de los equipos de rugby.

Y cada iniciativa lo aborda con un estilo diferente.

El modelo de Scrum Alliance (Scrum Master) se basa en prácticas concretas que se deben realizar en un marco definido de artefactos, roles y reuniones. El avance evolutivo del trabajo se realiza a través de iteraciones (“sprints”).

El modelo Scrum Manager se basa en los principios de Scrum(4) Relativiza por tanto la importancia de las prácticas y permite flexibilizar las implementaciones adecuando el modelo de prácticas y distribución de roles/responsabilidades a las características de cada organización. El avance evolutivo del trabajo, por el carácter flexible del modelo, funciona tanto con iteraciones como con desarollo continuo,(2) según las circunstancias de cada proyecto.

La flexibilidad del modelo Scrum Manager requiere mayor experiencia y madurez profesional de las personas que trabajan con él (Se basa más en el valor de las personas que en las prácticas empleadas).

Estas iniciativas ofrecen también estilos diferentes de difundir el conocimiento de Scrum.

La diferencia entre estos dos enfoques nos permite considerar cuál resulta más adecuado en cada caso: si Scrum Master(3),  o  Scrum Manager en función de los diferentes criterios profesionales y las circunstancias de cada proyecto.

(1) New New Product Development Game, Takeuchi & Nonaka 1986.

(2) Incremento iterativo o continuo.

(3) El modelo Scrum Master lo ofrecen tanto scrumalliance.org como scrum.org, que es la escisión en 2008 de la Scrum Alliance de Ken Schwaber por desavenencias económicas. El modelo Scrum Manager se ofrece en scrummanager.net

(4) Scrum Manager contempla el concepto de espiral continua de conocimiento de Nonaka y Takeuchi (Hitotsubashi on Knowledge Management), sin fijar por tanto un marco de prácticas definido, sino una evolución y adaptación desde los principios de la agilidad.