martes, 18 de septiembre de 2018

los principios ágiles más importantes que las prácticas

por 
la importancia de implementar los principios ágiles de comunicación, colaboración, transparencia, retrospección y simplicidad.
He trabajado en TI durante 25 años y conocí la mentalidad Agile en 2006. Abracé inmediatamente a Agile porque muchos de sus principios eran cómo ya trabajaba. Me gusta la simplicidad, desarrollé software en iteraciones para poder recibir comentarios y realizar correcciones de curso, prefería comunicarme cara a cara, y puse a mis clientes y desarrolladores en la misma sala con frecuencia para que pudieran colaborar y asegurar que estuviéramos en el Camino correcto.
Avance rápido hasta hace unos años, cuando una empresa me trajo para ayudarlos en su viaje Ágil. El primer día, el director me dijo que eran “ ya muy ágil”. Tenían todos los roles correctos en su lugar, sus ceremonias parecían estar bien ejecutadas, los artefactos parecían limpios y actualizados, parecían tener todo junto. Pero cuando comencé a investigar cómo interactúan entre ellos, vi la desconfianza entre TI y las unidades de negocio que no dio lugar a una colaboración real, casi toda su comunicación fue por correo electrónico para propósitos de "CC YA" y hubo una pesada carga de informe de estado debido a la falta de transparencia En la superficie se veía genial, pero debajo había un gran desastre. Estaban haciendo las partes fáciles de Agile, las prácticas de Scrum, pero no prestaban atención a las partes más duras : los principios Ágiles . Aprendí que priorizar las prácticas sobre los principios es una de las razones clave para el fracaso de Agile.
Puede implementar las prácticas de Scrum perfectamente y aún fallar en Agile. Es posible que vea una mejora en su capacidad para responder al cambio e incluso podría proporcionar un software que funcione más rápido por un tiempo. Sin embargo, no pasará mucho tiempo hasta que los beneficios de Agile sean menos evidentes. Los equipos tendrán dificultades para seguir el ritmo, el software no coincidirá con las expectativas del usuario con tanta frecuencia, y entonces Agile se considerará un fracaso. Incluso puede decidir volver a sus antiguas costumbres, formas que son más cómodas.
La incorporación de principios ágiles es la parte más difícil de Agile: cosas como trabajar a través de problemas de comunicación, desconfianza y falta de responsabilidad. A menudo omitimos trabajar con estos principios porque implica más tiempo y esfuerzo de lo que podemos desear invertir. Sin embargo, casi siempre son las cosas más difíciles las que nos dan el mayor beneficio.
¿Cuáles son algunos de los principios o cambios culturales que son las partes más difíciles de Agile?

Comunicación

A menudo veo a personas que usan Scrum Master para enviar sus mensajes a otros. Están acostumbrados a trabajar con un gerente de proyecto, y un Scrum Master es un rol totalmente diferente. Como Scrum Master trabajando con un nuevo equipo de Agile, tres miembros diferentes del equipo una vez vinieron a mí tratando de comunicarse a través de mí durante nuestro primer sprint. Uno de ellos dijo: "Dwight, necesito esta información de Ramesh antes de que pueda comenzar a codificar". Ramesh estaba a solo 20 pies de distancia de nosotros, pero estaban acostumbrados a que un gerente de proyecto manejara sus comunicaciones.
Un principio ágil clave es comunicarse cara a cara siempre que sea posible. La comunicación cara a cara puede asustar cuando muchos de nosotros estamos acostumbrados a sentarse en un cubículo sin tener que hablar con otras personas. Cuando esto sucedió, acompañé al miembro del equipo al escritorio de la otra persona y les pedí que comunicaran el mensaje directamente. Ayude a sus equipos a adquirir el hábito de comunicarse cara a cara como u primera  opción en lugar de como último recurso. El tiempo perdido no es ágil.

Colaboración

Agile se trata de personas que trabajan juntas, hablan juntas y presentan grandes ideas juntas. Estamos fundamentalmente en riesgo cada vez que alguien trabaja en algo solo. Un problema de colaboración que a veces veo ocurre cuando un Gerente de proyecto tradicional se convierte en Scrum Master. Los Project Managers pueden hacer grandes Scrum Masters, pero ten cuidado con aquellos que traen un estilo de comando y control junto con ellos. Agile no se  trata de comando y control, pero algunos nuevos Scrum Masters tienden a administrar y dirigir en lugar de colaborar con las partes interesadas y el equipo. Los equipos Great Agile no son administrados: se los anima a colaborar y a resolver los problemas ellos mismos. A menudo, la experiencia se aprende mejor (bien o mal) que diciéndole qué hacer.
También veo un patrón similar con los nuevos propietarios de productos, pero con el comportamiento opuesto. Muchos nuevos propietarios de productos están acostumbrados a crear requisitos, entregándoselos al equipo de desarrollo y luego a sentarse y esperar el producto final, con poca o ninguna participación adicional de su parte. La colaboración continua entre el propietario del producto y el equipo, junto con la corrección oportuna del curso, ayuda a garantizar que lo que se entrega al final del sprint sea justo lo que los interesados ​​querían.
Sin embargo, esto puede consumir mucho tiempo para el propietario del producto, y muchos de los nuevos en el rol no están listos para el compromiso o simplemente no saben que deben estar tan involucrados. Animo a los propietarios de productos a involucrarse regularmente con el equipo del proyecto durante todo el sprint. De esta forma, Sprint Review se convierte en una formalidad porque el propietario del producto ya ha visto varias iteraciones de las características durante el sprint y ha guiado al equipo a construir exactamente lo que los interesados ​​quieren.

Transparencia

