Un interesante simil Scrum vs. el lavado de la ropa

Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO

Basado mayormente en: http://www.dosideas.com/noticias/metodologias/729-scrum-en-pocas-palabras.html, el cual es la traducción de "Simple Scrum", por Tobias Mayer, comparto mi versión corta de Scrum.(insisto difiere muy poco pero creo -a mi criterio-  que era necesario añadir 2 ó 3 cositas más)

----

SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO

Scrum es un framework para mejorar la forma en la que trabajan las personas, o como lo define la Scrum Alliance: "un framework basado en equipos para desarrollar sistemas y productos complejos".  Scrum utiliza un proceso iterativo en donde cada iteración (llamada Sprint) es lo más corta posible (este tiempo puede ser entre una y cuatro semanas), manteniendo un ritmo parejo a medida que se avanza con planificación, ejecución y reflexión. Estas cajas de tiempo estrictas y rítmicas de Scrum permiten descubrir disfunciones en la organización.

Scrum define tres roles (Scrum Master, Dueño del Producto y Equipo), un conjunto de objetivos priorizados, un compromiso por cada sprint, y una forma sencilla para medir el progreso. Scrum usa ceremonias de tiempo acotado para planificar, para inspeccionar/adaptar a diario, y para inspeccionar/adaptar durante sprints.

Se mantiene una clara distinción entre el "Que" (el objetivo) y el "Como" (la forma de lograrlo)

Scrum requiere un foco claro, compromiso y transparencia completa en todos los niveles; adopta y enfatiza ciertos valores humanos incluyendo (pero no limitado a) la confianza, la integridad, el coraje y el respeto.

Fuente: Mountain Goat Software LLC

 Roles

•   Scrum master:  El Scrum Master es un líder servicial para el equipo, y un agente de cambio dentro de la organización.
• Product Owner (Dueño del producto): El Dueño del Producto es la principal voz del cliente, establece una visión y usa un proceso de priorización continua para lograrla.
• Team : El Equipo es auto-gestionado, multi-funcional, con poder para realizar el trabajo.

Artefactos

• Product Backlog (Pila del producto): Es una lista (backlog) de requerimientos u objetivos. Contiene todas las cosas que (creemos) nos gustaría tener en el producto o servicio, en algún momento. Es una lista viva, en un continuo estado de cambio y siempre ordenada por importancia, que cambia con el tiempo. Los elementos del backlog siempre hacen foco en el "Que".
• Sprint Backlog (Pila del Sprint) El compromiso del sprint es un subconjunto del backlog, que a veces se descompone en tareas de trabajo, que describen el "Como" del producto.
• Incremento: Es el producto de trabajo generado luego de un sprint, el cual es puede ser “potencialmente entregable”, o sea, si el Product Owner lo desea puede ser liberado al cliente en cualquier momento. Este incremento cumple la Definition Of Done (Definición de Hecho o Definición de Terminado), lo cual permite afirmar que si el incremento cumple esta definición no es necesario trabajar más sobre este producto de trabajo
• Métricas: Es el Scrum utiliza métricas simples, por ejemplo, mediciones de trabajo restante, o valor de negocio entregado. Las métricas deben usarse para medir la verdad - no para medir el éxito o el fracaso. Sólo se puede confiar en las mediciones de la verdad para fomentar un comportamiento de corrección en el equipo.

Eventos

• Sprint Planning (Planeación del Sprint): El Equipo y el Dueño del Producto se reúnen antes del inicio de cada sprint para planificar el trabajo y hacer un compromiso sobre este.
• Daily Meeting  (Scrum Diario o Reunión Diaria) : Todos los días, los miembros del equipo se juntan frente a un tablero visual (conocido como scrumboard) para alinearse entre ellos y para pedir y ofrecer ayuda. Esta reunión se realiza de pie, no toma más de 15 minutos y cada miembro del Team contesta tres preguntas:

o    ¿Qué hice ayer?

o   ¿Qué voy a hacer hoy? y

o   ¿qué impedimentos tengo?

