Objetivo 2018: menos ágil y Scrum Talk

Hola, y bienvenidos a Scrum Tawk, soy tu anfitrión John ...

Uno de mis objetivos para 2018 es pasar menos tiempo tratando de desentrañar #agile y #scrum. La desambiguación es una madriguera de conejo y las palabras son demasiado blandas. Pasé un montón de tiempo en 2017 repitiendo varios debates. Dudo mucho que haya agregado algo significativo al cuerpo de conocimiento, por lo que supongo que mi tiempo (y tu tiempo) es mejor gastarlo en otro lado.

Así que con eso, voy a estar minimizando la conversación de Agile y Scrum. Este es el por qué…

Primero, es aburrido y repetitivo ...

Y…

  1. Mencionar a Agile rara vez hace avanzar la conversación, especialmente con personas fuera de la burbuja de Agile-nerd.
  2. Cualquier búsqueda en Google arroja el hecho de que muchos de los debates sobre Agile y Scrum tienen casi una década. No se están resolviendo ... la confusión persiste. Yo diría que están empeorando a medida que "Agile" envejece, se comercializa / vende y se convierte en el valor predeterminado. La probabilidad de que vaya a desentrañar esta confusión es muy baja. Algunas almas útiles se han acercado para decirme que estaban teniendo los mismos debates con las mismas personas hace más de 6 años.
  3. Al menos para mí, Agile abarca una serie de patrones, prácticas y perspectivas valiosas. También viene con una gran cantidad de equipaje: casi nadie con quien trabajo se encuentra con Agile por primera vez. Los equipos de alto rendimiento con los que he trabajado seleccionan generosamente de una amplia gama de patrones (muchos fuera del paraguas ágil), por lo que me resulta más útil saltar directamente al corpus completo de patrones. Coincidentemente, estos equipos rara vez dicen que están "haciendo Agile" o "haciendo Scrum".
  4. Abarco tribus, pero en el fondo soy una "persona productora" (UX, gestión de productos, etc.) y un pensador de sistemas intransigentes. Los recientes comentarios de Twitter de varias personas ágiles me han convencido de que Agile (tal como existe hoy) es principalmente para el "desarrollo de software", con una sólida historia de "desarrollo de proyectos de software". Aunque hay muchas llamadas para que "el negocio" y "el equipo" trabajen juntos, siento un límite implícito (y a veces explícito). Se espera que el gerente de producto tenga las respuestas, y el equipo entrega diligentemente cosas utilizables / probadas. Prefiero adoptar una visión más amplia y holística.
  5. Amigos míos de la comunidad de productos / UX han invertido un montón de energía en descubrir cómo "conectar" las mejores prácticas de esas comunidades a las prácticas ágiles. Una vez más, creo que esto subraya un sesgo hacia Agile como la "forma en que los desarrolladores de software hacen lo suyo", y pone las otras áreas de experiencia en la retaguardia tratando de aprender a "jugar" Agile. La comunidad ágil me ha acogido (y a otros) del mundo de los productos: "realmente necesitamos grandes OP", pero personalmente no parece la esencia. Una vez más, siempre imaginé que habría una "forma" más global que combinara producto, UX, diseño de organización, soporte, operaciones, etc. Mi preocupación es que los límites alimentan la Fábrica de características y la centrada en la producción.
  6. Hace aproximadamente un año me encontré con Joshua Kerievsky y Modern Agile. Cuando necesito una instantánea "generativa" de Agile (algo que capta la esencia y puede generar / filtrar "formas" apropiadas), recurro a Modern Agile ya que está deliberadamente libre de prácticas específicas y tiene aplicabilidad para toda la organización ... una característica importante dado que la mayoría de los "problemas" no son únicamente problemas de desarrollo de software. Considero que MA es un complemento perfecto para muchos principios / prácticas Lean que toman una perspectiva de sistemas más amplia. El argumento es típicamente "pero MA no explica el cómo" a lo que sostengo que estamos nadando en el cómo. Por eso es igualmente importante, y principios como "Hacer de la seguridad un requisito previo" parecen resonar profundamente en los equipos.
  7. Incluso entre los "agilistas" autoidentificables, existen interpretaciones muy diferentes de lo que Agile es, no es, debería ser, no debería ser, etc. No hay nada intrínsecamente malo en esto (es realmente genial, en realidad), pero hace que hablar de Agile sea muy difícil.
  8. De manera similar, algunas personas se identifican tan profundamente con ciertos aspectos de Agile: autoorganización, trabajo a un ritmo sostenible, "confianza [equipos] para hacer el trabajo", que cualquier discusión sobre los beneficios relativos de las diferentes prácticas, o El diseño de diferentes “patrones” se vuelve difícil debido a la profunda inversión personal. Agilistas ardientes hornean gran parte de su identidad personal en Agile. A decir verdad, soy uno de estos. Me dificulta hablar de eso.
  9. Cualquier cosa que se comercialice y venda (y certifique) será difícil de descifrar. Esto es una constante con cualquier cosa "útil" (ver DevOps, por ejemplo), donde hay demanda para "comprarlo". El diálogo en torno a Agile está fuertemente influenciado por la experiencia de enseñarlo por dinero, tratando de introducirlo en entornos potencialmente hostiles y atendiendo las necesidades de las personas (y empresas) que compran / intentan instalar marcos (en este punto ... adoptadores posteriores). )
  10. En mi opinión, los patrones / prácticas ágiles son herramientas utilizadas, en concierto con muchos patrones adyacentes a Agile, para lograr valiosos resultados comerciales. Como Neil Killick señaló recientemente, hablar demasiado de Agile da la impresión de que "hacer Agile" es el objetivo final. No lo creo ... pero es muy fácil salir de esa manera.
  11. Puede ser imposible (para la mayoría de los no metodólogos que operan en el mundo real) desacoplar Agile de Scrum. Scrum está 1) controlado por dos personas, 2) tiene una perspectiva, 3) manifiesta esa perspectiva, incluidos varios miedos, en su diseño, y 4) es uno de los muchos enfoques válidos. Una vez más, no hay nada de malo en esto, hey, felicitaciones a Jeff y Ken, y a los fanáticos de Scrum, pero hace que la discusión sea mucho más difícil en mi mundo.
  12. La comunidad ágil es absolutamente maravillosa, y me siento maravilloso (y honrado) de ser parte de ella. Esto no es en modo alguno un repudio de Agile, sino solo un reconocimiento de mi parte de que hablar de ello explícitamente no me ayuda, n = 1, a mí.

Esperemos que Agile-folk encuentre interesante el contenido. Hablaré más sobre prácticas específicas y menos sobre el nebuloso "ágil" y mucho menos sobre Scrum.

Mejor

John