La transparencia es solo ser honesto, contarlo como es y, a veces, ser vulnerable. Una vez trabajé con un VP que me pidió que pasara el informe del estado de un proyecto para que se viera mejor para su liderazgo principal Expliqué la importancia de la transparencia, que humildemente aceptó. La franqueza resultante sentó un precedente de honestidad y apertura que continuó, sin importar los resultados. No podemos arreglar las cosas si los problemas se barren debajo de la alfombra. La transparencia ágil significa plantear cuestiones al aire libre donde se pueden tratar. Las herramientas de ciclo de vida ágil automatizadas son geniales, pero para que los equipos y las partes interesadas puedan ver lo que realmente está sucediendo, deben tomarse el tiempo para acceder a la herramienta y poder verla. En mi experiencia, muy pocas personas ajenas al equipo se toman el tiempo para hacerlo regularmente.
Al menos al comienzo de una transformación Ágil, animo a los equipos a hacer que el trabajo sea más visible colocando grandes tablas de papel de Scrum y gráficos de quemado en una pared y mostrando esta información a todos los que los rodean. El liderazgo realmente aprecia la visibilidad que esto aporta al trabajo de desarrollo. Esto también puede ayudar a reducir la necesidad de informes de estado ya que cualquiera puede mirar el muro del equipo y ver exactamente qué está pasando.  
Otro consejo de transparencia que aprendí se deriva del hecho de que muchos miembros nuevos del equipo de Agile son reacios a plantear obstáculos durante las reuniones de stand-up. Una de las principales funciones del Scrum Master es eliminar los obstáculos para que el equipo pueda concentrarse en la entrega de software. Pero si no se levantan obstáculos, el Scrum Master no puede ayudar a eliminarlos. Les recuerdo a los nuevos equipos al comienzo de cada reunión stand up que planteen incluso posibles  obstáculos si hay alguna posibilidad de que algo pueda retrasar su trabajo o hacer que no cumplan con su compromiso de sprint. Los miembros más silenciosos del equipo especialmente necesitan aliento para hablar. Recompense a los que expresan su opinión y plantean obstáculos en los primeros sprints, especialmente a las personas más tranquilas, reconociéndolos frente al equipo.

Retrospección

Me gusta comparar la retrospección con la documentación del software. La documentación del software a menudo no se realiza porque se considera de baja prioridad en comparación con pasar al siguiente proyecto. De la misma manera, algunos equipos ágiles omiten las retrospectivas de sprint porque creen que no tienen tiempo o no ven el valor de hacerlo. Solo puede tener una mejora continua cuando se detiene para reflexionar sobre lo que funciona o no funciona y toma una decisión consciente para ajustar las cosas. Pequeños ajustes aquí y allá pueden ser la diferencia entre el éxito y el fracaso. Una vez leí que "la acción sin reflexión lleva al agotamiento y la reflexión sin acción conduce al cinismo". Es vital  realizar retrospectivas después de cada carrera y luego implementar realmente los cambios valiosos que surgen de ella.  

Sencillez

Esta puede ser una de las partes más difíciles de Agile. La mentalidad Agile es muy simple: hay cuatro valores en el Manifiesto Ágil y en los 12 Principios Ágiles acompañantes. Scrum tiene algunos roles, artefactos y ceremonias. Todo lo demás que hay es un intento de mejorar la mentalidad ágil. Algunas de esas ideas son grandes adiciones y algunas simplemente complican el concepto simple de Agile. La documentación del software es un excelente ejemplo de cómo Agile puede simplificar nuestros proyectos. Los artefactos deben reducirse al mínimo a solo lo que realmente se necesita para hacer el trabajo.
La documentación tiene valor, no me malinterprete: la gobernanza y la documentación de cumplimiento a menudo son necesarias, y el software debe mantenerse utilizando comentarios o documentación de soporte. Sin embargo, a menudo existe una tendencia a crear documentos simplemente porque "siempre los hemos hecho", independientemente de si tienen valor o si alguna vez se leen. Comprenda y sopese el costo real de crear cada documento con el beneficio anticipado. Luego, minimiza el esfuerzo para crear esos artefactos. Puedes hacer que se vea elegante después si eso es realmente importante. Si un diagrama dibujado a mano y escaneado es suficiente para que el equipo avance, es un gran ahorro de tiempo.
Estos son algunos ejemplos de cómo los principios ágiles hacen una gran diferencia. Tenemos que hacer un esfuerzo consciente para ejecutar las partes más difíciles de Agile, los principios, y no solo las partes más fáciles, las prácticas.
Por lo tanto, aunque las prácticas de Scrum o Kanban son importantes, las prácticas solos a menudo conducen a la falla ágil. Los principios ágiles y el cambio de la cultura de desarrollo son en general las partes más difíciles, pero son lo que hace que Agile sea sostenible a largo plazo y maximiza los grandes beneficios que tiene para ofrecer.
Entonces, ¿cuál es el siguiente paso? Mire a su equipo, escoja uno de los principios o áreas de cambio cultural necesarios, una de las partes más difíciles, y ayude a su equipo a hacer lo que debe hacer. Los equipos que continúan trabajando en los principios y en la cultura, cambian duro y lo suficiente como para convertirse en la élite Ágil, los pocos que verdaderamente entienden a Agile, los pocos que desatarán el verdadero poder que el desarrollo Ágil tiene para ofrecer.
Fuente: https://dzone.com/articles/agile-principles-over-practices?edition=395205&utm_source=Zone%20Newsletter&utm_medium=email&utm_campaign=agile%202018-09-18

lunes, 20 de agosto de 2018

Como ser un Scrum Master Extraordinario

Diez consejos que siempre necesitarás aplicar para ser extraordinario

1. Nunca comprometa al equipo con nada sin consultarlos primero
Como Scrum Master, no tiene la autoridad para aceptar solicitudes de cambio (sin importar cuán pequeñas) en nombre del equipo. Incluso si está absolutamente seguro de que el equipo puede cumplir una solicitud, diga: "Necesito consultar esto por parte del equipo antes de poder decir que sí".
Y, desde luego, no comprometa al equipo con los plazos, entregables ni nada más sin antes hablar con los miembros del equipo. Puede que no necesites hablar con todo el equipo: muchos equipos permitirán que algunos o todos los miembros digan: "Sí, podemos hacer eso" sin una reunión de equipo completo. Pero sigue siendo su decisión, no tuya.

2. Recuerda que estás ahí para ayudar al equipo a lucir bien
Ser un Scrum Master no se trata de hacerte quedar bien. Te ves bien cuando el equipo se ve bien. Y se ven bien cuando hacen un gran trabajo.
Sabes que estás haciendo bien tu trabajo cuando los que están fuera del equipo comienzan a preguntarse si te necesitaban. Sí, puede ser aterrador si su jefe se pregunta si es necesario. Pero un buen jefe sabrá que tu habilidad y experiencia te hacen parecer innecesario cuando de hecho eres indispensable.
Confíe en su gerente para comprender la diferencia entre parecer innecesario y no ser necesario.

3. No derrotar al equipo con un libro de reglas ágiles
Ni Scrum ni Agile vienen con un libro de reglas (aunque algunos han intentado crear uno).
Si su producto tiene usuarios, considere escribir historias de usuarios. Pero las historias no son obligatorias para ser ágiles. Si alguien necesita saber cuándo entregará: estimar. Si no, tal vez no. Si crees que una revisión al final del sprint es demasiado tarde para recibir comentarios, haz una revisión individual a medida que se crea cada característica.
Ser ágil se trata de honrar los principios y valores que crean agilidad. Si te mantienes fiel a esos, no te puedes desviar demasiado, sin importar lo que te puedan decir algunos.

