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

__

Dos cosas que he aprendido en gerencia...

Se la escuché a un amigo

LAS COSAS TARDAN LO QUE SE DEMORAN

 (o sea, por más que presionen - cliente, gerente, etc, etc,-  las cosas tardarán su debido tiempo de elaboración y en software tendiendo al más grande.)



-----




Respecto a las decisiones..

SI COMO GERENTE NO TOMAS DECISIONES, OTROS LAS TOMARÁN SOBRE TI.

(significa que si no muestras gestión y toma fundamentada de decisiones otro - por lo general el superior, o tus pares -  al ver que no procedes, o procedes erráticamente, tomará(n) decisiones no muy agradables sobre ti)



_

Diferencia entre Valor de Negocio (Ágil) y Valor según el PMI

Una de las técnicas que tiene el PMI en el PMBoK para hacer seguimiento del avance del proyectos es la Técnica del Valor Ganado (earned value method  -EVM -) y esta consiste (de una forma muy básica) determinar cuanto alcance hemos logrado con respecto la linea base planteada de costos, o sea:

• Imaginémonos un proyecto donde planteamos que al 75% del tiempo del proyecto, el valor del alcance logrado era de $100.000.0000, pero si para esa fecha el valor de alcance logrado es de $60.000.000, este último valor corresponde al VALOR GANADO a la fecha..

Lo triste es que si con  estos $60.000.000 y 75% del tiempo del cronograma  el equipo del proyecto se la pasó haciendo:

• documentación, 
• prototipos, 
• tablas paramétricas
• funcionalidades que no correspondían al core del negocio, 

Lo que hicieron pudo pudo haber sido "muy bueno - funcionar muy bien - ", "muy bonito" pero sino lograron avanzar en lo realmente importante de poco o  nada sirve.  (se cancela el proyecto por alguna razón externa extraña y ese tiempo y dinero invertido no aportaron a su propósito dentro del negocio del cliente)

En las metodologías ágiles nos enfocamos en el valor de negocio, o sea en las funcionalidades que permiten al cliente poner a funcionar su negocio lo antes posible (buscando cumplir siempre con el principio de pareto : 20% de las funcionalidades que aportan al 80% del negocio), documentando solamente lo realmente importante y aplazando funcionalidades:

• nice to have (seria lindo / chévere que hiciera..)
• o ya que...
• "ya que" estamos haciendo esto.. hagamos aquello
• que solo van a hacer usadas por una persona cada año (o similar) y que se obtienen con query a base de datos
• Programar casos que en el proceso de negocio nunca se presentarán o que se resuelven diciendo "el sistema no soporta esta funcionalidad." o si se dá el caso miraremos si lo hacemos en una próxima versión.
• que emulan al excel, perfectamente pudiendo exportar a excel y allí realizar el tratamiento de datos adecuado (he visto muchos sistemas así.. ¿¿¿ustedes no??? )

Por lo tanto VALOR DE NEGOCIO y VALOR según el PMI son distintos.

Y lo que sería más sensato llamar a la técnica del valor ganado(EVM), mejor como "TÉCNICA ALCANCE COMPRADO/LOGRADO", pues quizás ese alcance comprado/logrado sea o no sea de valor para el negocio y los índices de avance SPI, Y CPI servirán para determinar cuanto estamos cumpliendo con el plan, pero no realmente cuanto valor estamos generando para nuestro cliente.


Nota:
Para una mayor precisión sobre el tema sugiero leer el Chaos Manifesto del 2013, del Standish Group( http://versionone.com/assets/img/files/ChaosManifesto2013.pdf ) el cual cito textualmente:  "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. "