Agilidad en la empresa: ¿en el producto, en la cultura o en todo?

En las empresas conviven dos dimensiones: una operativa, que realiza los productos o servicios de la compañía; y otra organizativa, que define y gestiona la cultura, estructura y modelo de gobernanza con el que se rige.

A menudo se aborda el escalado de agilidad de forma conjunta en ambas dimensiones. Se introducen modificaciones tanto en la gestión de los proyectos y los procesos de desarrollo, como en la cultura y el modelo de gobernanza.
Se actúa así, porque se considera que la agilidad implica cambios operativos y organizativos de forma simultánea, y por tanto no se valora por separado:

  1. Si el producto, servicio o proyecto de la empresa se puede construir de forma evolutiva, y si proporciona ventajas a los clientes o la comercialización.
  2. Si la propiedad de la empresa desea cambios en la estructura o en el modelo de gobernanza, y si es consciente de las implicaciones de esos cambios.

Cuando no se necesita o no se puede entregar de forma incremental, escalar la agilidad en la empresa no consiste en institucionalizar un marco de prácticas de desarrollo evolutivo, sino estructuras organizativas fractales y modelos de gobernanza dinámica.

Es el caso, por ejemplo, de AES (sector energético, 40.000 empleados), Heiligenfeld (Hospitales de salud mental, 600 empleados) o Zappos.com (venta de zapatos on line, 1.500 empleados)

Si el objetivo de la empresa se centra en el beneficio de los accionistas. Si basa el know-how de sus productos en ingeniería de procesos antes que en el conocimiento tácito de las personas, el escalado de la agilidad fracasará si implica introducir no sólo prácticas de agilidad técnica, sino también un nuevo paradigma cultural.

Diagrama cartesiano para reflejar en el eje vertical la agilidad en la dimensión organizativa, y en el eje horizontal la agilidad en la dimensión operativa, reflejando de esta forma 3 patrones de agilidad posibles: Agilidad organizativa, agilidad técnica y agilidad dual.

(*) Saber más acerca de cultura naranja, verde o teal.
Continue reading “Agilidad en la empresa: ¿en el producto, en la cultura o en todo?”

Agilidad: ¿Empresa naranja o verde?

Puede ser un error emplear el mismo marco de escalado de agilidad para todas las empresas. En organizaciones naranjas puede bastar un marco técnico para iterar haciendo ingeniería concurrente. En organizaciones verdes, o que quieren evolucionar al verde o teal se necesitará también evolucionar la estructura y la cultura.  Pero ¿de qué va esto de “naranja”, “verde” y “teal” ?

Este artículo esboza la base teórica: el modelo de paradigmas culturales de Frederic Laloux(1).

Según Laloux, la evolución de los valores y principios culturales de la humanidad viene marcando el tipo de organizaciones que creamos.
Aunque el estudio de los distintos paradigmas culturales contempla modelos de organización prehistóricos, a los que denomina infrarrojo y magenta, los que nos interesa conocer desde la perspectiva de gestión de las organizaciones actuales son los cinco últimos. Los denominados: rojo, ámbar, naranja, verde y esmeralda o teal.

Diagrama que muestra la duración de los paradigmas culturales: El infrarojo desde la prehistoria hasta unos miles de años antes de Cristro. El magenta, desde las primeras civilizaciones hasta los albores de la historia, y la aparición posterior del rojo, ámbar, naranja. verde y teal, y cómo en la actualidad se da la convivencia de estos 4 últimos. Continue reading “Agilidad: ¿Empresa naranja o verde?”

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