4. Nada es permanente así que experimente con su proceso
Parte de honrar los principios de la agilidad es experimentar con su proceso. Anime al equipo a probar cosas nuevas.
¿A su equipo le encantan los sprints de dos semanas y cree que funcionan perfectamente? Estupendo. Ahora pídales que prueben una carrera de una semana o tres semanas y observen los resultados. Los experimentos pueden no ser siempre populares, pero son la mejor manera de garantizar que continúe descubriendo nuevas y mejores formas de trabajar.

5. Asegúrate de que los miembros del equipo y los interesados ​​se vean como compañeros
Los miembros del equipo y las partes interesadas del lado del negocio aportan una perspectiva importante a una iniciativa de desarrollo de productos. Como tal, cada uno necesita ser valorado por igual.
Cuando una de las partes ve al otro como algo tolerable, la organización como un todo sufre. Los equipos de desarrollo deben comprender la perspectiva única presentada por los interesados. Y las partes interesadas deben respetar al equipo de desarrollo, incluida la escucha cuando los desarrolladores dicen que un plazo es imposible.

6. Proteja al equipo, incluso en más formas de las que puede pensar
Quizás el consejo ágil que se da con más frecuencia es que un Scrum Master necesita proteger al equipo de un propietario de producto o partes interesadas excesivamente exigentes. Y ese es un buen consejo. A veces, los propietarios de los productos simplemente piden demasiado con demasiada frecuencia y con demasiada agresividad. Esto obliga a los equipos a cortar esquinas, generalmente esquinas de calidad, que vuelven a rondar el proyecto.
Y entonces un buen Scrum Master protege al equipo contra esto.
Pero lo que no escuchas tan a menudo es que un buen Scrum Master también debería proteger al equipo contra la complacencia. Los buenos equipos ágiles buscan constantemente mejorar. Otros equipos se conforman, tal vez inconscientemente, en pensar que han mejorado lo suficiente. Y es probable que sean dramáticamente más rápidos y mejores que antes de haber oído hablar de ágil. Pero incluso los grandes equipos a menudo pueden mejorar mucho.
Los Great Scrum Masters protegen a los equipos de la sensación de que no les queda nada por aprender.

7. Desterrar el fracaso de su vocabulario
De vez en cuando, voy a visitar a un equipo que se refiere a un sprint como un "sprint fallido". Por lo general, esto significa que el equipo no entregó todo lo que planeaban. Apenas considero una falla, especialmente si el equipo terminó la mayoría de los elementos planificados o si manejaron hábilmente una emergencia.
Cuando un jugador de baloncesto tira el balón hacia la canasta y anota, se llama gol de campo. Cuando el jugador falla, se llama intento de gol de campo . No es un fracaso . Un intento .
Good Scrum Masters ayuda a los equipos a ajustar su forma de pensar para que reconozcan los sprints y las características que no alcanzan las expectativas como intentos en lugar de fracasos.

8. Elogie a menudo pero siempre atentamente
El otro día le dije a mi hija adolescente que estaba orgulloso de ella. Su rostro se iluminó. Eso no debería haberme sorprendido. ¿A quién no le gustaría que le digan que alguien está orgulloso de ellos?
Pero la forma en que reaccionó me hizo darme cuenta de que no debía contarle esto con la suficiente frecuencia. Pensé que era equivalente a que le dijera algo obvio, como: "Eres alta". Pero supe que no era así.
Nunca ofrezcas elogios falsos. Nadie quiere escuchar eso. Pero cuando los miembros de su equipo hacen un buen trabajo, hágales saber. Lo más probable es que no lo escuchen con la suficiente frecuencia.

9. Aliente al equipo a hacerse cargo de su trabajo
Un equipo que es nuevo en Agile confiará en su Scrum Master o coach de manera significativa. El equipo puede no saber cómo mantener reuniones de scrum diarias en quince minutos. O pueden no entender la importancia de superponer el trabajo o de ser un equipo multifuncional.
Lo mismo puede decirse de un equipo deportivo inexperto. El entrenador de los niños pequeños que aprenden a jugar fútbol (soccer) necesita enseñarles todo. Cuando mis hijas tenían 6 años, su entrenador corría a lo largo de todo el juego gritando: "¡Patea y corre!". Si no lo hacía, los jugadores jóvenes se olvidarían. Incluso con él gritando, de vez en cuando algún niño simplemente se sentaba en la hierba y miraba.
Compare el entrenador de los niños con el entrenador de un equipo de la Copa del Mundo. En un equipo de la Copa del mundo, los jugadores han aprendido qué hacer. Si el entrenador llega tarde a la práctica, los jugadores sabrán qué ejercicios o ejercicios para comenzar el día. El entrenador de la Copa Mundial no necesita recordarles a los jugadores que pateen y corran. Pero el equipo de la Copa Mundial nunca te diría que no necesitan un entrenador en absoluto.
No importa qué tan bueno sea un equipo ágil, todavía creo que se benefician de tener un Scrum Master o entrenador. Pero los buenos equipos ágiles asumen algunas de las tareas de entrenamiento más sencillas como parte de sus propios viajes para dominar las habilidades necesarias en el desarrollo de productos.

10. Cállate y escucha
Algunos de los mejores entrenadores o mentores que hará es permanecer en silencio y dejar que el equipo descubra la respuesta.
Esto puede ser difícil. Cuando ve que su equipo lucha por descubrir qué hacer, es natural querer intervenir y ofrecer consejos. Pero si resuelve problemas o incluso ofrece sugerencias con demasiada facilidad, los miembros del equipo aprenden a esperar que resuelva todos los problemas para ellos.
No quiero insinuar que nunca puedas ofrecer sugerencias. Eres una persona inteligente. Si no, no estarías en el rol en el que estás. Pero parte de ser un gran Scrum Master es ayudar a los equipos a aprender cómo resolver problemas por sí mismos. Si resuelves todos los problemas que enfrentan los miembros del equipo, no tienen la oportunidad de aprender cómo hacerlo ellos mismos.

¿Qué falta en esta lista?
Estoy seguro de que me faltan algunas perlas de sabiduría. ¿Cuál es el mejor consejo de una frase que has recibido o dado como Scrum Master? Por favor comparte tus pensamientos en los comentarios a continuación.

fuente : https://www.mountaingoatsoftware.com/blog/ten-sentences-with-all-the-scrum-master-advice-youll-ever-need

domingo, 12 de agosto de 2018

Una vista de la herramienta Team Canvas

Canvas es una herramienta estratégica facil de usar que ayuda a los miembros del equipo a iniciar proyectos y alinearse en una visión común. Según nuestra experiencia con startups y grupos creativos, está hecho para iniciar proyectos colectivos sin problemas, permitir que las personas conozcan entre sí y acumular el impulso suficiente para ponerse en marcha.  mas información de ella en http://theteamcanvas.com/use/

