Pages Menu
Categories Menu

Posted by on Sep 21, 2016 in General | 4 comments

Agilidad en grandes empresas… ¿Qué opinan los que saben?

El controvertido y maravilloso mundo de la agilidad en grandes empresas. Ese mundo con sus fans, con sus detractores, con sus mentiras, con sus verdades, con sus efectos placebo, en fin, ese mundo.

Cada uno que se dedique a esto de ayudar a mejorar, o hasta implantar, en base a buenas prácticas ágiles tendrá su opinión, pero… ¿qué opinan otros por ahí? ¿qué opinan los que más nombre tienen en el sector?

Acosado por la curiosidad, sin poder dormir aquella noche, me dije “qué mejor que buscar opiniones y consejos sobre agilidad en grandes empresas”. Podían haber sido muchas las que te dejara, pero me ha parecido esta una buena recopilación de opiniones, a ver que te parece (translations by jgarzas of course)….

 

Most common mistake in large-scale “Agile”: not starting by living small-scale “Agile” Second most common mistake: trying to scale.

(Error más común al escalar “agilidad”: no empezar viviendo la agilidad a pequeña escala Segundo error más común: intentar escalarla.)

— Ron Jeffries (uno de los fundadores de eXtreme Programming), aquí la fuente

.

.

If you can’t even do Agile once you can’t scale it!

(Si ni siquiera has podido ser ágil una vez no puedes escalarl)

— Ron Jeffries, aquí la fuente

.

.

Hierarchy is largely about authority and control. Management, often, is about telling people what to do and how to do it. These structures, often, work counter to the self-organization that is central to Agile 

If you take the viewpoint that most of your management structure needs to be replaced […], you’re going to meet a lot of resistance. If your mission is to sell a lot of SAFe or Kanban, […], you might wisely choose not to go directly up against the hierarchy. 

The management structure of a company is there to preserve the company, and in so doing, it acts to preserve itself. And, unfortunately, the thing it’s preserving is a thing that needs to be changed, very substantially. 

La jerarquía en gran medida trata sobre la autoridad y el control. El Management, a menudo, trata de decirle a la gente qué hacer y cómo hacerlo. Estas estructuras, a menudo, van en contra de la auto-organización que es central en la Agilidad.

Si tomas el punto de vista de que la mayor parte de la estructura de gestión necesita ser reemplazada […], vas a encontrar mucha resistencia. Si tu misión es la de vender mucho SAFe o Kanban, […],posible y sabiamente decidas no ir directamente en contra de la jerarquía.

La estructura de gestión de una empresa está ahí para preservar la empresa, y al hacerlo, actúa para preservarse a sí mismo. Y, desafortunadamente, lo que se preserva es algo que necesita ser cambiado, muy sustancialmente.

— Ron Jeffries, aquí la fuente

.

.

Scaling frameworks are often used to provide scaffolding for the legacy organization until they can evolve. Bureaucracy or changes in management often cripple and/or destroy agile implementation

Los Frameworks para escalar se utilizan a menudo para proporcionar un andamio a organizaciones “legacy” hasta que puedan evolucionar

Burocracia o los cambios en la gestión a menudo paralizan y / o destruyen la implantación ágil

— Jeff Sutherland (co-creador de Scrum), aquí la fuente.

.

.

We have measures to look at productivity, and one option when these measures get worse and become unacceptable is to descale.

Tenemos medidas de la productividad, y una opción cuando estas medidas empeoran y se vuelven inaceptables es des-escalar.

— Ken Schwaber (co-creador de Scrum), aquí la fuente.

.

.

“Don’t scale agile. Descale your organization. (not exactly sure what that means, but I think I agree…)”

No escales la agilidad. Des-escala tu organización.(no estoy seguro de que significa pero pienso que estoy deacuerdo)

— Henrik Kniberg (autor de Scrum desde las trincheras), aquí la fuente.

.

.

A mindless adoption of the values and principles as offered in the Agile community’s fundamental document, the Agile Manifesto, inevitably leads anyone to conclude that Agile doesn’t scale. At small scale, Agile is great. At large scale, Agile is stupid.