• Sprint Review (Demostración del Sprint): Al final de cada sprint se muestra el trabajo terminado a los clientes, y se sugieren adaptaciones.
• Sprint Retrospective (Retrospectiva del Sprint): A continuación de la demostración el equipo reflexiona sobre el proceso, buscando formas de mejorar y comprometiéndose a cambios.

Un resumen de contratos ágiles

La falta de transparencia en la Gerencia tradicional de proyectos - Una experiencia vivida

Quiero compartir algo que me paso en el ‪#‎AgileOpenBogota‬ del pasado 8 de marzo:

Pregunté a los asistentes a una charla "quienes habían visto a su gerente de proyecto decir mentiras" y todos alzaron la mano.

Me cuestionan varias cosas:

• Si la constante es una mentira, ¿el problema esta en el GP? o ¿en el proceso de ejecutar el proyecto?  (considero que esta en el proceso)
• ¿Por que no somos transparentes? ¿qué queremos ocultar?
• ¿Que nos impide ser transparentes?
• Sería bueno que la gerencia tradicional revisara los valores ágiles, dentro de los cuales esta la transparencia y la confianza.
• Desde que punto de vista las mentiras se vuelven  "manejo" del Gerente de Proyectos

Muchos cuestionamientos


Falla el proceso y seguimos obstinados en ello.



Les recomiendo este link:

• Insensatez 3.0 por Jorge Aramburo

Mi pregunta para tí,

• si eres gerente de proyecto ¿ ERES MENTIROSO? ¿POR QUÉ?
• si eres team member, ¿tu gerente de proyecto ES MENTIROSO?¿POR QUÉ?
• si eres Scrum Master ¿ ERES MENTIROSO? ¿POR QUÉ? (esta si es una falta grave al manifiesto, principio y valores ágiles, - revisa que tienes que corregir para que esto no se repita - )

Queda abierto el espacio de discusión

_

No somos "recursos", nuestra forma de solucionar los retos es única e irrepetible

Existe una colección de frases frecuentes en los gerentes, gerentes de proyecto, líderes de proyecto respecto a quienes componen sus equipos de trabajo, entre ellas están:

• ¿cuando liberas un recurso, lo necesito para el proyecto x?
• mi proyecto necesita más recursos
• tengo dos recursos que no puedo mover
• tengo un recurso enfermo
• y así podría seguir...

Realmente es un lenguaje cosificante que no aplica bajo ningún contexto y mucho menos en desarrollo de software y TI.

Lo cierto es que NO SOMOS RECURSOS (nadie lo es), no somos reemplazables, la forma como solucionamos un problema, y en especial en desarrollo de software es única e irrepetible, como lo he argumentado en muchos contextos y entrenamientos, no estamos picando piedra con la misma fuerza y en el mismo ángulo durante un periodo asignado del día.

Tal vez esa cosificación de la persona, ingeniero, tecnólogo o técnico sea un lenguaje de poder o de control sobre quienes tiene asignados (no dudo para algunos lo será, lo he notado), para otros es la fuerza que trae el leer la palabra "RECURSO" en el:

• PMBoK
• MS Project
• y el resto de suites de software y libros para gerencia de proyectos.

Ojalá desde los Gerentes de Proyecto cambie todo esto, la verdad, yo he logrado más tratando a quienes tienen la gran labor de sacar un proyecto o producto adelante (junto conmigo) como personas, equipo, ingenieros; permitiendome cediendo el control, confiando y permitiendo que tomen la responsabilidad para la cual fueron contratados.

Repito, no somos recursos, nuestro equipo no esta compuesto por recursos, la forma de solucionar los retos en software y TI es única por cada persona, cada integrante de un equipo agrega particularidades únicas en el proceso creativo.

Ojalá esto cambie pronto ojalá comprendamos que quienes conforman nuestros equipos son personas.

--

Valoramos más

LAS PERSONAS Y SUS INTERACCIONES sobre los procesos y herramientas.

Agile Manifesto

__