viernes, 27 de julio de 2018

En scrum lecciones aprendidas se trabajan en la reunion de retrospectiva

En el proceso  retrospectiva del Sprint , el Scrum Master y Scrum Team se reúnen para analizar las lecciones aprendidas durante todo el Sprint. Esta información está documentada como lecciones aprendidas, que pueden aplicarse a futuros Sprints. Como resultado de esta discusión, puede haber Mejoras Accionables Acordadas o Recomendaciones del Cuerpo de Orientación de Scrum Actualizadas. Las mejoras aprobadas acordadas son las  principales salida de este proceso. Son la lista de elementos procesables que el equipo ha creado para abordar problemas y mejorar procesos con el fin de mejorar su rendimiento en futuros Sprints. Una vez que las Mejoras Accionables Acordadas hayan sido elaboradas y refinadas, el Equipo de Scrum puede considerar elementos de acción para implementar las mejoras. El Retrospect Sprint Log es un registro de las opiniones, discusiones y elementos procesables planteados en una reunión de Retrospect Sprint. El Scrum Master podría facilitar la creación de este registro con las aportaciones de los miembros del Scrum Core Team. La recopilación de todos los registros de Sprint retrospectivos se convierte en el diario del proyecto y detalla los éxitos, problemas, problemas y resoluciones del proyecto. Los registros son documentos públicos disponibles para cualquier persona en la organización.

Seguir los tres procesos de la fase de Revisión y Retrospect ayuda a los involucrados en un proyecto de Scrum a revisar los entregables e identificar los impedimentos para neutralizar en el futuro. Recuerde que los procesos no necesitan realizarse de forma secuencial o por separado. Se pueden ajustar para complementar los requisitos específicos de cada proyecto. Sin embargo, antes de abandonar la fase de Revisión y Retrospectiva, es imprescindible analizar el proyecto y determinar qué funcionó y qué no funcionó.

Los principales  objetivos  de la reunión son identificar tres cosas específicas:

Cosas que el equipo necesita seguir haciendo: mejores prácticas
Cosas que el equipo necesita comenzar a hacer: mejoras de procesos
Cosas que el equipo necesita dejar de hacer: problemas de proceso y cuellos de botella
Estas áreas se discuten y se crea una lista de Mejoras procesables acordadas.

Otras  herramientas  utilizadas en el Proceso de Retrospect Sprint son:
Lancha rápida
Métricas y técnicas de medición

Las  salidas  de Retrospect Sprint son:
Mejoras accionables acordadas
Elementos de acción asignados y fechas de vencimiento
Artículos no funcionales propuestos para cartera de productos priorizada
Registros de la Retrospectiva del Sprint o Log (s)
Lecciones aprendidas del equipo Scrum
Recomendaciones actualizadas de Scrum Guidance Body

¿Cómo se relaciona la reunión de Retrospect Sprint con el aspecto 'inspeccionar y adaptar' de Scrum?
La reunión de Retrospect Sprint es un elemento importante del marco de Scrum "inspeccionar-adaptar" y es el paso final en un Sprint. Todos los miembros del equipo de Scrum asisten a la reunión, que es facilitada o moderada por Scrum Master. Se recomienda, pero no es obligatorio para el propietario del producto. Un miembro del equipo actúa como el escriba y documenta las discusiones y los elementos para la acción futura. Es esencial realizar esta reunión en un ambiente abierto y relajado para alentar la participación plena de todos los miembros del equipo. Las discusiones en la Retrospect Sprint Meeting abarcan tanto lo que salió mal como lo que salió bien.
fuente : https://www.linkedin.com/pulse/scrumstudy-sprint-retrospective-meeting-jeetendra-roy-smc-ssgb-mba/

La Era de Agile Uno de los 10 mejores libros del 2018 Segun Amazon

Un viaje al futuro de muchas empresas nos presente este libro, Adoptar agile permite a un equipo, una unidad o una empresa adaptar y actualizar ágilmente los productos y servicios para satisfacer la cambiante tecnología y las necesidades de los clientes. Y el proceso es aplicable en cualquier parte: las empresas no necesitan nacer ágiles, comienza la transición y cosechando resultados extraordinarios.
Entrenamiento en gestion agil de proyectos con Scrumstudy. Como incorporando prácticas más ágiles en su organización y ejemplos inspiradores de acciones ágiles y consejos claros y prácticos.  Info Whatsapp 57 3206953696 #scrum #agilent

jueves, 19 de julio de 2018

Convergencia de Scrum y DevOps - The Convergence of Scrum and DevOps

Vale la pena mirar el documento The Convergence of Scrum and DevOps , Dave West CEO Scrum.org, Jayne Groll CEO DevOps Institute, como integrar Scrum y Devops , los equipos entregan software en funcionamiento continuamente y donde el trabajo fluye sin interrupciones entre todas las partes
interesadas en tiempo real. Agregue a eso donde el valor es claramente entendido, medido e informado. Y muchas ideas y conceptos de Scrum.org super valiosos #scrum #devops #software #ceos #agilent Fuentes usadas en los entrenamientos de Gestion agil de proyectos con Scrumstudy.

lunes, 16 de julio de 2018

El Equipo acepta mayor responsabilidad y ofrecer mayor valor

¿Aceptar una mayor responsabilidad significa entregar un mayor valor? Scrum cree que los empleados son motivados por sí mismos y buscan aceptar una mayor responsabilidad. Entonces, entregan mucho más valor cuando se autoorganizan. El estilo de liderazgo preferido en Scrum es "liderazgo de servicio", que enfatiza el logro de resultados centrándose en las necesidades del equipo de Scrum.

Beneficios de la autoorganización
La autoorganización como principio esencial en Scrum conduce a lo siguiente:
  • Compromiso del equipo y propiedad compartida
  • Motivación, que conduce a un nivel de rendimiento mejorado del equipo
  • Entorno innovador y creativo propicio para el crecimiento