Una adopción sin sentido de los valores y principios que ofrece en el documento fundamental de la comunidad ágil, el manifiesto ágil, conduce inevitablemente a cualquiera a la conclusión de que la agilidad no escala. A pequeña escala, la agilidad es grande. A gran escala, la ágilidad es estúpida.

— Jurgen Appelo, fuente aquí.

.

.

Atrevido y extremadamente corto resumen: antes de llevar la agilidad a una estructura gigante ponte a aligerar la estructura.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

4 Comments

  1. Muy interesante en general, reseño:
    “Don’t scale agile. Descale your organization. (not exactly sure what that means, but I think I agree…)”

    No escales la agilidad. Des-escala tu organización.(no estoy seguro de que significa pero pienso que estoy deacuerdo)

    Y me quedo con este porque SI lo entiendo o al menos creo que lo he sufrido; para no variar doy mi opinión personal sin ningún respaldo más que mi pobre espalda.

    Entiendo que al final escalar una empresa muchas veces solo se traduce en crecer en jefes y jerarquía y burocracia (burocracia que siempre tiene sentido negativo, pero su raíz era positiva allá en tiempos pasados mejores).
    Para crecer en jefes muchas empresas no crecen en personal a priori; sino que suben el sueldo a fulanito jodiendo a menganito y todo lo que viene a continuación muy previsible.
    ¿No será mejor crecer en bella forma de onda en el estanque que como un molesto barrillo de pus?
    No me extiendo más, creo que la idea central de lo que quería contar se capta.

    • Yo lo entiendo similar, reduce jerarquía, departamentos, ayudantes, y aumenta la auto-organización…

  2. Exacto la agilidad debe estar en el adn de la organización y por ende en todos y cada uno de los que la conforman, no es una moda, es un forma de vida, te das cuenta porque empiezas a cambiar hábitos y comportamientos. Y a ver que realmente la inteligencia no está y la eficiencia no está en que tantos planes y documentos generas, sino lo que entregas para que otros puedan usarlo y se sientan a gusto usandolo. Es mi humilde opinión.

  3. Hola Javier,

    me gusta ver que vuelves con energía. He estado un poco “off” por el nacimiento de mi hijo y a la vuelta veo 20 posts. 🙂

    Este es un tema amplio, se podría escribir mucho. Citas a los “grandes” (¡eso siempre está bien!). Básicamente yo veo dos enfoques: los que quieren escalar “bottom-up” y los que van con un modelo estructurado que adaptar (SAFe), que era lo mismo que Leffingwell proponía con RUP. Y me temo que ambas posturas son difícilmente reconciliables.

    En Scrum.org estamos claramente por el bottom-up. Tener rodada la agilidad en equipos pequeños facilita que aquellas cosas que funcionan y que no funcionan en el contexto de cada organización se podrán propagar a los demás equipos. Es lo que propone Cohn en su libro “Succeeding with Agile”. Hay una frase provocativa (ahora no caigo en el autor) que dice: “If you scale shit, you will have scaled shit”. 😉

    Hay mucha gente que pone SAFe a caer de un burro, porque supone proponer una solución “sencilla” a un problema “complejo”, y eso es un error según el modelo Cynefin. Es el mismo error de las metodologías pesadas para un único equipo, pero aún peor porque se escala a algo más complejo aún, como es una organización. Yo coincido en parte con Sutherland, es un andamiaje que encamina las cosas, pero si las organizaciones grandes que lo adoptan ni entienden que es la agilidad, ni quieren cambiar radicalmente, el beneficio de SAFe va a ser muy pobre respecto a las promesas que hacen.

    El modelo Spotify es más de plantear un ecosistema donde los equipos tengan bastante libertad. A mi personalmente me gusta bastante, pero sinceramente no lo veo en organizaciones jerárquicas que no hayan tenido MUCHA experiencia con la agilidad.

    Finalmente, de-escalar se refiere a reducir estructura (ágil o tradicional). En el libro “Scrum: double the work in half the time” Sutherland describe algunos ejemplos brutales, como el del FBI. Y yo me atrevería a decir que aplican a más de una startup exitosa que conozco.

    ¡Saludos a todos!

    alex ballarin @ http://www.itnove.com

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This