Artículos que explican patrones anti-AGILE

Question

Cuantos más clientes visito, más malas implementaciones de Agile Scrum veo. A veces solo espero no entender los fundamentos de Agile, pero cuanto más leo la imagen más clara que he desarrollado sobre lo que realmente es Agile, en comparación con cómo se implementa.

Estoy buscando cómics/artículos que ayuden a explicar por qué SCRUM falla, o hablen de estudios de casos sobre implementaciones de scrum BAD.

personalmente me gusta este libro blanco The Agile Method and Other Fairy Tales (pdf)

Y esto es, con mucho, la mejor Dilbert alt text http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/000/1051/1051.strip.gif cómica

Edición

A continuación tiene algunos enlaces a Scrum Alliance, por aquellos que no tienen una cuenta aquí son los enlaces de caché Talking Chickens article, Missing Pigs

Answer 1

Esta misma observación se ha hecho antes y se ha debatido ampliamente (incluido el artículo sobre "Flaccid Scrum" by Martin Fowler y muchas charlas y artículos sobre ScrumBut por Ken Schwaber y Jeff Sutherland) anteriormente.

existen en principio dos razones para esto, cada uno con su propio conjunto de "olores":

• ningún cambio cultural - con demasiada frecuencia bajo la bandera de Scrum, ágil y, recientemente, sobre todo Kanban todavía tenemos un antiguo comando y control, con los gerentes aún usando la técnica de administración de "señalar y contar" (señalar a alguien y decirles qué se supone que deben hacer y cuándo debe finalizar). Agile debe traer un cambio cultural de esto a una situación, donde los equipos se apropian del trabajo que hacen y se autogestionan la parte técnica, mientras que los gerentes se concentran en eliminar los impedimentos y dirigir a toda la empresa/proyecto en la dirección correcta. Cuando este cambio falta, también lo son los beneficios de los métodos ágiles, incluso si se siguen en el papel.

• prácticas técnicas pobres - Scrum no dice nada explícitamente sobre cómo escribir un buen código, fácil de leer, cómo revisar y refactorizar, cómo escribir pruebas, cómo usarlos una vez escritos, etc., etc. . Scrum se creó con la suposición de que, liberado de los grilletes de comando y control, los desarrolladores de entornos de cascada harán las cosas bien. Desafortunadamente, en muchos casos no lo hacen, en demasiados casos no lo hacen por complacencia o pereza, sino por ignorancia. Esto está relacionado con el hecho de que muchas personas que desarrollan software nunca fueron educados (formal o de otro tipo) en aspectos básicos como algoritmos, métodos numéricos, modelado de objetos, etc., etc.

Vale la pena señalar que Ken es aparentemente Schwaber el único líder de pensamiento de Scrum que tomó nota de esta situación e intenta hacer algo al respecto. Su respuesta es la mejora de la educación de Scrum Master principalmente a través de cursos Scrum in Depth, pero también asegurando que los desarrolladores se den cuenta de que tienen que usar buenas prácticas técnicas para que Scrum realmente funcione. Esta es la razón por la cual se crearon cursos para desarrolladores: Ken Scroll Developer Certified y Professional Scrum Developer son ambos programas creados para mejorar el segundo problema anterior. Por supuesto, los entrenamientos, sin importar qué tan bien preparados y entregados estén, no lo resolverán directamente, pero al menos esto muestra que Ken reconoce que el problema existe y trata de hacer algo al respecto.

BTW - Ken acaba de publicar un artículo en su blog sobre algunos de los "olores": The Elephant In The Room. Vale la pena leer.

Answer 2

Usted puede encontrar la serie de Bob ágil en ágiles anti-patrones muy útiles

http://www.agileforall.com/category/agile/antipattern/