La autoorganización no significa que los miembros del equipo puedan actuar de la manera que deseen. Simplemente significa que una vez que se define la Visión del producto en el proceso Create Project Vision, se identifica al propietario del producto, Scrum Master y Scrum Team. Y el propio Scrum Core Team trabaja en estrecha colaboración con los Stakeholder (s) relevantes para refinar mejor los requisitos a medida que pasan por el proceso Develop Epic (s) y Create User Stories. La experiencia del equipo se usa para evaluar los insumos necesarios para ejecutar el trabajo planificado del proyecto. Este juicio y experiencia se aplican a todos los aspectos técnicos y de gestión del proyecto durante el proceso Crear entregas.
Aunque la priorización se lleva a cabo principalmente por el propietario del producto que representa la voz del cliente, el equipo de Scrum autoorganizado participa en el desglose de tareas y la estimación durante los procesos de creación de tareas y estimación de tareas. Durante estos procesos, cada miembro del equipo es responsable de determinar qué trabajo va a hacer. Suring la ejecución de un Sprint, si los miembros del equipo necesitan ayuda para completar sus tareas, Scrum aborda esto a través de la interacción regular obligatoria con las Daily Standup Meetings. El propio Scrum Team interactúa con otros equipos a través de Scrum of Scrums Meetings y puede buscar orientación adicional según lo requiera el Scrum Guidance Body.

Finalmente, Scrum Team y Scrum Master trabajan estrechamente para demostrar el incremento del producto creado durante el Sprint en el proceso Demostrar y Validar Sprint, donde se aceptan entregables debidamente completados. Dado que los entregables son potencialmente enviados, (y el inventario priorizado del producto tiene prioridad según las historias de los usuarios en el orden de valor creado por ellos), el propietario del producto y el cliente pueden visualizar y articular claramente el valor que se crea después de cada Sprint; y los equipos Scrum a su vez tienen la satisfacción de ver que el cliente y otras partes interesadas aceptan su arduo trabajo.
fuente : http://blog.scrumstudy.com/accepting-greater-responsibility-and-delivering-greater-value/

viernes, 29 de junio de 2018

Desarrollo de proyectos con Scrumstudy Procesos y actividades

Eche un vistazo a estos procesos y las actividades que se enumeran a continuación para comprender mejor el flujo de un Proyecto Scrum.
Iniciado
  1. Crear Visión del Proyecto: en este proceso, se revisa el Caso de Negocio del Proyecto para crear una Declaración de Visión del Proyecto que servirá como inspiración y proporcionará enfoque para todo el proyecto. El propietario del producto se identifica en este proceso.
  2. Identifique Scrum Master y Stakeholder (s): en este proceso, Scrum Master se identifica utilizando Criterios de selección específicos.
  3. Equipo Scrum de Formulario: en este proceso, se identifican los miembros del Equipo Scrum. Normalmente, el Propietario del Producto tiene la responsabilidad principal de seleccionar a los miembros del equipo, pero a menudo lo hace en colaboración con Scrum Master.
  4. Desarrolle Epic (s): en este proceso, Project Vision Statement sirve como base para desarrollar Epic (s). Se pueden realizar reuniones de grupos de usuarios para desarrollar Epic (s).
  5. Crear una cartera de pedidos priorizada de productos: en este proceso, las Epic (s) se refinan, elaboran y priorizan para crear una cartera de productos priorizados para el proyecto. Los criterios de finalización también se establecen en este punto.
  6. Realizar planificación de liberación: en este proceso, Scrum Core Team revisa las Historias de usuarios en la cartera de productos priorizados para desarrollar un calendario de planificación de entregas, que es esencialmente un cronograma de implementación por fases que se puede compartir con las partes interesadas del proyecto. La duración de Sprint también se determina en este proceso.
Plan y estimación
  1. Crear historias de usuarios: en este proceso, se crean historias de usuarios y sus criterios de aceptación de historias de usuario relacionadas. Las historias de usuarios generalmente son escritas por el propietario del producto y están diseñadas para garantizar que los requisitos del cliente estén claramente representados y que todos los interesados ​​puedan comprenderlos completamente. Se pueden realizar ejercicios de escritura de historias de usuario que involucren a los miembros del equipo de Scrum creando las historias de usuarios. Las historias de usuarios se incorporan en la cartera de pedidos priorizados del producto.
  2. Aprobar, estimar y confirmar las historias de los usuarios: en este proceso, el propietario del producto aprueba historias de usuarios para un Sprint. Luego, Scrum Master y Scrum Team estiman el esfuerzo requerido para desarrollar la funcionalidad descrita en cada historia de usuario, y el equipo de Scrum se compromete a cumplir los requisitos del cliente en forma de historias de usuarios aprobadas, estimadas y comprometidas.
  3. Crear tareas: en este proceso, las historias de usuarios aprobadas, estimadas y confirmadas se dividen en tareas específicas y se compilan en una lista de tareas. A menudo, se lleva a cabo una reunión de planificación de tareas para este fin.
  4. Tareas de estimación: en este proceso, el Equipo central de Scrum, en Reuniones de estimación de tareas, estima el esfuerzo requerido para llevar a cabo cada tarea en la Lista de tareas. El resultado de este proceso es una Lista de Tareas Estimada de Esfuerzo.
  5. Crear Sprint Backlog: en este proceso, el Scrum Core Team tiene Sprint Planning Meetings donde el grupo crea un Sprint Backlog que contiene todas las tareas para completar en Sprint.

Implementar
  1. Crear entregables: en este proceso, el equipo de Scrum trabaja en las tareas del resumen de Sprint para crear entregas de Sprint. Un Scrumboard se usa a menudo para rastrear el trabajo y las actividades que se llevan a cabo. Los problemas o problemas que enfrenta el Equipo de Scrum podrían actualizarse en un Registro de impedimentos.
  2. Realice un standup diario: en este proceso, todos los días se lleva a cabo una reunión muy centrada, Time-boxed denominada reunión Daily Standup. Este es el foro para que Scrum Team se actualice entre ellos sobre su progreso y cualquier impedimento que puedan enfrentar.
  3. Antigüedad acumulada del producto del novio: en este proceso, el Backlog prioritario del producto se actualiza y mantiene continuamente. Se puede llevar a cabo una Reunión prioritaria de revisión del trabajo acumulado, en la que se debaten y se incorporan los cambios o las actualizaciones a la acumulación en la cartera de productos priorizados, según corresponda.
Revisar y retrospectivamente
  1. Convene Scrum of Scrums: en este proceso, los representantes del equipo de Scrum se reúnen para las reuniones de Scrum of Scrums en intervalos predeterminados o cuando sea necesario para colaborar y realizar un seguimiento de sus respectivos avances, impedimentos y dependencias en todos los equipos. Esto es relevante solo para proyectos grandes en los que participan varios equipos de Scrum.
  2. Demostrar y validar Sprint: en este proceso, el equipo de Scrum demuestra los entregas de Sprint al propietario del producto y las partes interesadas relevantes en una reunión de revisión de Sprint. El objetivo de esta reunión es garantizar la aprobación y aprobación del propietario del producto para los entregables creados en el Sprint.
  3. Retrospect Sprint: en este proceso, Scrum Master y Scrum Team se reúnen para analizar las lecciones aprendidas durante todo el Sprint. Esta información está documentada como lecciones aprendidas que se pueden aplicar a futuros Sprints. A menudo, como resultado de esta discusión, puede haber mejoras aprobadas accionables o recomendaciones actualizadas del cuerpo de orientación de Scrum.
Lanzamiento
  1. Envíos Entregables: en este proceso, los Entregables Aceptados se entregan o se transfieren a las partes interesadas relevantes. Un Acuerdo formal de entregas de trabajo documenta la finalización exitosa del Sprint.
  2. Proyecto Retrospect: en este proceso, que completa el proyecto, las partes interesadas de la organización y los miembros del equipo básico de Scrum se reúnen para retrospectivar el proyecto e identificar, documentar e interiorizar las lecciones aprendidas. A menudo, estas lecciones conducen a la documentación de Mejoras acordadas accionables, que se implementarán en proyectos futuros.

lunes, 25 de junio de 2018

Hacer el trabajo agil

Las prácticas ágiles son cruciales para las empresas de hoy en día, pero hay bajo nivel de adopcion. Los métodos ágiles pueden, y deben, extenderse más allá del desarrollo de software, transformando la forma en que abordamos el trabajo en equipo, el liderazgo y las formas de trabajar.
Los expertos de BCG en metodología ágil adoptan una visión holística que va más allá del desarrollo de software para todos los aspectos de la organización. Agile es un enfoque iterativo, empírico y multifuncional que puede aplicarse en muchos contextos comerciales y adoptarse en toda la empresa. Un modelo operativo ágil facilita tiempos de respuesta más rápidos al mercado y un mejor ajuste a las expectativas del cliente. Fomenta tanto la velocidad como la mejora continua. Nuestra oferta ágil abarca una perspectiva exhaustiva e interfuncional, abordando temas tan cruciales como la agilidad a escala, las trampas comunes, el software ágil y las formas ágiles de trabajar.
No se trata solo de tecnología. Se trata de una nueva forma de pensar que es más colaborativa, más abierta, más creativa y mucho más eficiente que otros modelos comerciales.
La transformación ágil a gran escala no se trata solo de tecnología. Se trata de una nueva forma de pensar . Es más colaborativo, más abierto, más creativo y mucho más eficiente que otros modelos comerciales. Y es algo que puede implementarse en una empresa, no solo en uno o dos departamentos. 
Las empresas pueden lograr una transformación ágil en tres niveles: el nivel del proyecto, que es relativamente fácil de lograr; el nivel de cartera, que es más complejo; y el nivel de organización, que requiere un replanteamiento completo del modelo operativo de una compañía. Moverse efectivamente desde el primer nivel hasta el último puede ser difícil para una gran organización, pero las empresas que se mueven en pasos progresivos pueden tener éxito.
fuentes
https://www.bcg.com/agile/large-scale-agile-transformation.aspx
https://www.bcg.com/agile/default.aspx

martes, 12 de junio de 2018

Aplicado Kaizen 5S al desarrollo de software

Consideremos, por el momento, que nuestra genba = nuestro lugar de trabajo, es el código fuente.

1 Aplicando  seiri , eliminemos el código heredado, los métodos y variables no utilizados, el código comentado y duplicado, etc. Seiri , que significa "ordenar" en inglés, en contexto kaizen significa "tirar cosas que no se usan"

2. Usando seiton , coloque el código en su lugar correcto, refactorícese, renómbrelo, reduzca a una sola responsabilidad, aplique patrones de diseño si es necesario, y así sucesivamente. Seiton , que significa "poner orden" en inglés, en contexto kaizen significa "poner las cosas en su lugar correcto y dejarlas allí, listas para usar"

3 Usando  seisô , repita las actividades mencionadas con frecuencia y constantemente, ejecutando pruebas (posiblemente) cada vez que se comprometa, y no solo en partes nuevas del código. Cada vez que abre un archivo de código fuente, ciérrelo más brillante que antes. Seisô , que significa "brillar / barrer" en inglés, en contexto kaizen significa "limpiar a menudo"

4 Seiketsu representa el trabajo estándar, una parte obligatoria de cualquier iniciativa kaizen . Defina y mantenga (¡y aplique!) Un estándar de codificación para el equipo, para su grupo y posiblemente incluso para toda la empresa. Defina y mantenga (¡y haga cumplir!) Un conjunto de comprobaciones de calidad del código y sugerencias para sus entornos de IDE y control de versiones. Manténgalos actualizados y alineados con las mejoras tecnológicas. Seiketsu , que significa "estandarizar" en inglés, en contexto kaizen significa "mantener los comportamientos 3S (arriba) y mantener el lugar de trabajo de manera apropiada.

5 Shitsuke , es el concepto de repetir las actividades anteriores, documentarlas como procedimientos y hábitos estándar, y transformarlas y mejorarlas continuamente. shitsuke , que significa "sostener" en Inglés, en el kaizen contexto significa "conservar y mantener los procedimientos seleccionados y aplicarlos como hábitos"

fuente:

lunes, 11 de junio de 2018

Miembros de equipos Scrum - Scrum developer Certified

Certificacion internacional Online Scrum Developer Certified - Desarrolador de Scrum , un miembro clave del equipo Scrum - con el mejor contenido en video cortos. Todas las tematicas son ampliadas en el SBOK en Español e ingles. Solicita tu link de pago certificado x Epayco.
Scrum Developer Certified SDC Online

miércoles, 9 de mayo de 2018

miércoles, 2 de mayo de 2018

Cómo justificar el valor del proyecto

La justificación comercial primero se evalúa antes de que se inicie un proyecto y se verifica continuamente a lo largo del ciclo de vida del proyecto. Este es un paso muy importante en el marco de Scrum. 
El proyecto debe tener sentido comercial en todas y cada una de las partes de su ciclo de vida. La estimación del valor del proyecto es una forma importante de establecer una justificación comercial. Estimar el valor del proyecto ayuda a quienes toman las decisiones a tomar una decisión vital como continuar con el proyecto existente o no.
La guía del cuerpo de conocimiento de Scrum (SBOK) proporciona información sobre varios métodos que se pueden usar para medir de manera efectiva el valor del proyecto para ayudar al equipo de Scrum a tomar decisiones estratégicas muy importantes.
El valor que proporcionarán los proyectos comerciales se puede estimar utilizando diversos métodos, como el retorno de la inversión (ROI), el valor presente neto (VPN) y la tasa interna de rendimiento (TIR).

1.       Retorno de la inversión (ROI)
El retorno de la inversión (ROI) cuando se usa para la justificación del proyecto, evalúa el ingreso neto esperado que se obtendrá de un proyecto. Se calcula deduciendo los costos esperados o la inversión de un proyecto de sus ingresos esperados y luego dividiendo esta (ganancia neta) entre los costos esperados para obtener una tasa de retorno. Otros factores como la inflación y las tasas de interés sobre el dinero prestado pueden tenerse en cuenta en los cálculos de ROI.

ROI formula: ROI = (Ingresos del proyecto - Costo del proyecto) / Costo del proyecto

Aquí hay un ejemplo de ROI :
El ROI de un proyecto que tendrá un costo de desarrollo de $ 125,000, con los beneficios financieros esperados estimados en $ 300,000 se calcula de la siguiente manera:

ROI = ($ 300,000 - $ 125,000) / $ 125,000 = 1.4

Por lo tanto, el retorno de la inversión es 1,4 veces la inversión (o 140%).
Los incrementos frecuentes de productos o servicios son una base clave de Scrum que permite una verificación más temprana del ROI. Esto ayuda a evaluar la justificación del valor continuo.

2.       Valor Presente Neto (VPN)
El Valor Presente Neto (VPN) es un método utilizado para determinar el valor neto actual de un beneficio financiero futuro, dada una inflación o tasa de interés supuesta. En otras palabras, el VPN es el ingreso total esperado o los ingresos de un proyecto, menos el costo total esperado del proyecto, teniendo en cuenta el valor temporal del dinero.

Aquí hay un ejemplo para el valor actual neto :
¿Cuál de los siguientes dos proyectos es mejor seleccionar si se usa el VPN como criterio de selección?

El Proyecto A tiene un VPN de $ 1,500 y se completará en 5 años.
El Proyecto B tiene un VPN de $ 1,000 y se completará en 1 año.
Solución: Proyecto A, ya que su VPN es más alto; el hecho de que el Proyecto B tiene una duración más corta que el Proyecto A no se considera aquí, porque el tiempo ya está contabilizado en los cálculos del VPN (es decir, debido a que es el valor actual, no futuro, el que se está considerando en el cálculo )

 3.       Tasa interna de rendimiento (IRR)
Tasa Interna de Retorno (TIR) ​​es una tasa de descuento sobre una inversión en la que el valor presente de las entradas de efectivo se iguala al valor presente de las salidas de efectivo para evaluar la tasa de rendimiento de un proyecto. Al comparar proyectos, uno con una TIR más alta suele ser mejor.

Aunque la TIR no se usa para justificar proyectos tan a menudo como otras técnicas, como el VAN, es un concepto importante que debe saberse.

Aquí hay un ejemplo de Tasa Interna de Retorno:

  Basado en IRR, ¿qué proyecto es el más deseable?

Proyecto A, que tiene una TIR del 15% y se completará en 5 años.
Proyecto B, que tiene una TIR del 10% y se completará en 1 año.
Solución: Proyecto A, ya que su TIR es más alta; el hecho de que el Proyecto B tiene una duración más corta que el Proyecto A no se considera aquí porque el tiempo ya se tiene en cuenta en los cálculos de IRR (es decir, como con el VAN, es el valor actual, no futuro, el que se utiliza para determinar la TIR) .
Fuente : http://blog.scrumstudy.com/how-to-estimate-project-value/

martes, 24 de abril de 2018

Comparacion de 2 certificadores Scrum Alliance y Scrum Org


Desde el año pasado encontré este comparativo y no se si esta con toda la fidelidad que quisiera, pero es mejor una aproximación que el total desconocimiento.

viernes, 13 de abril de 2018

LA ERA AGILE y bajo el dolar

LA ERA AGILE llego y como bajo el dolar , las certificaciones tambien :-) Por tiempo limitado al precio del 2017 y mas , Certificacion Internacional Scrum Master Certified SCM de Scrumstudy (precio de lista 450US) + Taller de entrenamiento en Gestión LEAN y AGIL de proyectos con simulación lego + Certificacion SFC Scrum Fundamentals Certified.  Paga 50% hoy y 50% en 30 dias o por Epayco todas las tarjetas de crédito. call now + 57 320 695 3696

crear unidades USB Live

UNetbootin le permite crear unidades USB Live de Ubuntu y otras distribuciones de Linux sin necesidad de grabar un CD.

Puedes dejar que UNetbootin descargue una de las tantas distribuciones soportadas en el menú desplegable o puede suministrar su propio archivo .iso de Linux.

Características
UNetbootin puede crear un USB Live que arranque desde su PC.

Es capaz de utilizar las distribuciones, ya sea descargando archivos ISO (imagen de CD) para usted, o mediante el uso de una imagen ISO que usted haya descargado con anterioridad.
http://unetbootin.github.io/

miércoles, 4 de abril de 2018

La era de Agile: Por que la gestión Agile se está comiendo el mundo

En 2011, Marc Andreessen escribió su famoso ensayo, " Por qué el software está comiendo el mundo " , en The Wall Street Journal, que lleva al cliché de que "todas las empresas necesitan convertirse en una empresa de software". (Una actualización útil de Jeetu Patel sobre el situación en 2016 está aquí: "El software todavía se está comiendo el mundo ").
De alguna manera, el artículo de Andreessen en 2011 fue notablemente profético. En 2011, Wall Street despreció a las empresas de TI.  Andreessen le decía a Wall Street: "¡Presten atención! Estas compañías son más valiosas de lo que crees que son ". Y Wall Street escuchó. En 2018, las cinco empresas más grandes del mundo por capitalización bursátil son empresas de TI: Amazon, Apple, Facebook, Google y Microsoft.
Pero resultó que Andreessen tenía la mitad de razón. No es que todo el software se esté comiendo el mundo: General Electric acaba de demostrarlo de una manera espectacular: invirtió mucho en software y el resultado. Después de cinco años, el CEO y sus principales lugartenientes fueron despedidos. Desarrollos similares están en curso en Intel, P & G y HP.
Resulta que no es solo el software lo que está 'devorando el mundo'. Las empresas están aprendiendo de la peor manera que el software requiere una forma diferente de ejecutar la organización para tener éxito. Las empresas deben ser ágiles, adaptables, capaces de adaptarse sobre la marcha para cumplir con los caprichos cambiantes de un mercado impulsado por el cliente. Este tipo de gestión era -y es- allá de las capacidades de los torpes gigantes de la industria de la 20 ª siglo. Son las empresas que son realmente ágiles las que están devorando el mundo (ya sea que se llamen o no con la etiqueta "Ágil").
De hecho, muchas de las grandes firmas de TI exitosas no usan la etiqueta "Agile" para describir la forma en que se ejecutan. En su lugar, hablan de "la forma de Google" o "nuestra cultura de inicio". De los cinco grandes, Microsoft es la excepción al hacer un compromiso explícito con la etiqueta "Agile".
Pero cualquiera que sea la etiqueta utilizada, las empresas de software exitosas implementan de manera reconocible la esencia de Agile, un enfoque en ofrecer valor para los clientes, trabajando en equipos pequeños en ciclos cortos y arreglos organizacionales en red en lugar de burocracia y silos descendentes. No es para las empresas que invierten en software, manteniendo la estructura de arriba hacia abajo th prácticas de gestión del siglo pasado.
Como resultado, el mundo está entrando en una nueva era: la era de Agile. Una revolución imparable ahora está en marcha en nuestra sociedad, afectando a casi todos. Las organizaciones ágiles están conectando a todos y todo, en todas partes, todo el tiempo. Son capaces de ofrecer un valor instantáneo, íntimo y sin fricciones a gran escala. Están creando un mundo en el que las personas, las ideas y el dinero interactúan rápida, fácil y económicamente. Para algunas empresas, la revolución es edificante y hermosa. Para otros, es oscuro y amenazante.
Deslumbrantes ejemplos de la nueva forma de dirigir las organizaciones son aparentes en todas partes. No son solo las cinco firmas más grandes por capitalización de mercado: Amazon, Apple, Facebook, Google y Microsoft. También son firmas como Airbnb, Etsy, Lyft, Menlo Innovations, Saab, Samsung, Spotify, Tesla, Uber y Warby Parker. Al mismo tiempo, lo que está levantando a algunas compañías es matar a otras, ya que las burocracias líderes del mercado, grandes y pesadas, pierden las transformaciones que cambian el juego en la industria y en la industria.
En pocas palabras, es ágil, no solo software, lo que está devorando al mundo. Como de costumbre, con cualquier cambio social masivo, hay buenas y malas noticias. Comencemos con las buenas noticias.
Buenas noticias n. ° 1: los clientes se hacen cargo
Las empresas ganadoras son aquellas que ofrecen un valor instantáneo, íntimo y sin fricciones para los clientes. Un mundo en el que las personas, los conocimientos y el dinero interactúan rápida, fácil y económicamente es un mundo que ha transformado la vida humana: todo es más fácil y más conveniente. Es difícil para los jóvenes de hoy incluso imaginar el mundo de hace apenas treinta años. ¿Cómo se las arreglaron las personas sin teléfonos celulares y sin Internet? Suena francamente arcaico, como el mundo antes de que se inventara la rueda.
Buenas Noticias # 2: El fin de la esclavitud salarial
Con los grandes avances en la prosperidad material que fueron generados constantemente por la Revolución Industrial a partir de finales de 1700 en adelante, era fácil pasar por alto el hecho de que implicaban un trato oscuro: en esencia, grandes cantidades de la raza humana acordaron venderse a sí mismos esclavitud. Correcta o incorrectamente, acordaron ser tratados como esclavos en el trabajo. Mientras estaban en el lugar de trabajo, acordaron seguir órdenes, incluso si esas órdenes eran degradantes, estúpidas o simplemente incorrectas, es decir, esclavitud. Sin duda, hubo algunas tareas interesantes en algunas partes de algunas organizaciones. Pero ellos fueron las excepciones. Lo que se valoró fue un seguimiento diligente de las órdenes.
Entonces, aunque la esclavitud fue abolida en la esfera política a mediados del siglo XIX , continuó en el lugar de trabajo en forma de esclavitud salarial, incluso si pocos estaban dispuestos a llamarlo así. La renuencia a enfrentar esta realidad social provino del hecho económico de que la esclavitud asalariada era útil: condujo a una gran mejora en la prosperidad material para la mayoría de la sociedad , al menos para la mayoría del mundo desarrollado. El hecho de que condujo a una existencia espiritualmente arrugada para gran parte de la raza humana fue solo un lamentable efecto secundario del "progreso".
Esclavitud asalariada como modelo económico continuó así de finales del 18 º siglo hasta finales del 20 º siglo. Entonces algo salió mal. Resultó que los esclavos asalariados no podían ofrecer lo que la economía ahora necesitaba. En un mercado interrumpido por la globalización, la desregulación, el trabajo del conocimiento y las nuevas tecnologías, ahora las empresas requerían iniciativa, innovación, compromiso, inteligencia, pasión, todo lo contrario de los esclavos asalariados.
Como resultado, se necesitaba un nuevo tipo de gestión para habilitar este nuevo tipo de trabajador. Algunos llamaron a esta forma de ejecutar una organización "Ágil". Algunos usaron otras etiquetas. Pero como sea que se llame, no fue solo un nuevo proceso. Era una manera fundamentalmente diferente de dirigir organizaciones. Fue económicamente más productivo. Y tiene un inmenso beneficio potencial para el espíritu humano. Puede crear lugares de trabajo que permitan a los seres humanos contribuir con todos sus talentos a algo valioso y significativo, creando valor para otros seres humanos.
El final de la esclavitud en la esfera política fue un gran problema. El final de la esclavitud asalariada en el lugar de trabajo también es un gran problema.
Las malas noticias: una nueva y más oscura edad dorada
Sin embargo, al igual que con cualquier cambio social masivo, también hay desventajas. David Dayen expone un resumen de los problemas en un perspicaz artículo publicado en American Prospect, " Big Tech: The New Predatory Capitalism ". Argumenta que "Los gigantes tecnológicos amenazan la democracia, la privacidad y la competencia" y pregunta: "Puede ¿Serán domesticados?
Por lo tanto, los exponentes exitosos de software y Agile están teniendo tanto éxito que ahora están emergiendo como una amenaza para una sociedad libre, de la misma manera, mutatis mutandis , que las grandes compañías industriales de fines del siglo XIX (ferrocarril, petróleo, el acero) se convirtió en una amenaza para la sociedad y tuvo que dividirse en grupos que fustigaban la confianza como el presidente Theodore Roosevelt. Es necesario que ocurra un escenario similar con las grandes firmas de TI. Ese es un trabajo para el sector público. El artículo de Dayen establece la agenda. Es cierto que es difícil ver cómo sucederá todo esto en el entorno político actual. Pero tiene que suceder, si una sociedad libre quiere sobrevivir.
La necesidad de hoy: abraza ágil
Para el sector privado, esperar una acción antimonopolio no es una solución. Continuando con las prácticas de gestión y las estructuras de explotación de árboles gigantes de la industria de la 20 ª siglo no cortar la mostaza. Para sobrevivir, y mucho menos prosperar, las empresas de hoy deben aprender a aceptar la nueva realidad empresarial: están entrando en la era de Agile.

Fuente: https://www.forbes.com/sites/stevedenning/2018/01/02/why-agile-is-eating-the-world%E2%80%8B%E2%80%8B/#4a692ef4a5b3