Scrum: Comprometiéndonos un poco más allá en el planning

Hola a todos

Aunque existen estrategias para mejorar la velocidad de un equipo (ver algunas aquí) y como lo he expresado es mejor ser más productivos que más veloces (clic aquí), les comparto un pequeño tip para que el equipo vaya ganando velocidad en su construcción de producto.

Por lo general, cuando los equipos comienzan o fallan son temerosos escogiendo la cantidad de historias a implementar que harán parte del sprint backlog. Una buena forma de alejar el temor y lograr la confianza (basándonos obvio en el principio) de transparencia es:

"Ok, comprometámonos con lo que nos sentimos seguros (15 puntos por ejemplo) y dejemos esta historia como opcional (ej:3 puntos), y si alcanzamos a hacerla, pues ¡Genial!"

Si el equipo compra la idea, al final pueden darse las siguientes situaciones:

1. Se logré solo lo inicialmente comprometido (cero líos, no hay ningún problema)
2. Logren hacer lo adicional, en este caso 18 puntos (excelente)
3. Si el equipo nota que después de varios sprints cumple el reto adicional, ellos mismos, el Product Owner o el Scrum Master pueden considerar que se puede aumentar la velocidad para el siguiente sprint, en este caso 16, 17 ó hasta los mismos 18 puntos, lo que decidan en consenso.

Saludos ágiles

Jorge Abad

No hay razones para trabajar horas extras bajo un escenario normal de trabajo.

A lo largo de la vida profesional he aprendido que no hay razones para trabajar horas extras.

Si tu o tu equipo trabajan horas extras se debe a alguna de las siguientes razones, identifícalas y trabaja sobre ellas.

Situación	Si eres tu	Si es alguien que tienes a cargo	Consecuencia
Mala definición de cargo y funciones	Habla con tu superior	Revisa si esta situación es temporal o como puedes hacerla lo más corta posible.	Cualquier persona en ese cargo/rol terminará por renunciar. En estos casos la vida personal paga los platos rotos y llega el momento que ningún sueldo del mundo compensa la vida personal y/o familiar.
Sobre-asignación de tareas	Habla con tu superior y demuéstrale con hechos y  números lo que sucede.	Haz que esta situación sea lo más corta posible	Igual que el anterior
Estas asumiendo responsabilidades que no son tuyas, o quieres hacer todo tu.	Tú sabrás que haces con tu vida y tu tiempo y con qué objetivo te estás sob-e esforzando,  aun así, no es aconsejable prolongar esto en el tiempo pues, pues puede que: ·         Nadie recompense tu sobre-esfuerzo ·         Se considere un esfuerzo normal que no merezca ser recompensado ·         Por fin te recompensen y logres el objetivo ·         Pierdas muchas cosas importantes (familia, amigos, salud, tiempo invaluable de tu pareja e hijos ) y lo logres ·         Pierdas muchas cosas importantes (familia, amigos, salud, tiempo invaluable de tu pareja e hijos ) y NO LO LOGRES De igual forma, identifica si tienes problemas con delegar y confiar en el trabajo de los otros , si es así,  comienza a trabajar en esta zona con ayuda de tu superior, recursos humanos, etc.,  pues es claro que tienes problemas serios de trabajo en equipo.	Revisa los objetivos con esta persona que tienes a cargo, y determina si puede alcanzarlos, de forma que se identifuque la viabilidad de las expectativas y reconocer si se puede o no seguir sacrificando en el corto, medio o largo plazo. Identifica si la persona a cargo tiene problemas con delegar y confiar en el trabajo de los otros , si es así, ayúdale a salir de esta zonan esta zona con ayuda de tu superior, recursos humanos, etc.	Depende de lo que esté en juego, tanto laboral como en el entorno personal
No tienes información/formación para hacer lo que te encomendaron y te toma más tiempo de lo que lo hace una persona “normal”	Solicita información, formación, ayuda o realiza autoestudio para cubrir pronto la curva de aprendizaje. Ponte metas claras en el corto y mediano plazo a lograr cubrir el GAP y no eternizar la situación.	Determina si esta es la situación, y si es del caso brinda información, formación, ayuda o estimula autoestudio para cubrir pronto la curva de aprendizaje. Ponle metas claras en el corto y mediano plazo a lograr cubrir el GAP y no eternizar la situación.	Frustración y se pone en riesgo la continuidad laboral.
Pierdes demasiado tiempo en la oficina haciendo cosas que no son  y luego tu conciencia te dice que debes quedarte para compensar el tiempo perdido	Te recomiendo lee estos dos artículos [1] y [2],y te informo que estas en riesgo de ser despedido. Aun  así, Identifica si la razón de la procastinar/postergar está ligada con que estás haciendo algo que no te gusta y toma acciones.	Te recomiendo lee estos dos artículos [1] y [2], y hables directamente con la persona a cargo y le propongas un plan de acción y seguimiento de forma que identifiques mejora, continuidad o detrimento de la actitud.  En caso de continuar o tener un detrimento en la actitud, es mejor prescindir de esta persona y encontrar quien tiene la motivación para hacer correctamente el trabajo. Indaga si la razón de la procastinar/postergar está ligada con que la persona haciendo algo que no te gusta y toma acciones como reasignación de cargo o funciones en caso de ser posible.	Si no hay mejora en esta situación, siempre se tendrá en juego la continuidad laboral

En caso de que el proyecto, o la situación sea temporal y se requiera un sobre-esfuerzo, te recomiendo leer este post [3].


Saludos

Jorge Abad

Referencias

[1] Postergarlo todo, un hábito poco saludable - http://www.eltiempo.com/vida-de-hoy/salud/postergar-las-cosas-no-es-bueno-para-la-salud_12989998-4
[2] La Procastinacion: El Enemigo de Tu Productividad - http://www.marthacaballero.com/procastinacion-enemigo-de-tu-productividad/
[3] Recomendaciones sobre el sobre-esfuerzo del equipo en un proyecto- `http://lecciones-aprendidas.blogspot.com/2012/10/recomendaciones-sobre-el-sobre-esfuerzo.html

CMMi y SCRUM: Mi punto de vista

Hola a todos:

Hace algunos días venia pensando en este post, pues sé que puede herir susceptibilidades y generar controversia, pero la reflexión y la sensatez me ha llevado ha escribirlo. Comenzaré entonces el post con las dos conclusiones con las que quiero terminar:

• CMMi es un modelo  prescriptivo que incluye muchas componentes y elementos,  su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
• SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".

Ya que saben mi conclusiones, espero estén interesados en conocer mis argumentos. Voy a manejarlos en forma de cuadro comparativo:

Característica	CMMi (Capability Maturity Model Integration)	SCRUM
Tiempo de adopción	·         Lo normal es que la adopción de cada nivel toma aproximadamente entre 12 a 18 meses [1] ·         La adopción completa de CMMi nivel 5 toma entre 3 a 5 años empleando técnicas de Six Sigma [1]	·         Aplicar Scrum y toma poco tiempo, aproximadamente 3 a 4 sprints de 2 semanas para estar ejecutando bien el framework. Se sugiere acompañamiento (coach) o mucha lectura para hacerlo bien [4]
Costo	Mínimo 100.000 dólares por cada nivel, compartido entre consultorías, adopción y adaptación del modelo dentro de la organización[12]	Sin información. Nota: Se puede adoptar el framework y las prácticas técnicas a muy bajo costo para los equipos.
Capacidad	La "capacidad certificada" de hacer software solo se demostrará después del primer nivel (nivel 2) certificado (he concluido,  que seguirás fallando en proyectos)	La capacidad es dada por el software funcionando cumpliendo la Definición de Hecho/Realizado (Definition of Done - DoD), disponible desde el primer sprint. Aunque es cierto, también se puede fallar en Agile [7][8][9], pero un equipo con coraje y el poder de las retrospectivas pueden cambiar favorable y rápidamente esta situación.
Complejidad del modelo	Entender CMMi requiere de entrenamiento y es un documento de 482 páginas (esta es la hora que nó me lo termino de leer)[2]	Para entender Scrum requiere de máximo una tarde leer la guía oficial que tiene 16 páginas [3]. ( y bueno, mucha reflexión y lecturas complementarias [4] para comprender este marco que te da límites y libertad.)
Universalidad del entendimiento del modelo	Muchas cosas dependen de la interpretación del consultor y de quien haga la evaluación (frase que se escucha con frecuencia mucho en el mundo CMMi).	He observado que entender el marco a pesar de ser simple, requiere de acompañamiento y mucha lectura.  El framework te proporciona unos límites claros y mucha libertad para moverte dentro de ellos. La recomendación en este caso es: ·        cumpla las reglas, ·         haga todas las reuniones ·         no fusione roles ·         no alargue el sprint ·         Lea a los líderes
Áreas de interés	CMMi se involucra con muchas áreas dentro de la organización, los proyectos y la ingeniería [5][2]: ·         Administración de procesos o   Entrenamiento o   Innovación ·         Ingeniería o   Requisitos o   Verificación o   Validación o   Solución técnica ·         Gestión de proyectos o   Gestión o   Administración de proveedores ·         Soporte o   Medición o   Auditorías al proceso y producto o   Gestión de la configuración o   Análisis de causas o   Análisis de decisiones	Scrum con respecto a  CMMi solo se encuentra fuertemente asociado a la gestión de proyectos y a la gestión de requerimientos [6] Respecto a la Ingeniería esta no se encuentra definida en Scrum, la responsabilidad es delegada al equipo auto-organizado que sabe y conoce como lograr el producto:"el equipo decide como pasar de una lista de requerimientos a un producto potencialmente entregable durante el sprint". Por lo tanto, los equipos SCRUM se apoyan fuertemente en las prácticas técnicas (para cumplir el manifiesto ágil el cual hace el llamado a la excelencia técnica) y así lograr la DoD (Definition of Done). Dentro de las prácticas técnicas se encuentran [10]: TDD BDD ATDD Continuous deployment Pair Programming Refactoring Gestión de la configuración Métricas Entre otros Es de observar que estas prácticas técnicas dan soporte a las diferentes áreas de CMMi, dejando por fuera a: Entrenamiento Administración de proveedores
Ciclos de mejora	Aunque se realizan auditorías tanto  a los proyectos como a la organización  y se recolectan y aplican las lecciones aprendidas, los ciclos de mejora toman tiempo y dependiendo de la organización se realizarán entre 2 a 4 en el año. Y la aplicación de las mejoras depende de las políticas de la organización	Se realizan mejoras cada sprint (el cual finaliza entre 2 a 4 semanas), habilitando el PHVA en ciclos cortos y potencializando inmediatamente la mejora continua de los equipos de desarrollo. Scrum no está orientado a la organización,  sino a  los equipos y estos son los directamente beneficiados con el framework . Es natural el compromiso del equipo con la mejora (kaizen)

 Bajo lo expuesto anteriormente, concluyo:

Es más fácil lograr CAPACIDAD* con Scrum que con CMMi, en términos de costo y tiempo. 

-
-

"Con Scrum el proceso de alcanzar capacidad es más rápido, barato, natural y convergente que con CMMi."[14]

-

* Hablo de capacidad pues la "C" de CMMi es de Capacidad que es el argumento de venta del modelo y considerando dicha capacidad como la facultad de hacer software de alta calidad funcional y técnica que cumpla con las expectativas de los clientes y usuarios, por parte de la organización y sus equipos de trabajo.

Ahora resulta que todos son ágiles

Es frecuente encontrar artículos del SEI y al PMI y otros de corrientes de la ingeniería de software clásica, apegados a modelos rígidos diciendo:
-

"si, si, y además nosotros también somos ágiles. Miren pueden pagarnos estos cientos o miles de dólares para que yo lo certifique o certifiquemos su empresa en agilidad bajo nuestro modelo"

Observo que se les esta yendo el negocio de las certificaciones y las consultorías de las manos, pues cada vez las empresas y los equipos de software están encontrando más pronto la EXCELENCIA y CAPACIDAD de hacer software con altísima CALIDAD en el agilismo, que bajo los esquemas tradicionales y rígidos como son CMMi, PMBoK, RUP, entre otros.


En la misma línea del párrafo anterior, es una moda el uso la palabra ÁGIL / AGILE (o en su defecto SCRUM), y muchos quieren ponerla de prefijo o de apellido a su negocio, framework, título, etc., cosa buena pues apunta a que los agilistas tienen la razón y cosa mala pues habrán muchos diciendo que son ágiles sin serlo. Más temprano que tarde el mercado y los hechos demostrarán quienes son o no del mundo agile, y esto será dictado por el cumplimiento del Manifiesto Ágil  y sus Principios [11], y el éxito en la forma de ejecutar lo que se comprometen en un entorno complejo.

¿Además qué grande (léase: google, facebook, yahoo, microsfot, etc) del software tiene CMMi nivel 5?

Volviendo al inicio

Termino entonces este post con las conclusiones prometidas:

• CMMi es un modelo  prescriptivo que incluye muchas componentes y elementos,  su adopción es lenta y bastante costosa para los equipos y organizaciones, e incluso adoptándolo no se garantiza que "todo vaya a ir bien"
• SCRUM es un marco poco prescriptivo que tiene excelentes prácticas de gerencia de proyectos, gestión de requisitos y habilita de una forma rápida la mejora continua, su adopción es simple y poco costosa, adicionalmente su correcta implementación hará que pronto "todo vaya bien".

Queda abierta la discusión

Saludos y un abrazo ágil a todos

Referencias:

[1] http://www.sei.cmu.edu/library/assets/bridging-gap.pdf
[2] CMMI for Development, Version 1.3. http://www.sei.cmu.edu/reports/10tr033.pdf
[3] The Scrum Guide -https://www.scrum.org/Scrum-Guides
[4] Por dónde comenzar a leer y a estudiar de Scrum http://lecciones-aprendidas.blogspot.com/2013/05/por-donde-comenzar-leer-de-scrum.html
[5] Framework para el Desarrollo De Software En Entornos Académicos - https://docs.google.com/file/d/0B5JZ11Z2PoWWWDlheXY2SnhUc2M/edit?pli=1
[6] Can Scrum help to improve the project management process?  A study of the relationships between Scrum and Project Management process areas of CMMI-DEV 1.3. http://www.javiergarzas.com/2013/03/cmmi-scrum.html
[7] Ways to Fail with Scrum!- Jeff Sutherland  http://www.gbcacm.org/sites/www.gbcacm.org/files/slides/3B%20-%207%20Ways%20to%20Fail%20with%20Scrum!.pdf
[8] How to Make Scrum Fail - http://agile.dzone.com/articles/how-make-scrum-fail
[9] Scrum Fails? -Ken Schwaber http://kenschwaber.wordpress.com/2011/04/07/scrum-fails/
[10] What are the Most Important and Adoption-Ready Agile Practices?  http://www.infoq.com/research/agile-practises?utm_source=infoqresearch&utm_campaign=rr-content#.UUmgOcTIFVw.twitter
[11] Manifiesto Ágil  -http://agilemanifesto.org/

[12]Profiles of Level 5 CMMI Organizations - http://www.compaid.com/caiinternet/ezine/reifer-profiles.pdf
[13]Jeff Sutherland. Scrum and CMMI Level 5: The Magic Potion for Code Warriors "http://systematic.com/media/282221/Scrum_and_CMMI_Level_5___The_Magic_Potion_for_Code_Warriors.pdf
[14] Texto de mi autoría adicionado el 15 de septiembre de 2013

Tips para el Sprint Backlog: Primero las HU Riesgosas y luego las prioritarias

Hola a todos

Recordemos:

• Sprint backlog: ítemes de backlog (en nuestro caso Historias de Usuario - HU) comprometidos a construir durante el sprint.

De las primeras cosas que aprendí en Scrum, al ver que un sprint fallaba fue:

Hacer de primero las HU más riesgosas y aunque no sean las prioritarias para el Product Owner (PO)

Razones:

• si comienzas muy tarde a hacer la HU es probable que por sus dependencias o complejidad no la termines.
• Obvio después de la(s) riesgosa(s) poner las HU que tengan más prioridad de forma que siempre estemos dando el máximo valor a medida que avanza el sprint.

Sugerencias:

• Hacer ver al PO por que va esta(S) HU(s) de primero.- La verdad no es complejo-.
• Debido a que esta historia va primero solicitar los insumos para hacerla, en caso que no estén,  poner una fecha máxima para la recepción de insumos, en caso contrario,  hacer ver que si no se reciben oportunamente la historia se cae (no se culmina), y esos puntos no se logran.
• Lo ideal y recomendado es comenzar el sprint con los insumos (información, componentes, definiciones, etc) claros y resueltos para que el Sprint avance sin tropiezos.
• Si una es HU riesgosa y se observa que la posibilidad de completarla es casi nula debido a su complejidad:
• Definir un Spike (tarea dentro del sprint) con timebox definido (léase timebox=tiempo fijo) y objetivos definidos
• Ese spike debe tener como objetivo eliminar la complejidad y adquirir el conocimiento necesario para lograr estimar y construir esa HU en el siguiente sprint
• No tener muchas historias de usuarios riesgosas, a lo sumo 2 de un máximo de 7 HU (un sprint debería tener a lo sumo entre 6 y 8 HU), debido a que si son muchas el sprint puede ser un fiasco y no completar nada. (situación que viví y de la cual aprendimos como equipo)
• Enfocarse y enfocar al equipo durante la ejecución del sprint en máximo 2 historias al tiempo de forma que se evacue siempre lo primero. Esto en Kanban se llamaría un limite de 2.

Saludos y abrazos ágiles a todos

Jorge Abad

Scrum Master: Identificando y removiendo impedimentos... y adicionalmente el conflicto humano

Ayer realizamos en Medellín el primer AGILE BEER NIGHT - un gran espacio, de amistad, compartir experiencias y de cerveza - pero entre muchas cosas que conversábamos noté que algo no estaba muy claro, y es el trabajo del scrum master en remover todo tipo impedimentos.

Del Scrum Master, como lo he escrito en varios post  y como lo dice www.scrum.org es responsable de:

1. Remover impedimentos
2. Ser dueño del proceso y que se cumpla el proceso 
3. Realizar coach al equipo (orientarlo a que sea mejor tanto técnica como humanamente)

Pero el primer punto es el que me ocupa, un scrum master debe trabajar en identificar impedimentos en todas partes - un cazaimpedimentos -:

• sea que se los digan los team member en el daily (recordemos las tres preguntas mágicas: ¿qué hice ayer?¿qué voy a hacer hoy?¿qué impedimentos tengo?) 
• que se lo diga cualquier miembro del equipo scrum en el transcurso del día, (aclaro: el equipo scrum esta compuesto por Product Owner, Scrum Master y Team Members, estos últimos son los encargados de construir el producto)
• que se evidencien y expliciten en la review y con mayor razón en la retrospectiva
• o que el Scrum Master, lo "huela" o lo identifique sin que nadie se lo diga. 

(ya se dan cuenta por que se requiere un scrum master con dedicación de medio a tiempo completo para un proyecto)

Y allí esta una de las claves del liderazgo servicial, es estar preguntándose constantemente: 

¿qué le falta o estorba a mi equipo para que se sientan muy cómodos y hagan bien lo que más le gusta : construir un producto que los haga sentir orgullosos?, 

La respuesta a esta pregunta puede tener muchos tamaños, colores, sabores, y fuentes, pues pueden ser identificados desde los 3 pilares (que enumera Alan Cyment):

• Productividad
• Calidad
• y Felicidad

Como en las 4 capas ( que nos cuenta fuerza tres ver más aquí)

• Filosofía : las personas
• Metodología: el proceso
• Técnica: el conocimiento requerido para completar el producto
• Ecosistema: que entorno laboral que tiene el Equipo Scrum y los team member para realizar su trabajo 

Pero he notado que el esfuerzo depende mucho del tipo de impedimento:

• impedimentos tipo hard: de productividad, calidad, metodología, técnica y ecosistema es relativamente sencillo. Su remoción se centra en encontrar qué remueve el impedimento, y en muchos casos la remoción es causal, típica acción-reacción.: ejemplos:
• falta de conocimiento
• lugar inadecuado del equipo
• información inoportuna
• no se entiende cierto tipo de reunión del framework
• historias de usuario muy grandes
• salarios
• etc.

• impedimentos tipo soft: correspondientes a la felicidad, filosofía, estos dos tienen la complejidad correspondiente al ser humano, a la persona, sus experiencias, su forma de relacionarse con otros, a como se relacionaba en el pasado, a su presente, a como ve el futuro; y en este campo las acciones son más complejas y se requiere de grandes habilidades blandas de parte del Scrum master para removerlos. Ejemplos de estos impedimentos pueden ser:
• miembros que le hagan bulling a otros por falta de conocimiento o por falta de personalidad
• personas desmotivadas a pesar de ser buenas técnicamente
• alguien con baja auto-estima
• des motivación para al trabajo
• equipo rebelde
• equipo desmotivado
• equipo ubicado en zona confortable de la que no queire salir (en otras palabras: equipo sin coraje)
• equipo o persona sin los valores ágiles
• transparencia, 
• coraje, 
• respeto,
• comunicación, 
• simplicidad
• foco
• capacidad de dar retroalimentación
• alguien que no cumple los compromisos pero que se nota comprometido
• miembros de equipo aislados
• Product Owner al extremo perfeccionista
• equipo desmotivado
• rivalidad entre miembros del equipo
• alguien que aplasta a los otros con sus comentarios ya sean técnicos o no
• Producto Owner conflictivo
• team member conflictivo
• o que el del problema sea yo mismo, el Scrum Master (y como lo decíamos acompañados de cervecitas, yo sea un Scrum Monster)
• etcétera, etcétera, y muchos etcéteras.

Estos últimos requieren de una intervención más cuidadosa y cada caso es un mundo aparte, lo que funcione en una situación no significa que vaya a funcionar en una situación similar.

Muchas veces es suficiente con hablar con el/los implicado(s), otras veces es requerido una serie de acciones y toma de evidencias para saber como actuar.

Esta intervención y problemática está relacionada con nuestra forma de ser, y cuando se trabaje en remover el impedimiento ha de ser con bisturí, con claridad, con hechos (no suposiciones y juicios) de forma que logremos cambios a través de los pedidos y ofertas. 

A estos pedidos, ofertas y compromisos se les debe hacer seguimiento para identificar mejoras o detrimentos de las situaciones e identificar pasos a seguir.

Ser Scrum Master tiene su ciencia, cada vez lo concluyo más.

Para comenzar a adentrarse en este aspecto humano, les sugiero:

• Ver estos videos de Scrum detrás de Scrum: 
• Scrum detras de Scrum - Martin Alaimo
• Dojo (taller) scrum detras de scrum  - Martin Alaimo
• leer y poner en práctica el libro Más productivos de Martín Alaimo 
• Frases para entender, acompañar y hacer coach a equipo
• si encuentro y leo más autores los estaré compartiendo

Nota: 

Sé que no les solucioné los problemas, pero si los evidencié, y si algún SM (Scrum Master) solo estaba ocupado del proceso y de que solo tuvieran los insumos, creo que con este post, tiene un buen punto de partida para trabajar lo más delicado y valioso del proyecto: LAS PERSONAS Y SUS RELACIONES.

Saludos a todos

Productividad mejor que Velocidad.

-

Qué es mejor ir a 200 km/hora en la dirección equivocada, implicando que entre más avanzas más lejos estás.
o
Ir a 80 km/hora en la dirección de la visión - dirección correcta -.

-

• Productividad ( me lo recordaba Jorge Johnson @jorge_johnson) es dar valor de negocio.
• Velocidad es construir software, útil o no útil pero software al fin al cabo.

Bajo estas definiciones entonces:

1. Hacer mucho software pero no generarle valor al cliente
• mucha velocidad y poca productividad
• ejemplo:
• hacer funcionalidades que serán poco usadas y que corresponden al "nice to have" y que no están alineadas con la visión del producto.
2. Hacer poco software pero generarle valor al cliente. 
• poca velocidad pero alta productividad 
• ejemplos
• cuando estamos haciendo refactor que nos permitirá tener una mejor aplicación
• cuando estamos haciendo componentes complejos pero que requieren gran esfuerzo en su construcción.
3. Hacer mucho software y generar mucho valor
• mucha velocidad y alta productividad
• ejemplo:
• construyendo funcionalidades de valor para el cliente de complejidad normal.
4. Hacer poco software y poco valor
• poca velocidad y poca productividad
• ejemplo
• Construir un componente muy complejo que requiere mucho esfuerzo, que no será muy usado. - por lo general un capricho funcional de algún interesado con poder -, y que no se encuentra alineado con la visión del producto.

En síntesis, nuestro esfuerzo como Equipo o como Scrum Masters es guiar al Product Owner a que solicite las funcionalidades del producto que le proporcionen valor, sea que estas se hagan o no con velocidad, pues estamos bajo el principio de transparencia y sabemos que estaremos con nuestro equipo trabajando comprometidamente en el backlog priorizado, en el 20% de las características que dan el 80% de beneficio (ley de pareto para el agilismo).



Por lo tanto, siempre preguntemos:

• ¿es necesario?
• ¿le agrega valor al producto?
• ¿cuantos lo van a usar?
• ¿ese uso lo pueden hacer en una herramienta externa? (informes que perfectamente pueden manipular mejor en excel)
• y volver a preguntar ¿es realmente  necesario?
• ¿prefieres nuestro tiempo en esta funcionalidad a esta otra?
• ¿si se acabará el dinero preferirías esto o aquello?
• ¿prefieres esta validación supercruzada entre estos 8 campos o que entreguemos esta historia que te saca el total de ventas del día? (por ejemplo)

Nota: 
Aunque esta nota aplica para el agilismo, también es valida para el esquema tradicional.



--

Scrum: Cediendo el mando y control AL EQUIPO

Hace aproximadamente un año comenzamos a migrarnos a una forma de trabajo completamente diferente, llamada “Scrum”, ha sido un proceso lleno de ganancias, retrospectivas, mejoras y aprendizajes. Este framework ha implicado cambio un radical en nuestra forma habitual construir software y de relacionarnos como personas y trabajadores del conocimiento [2].

Son muchos los aspectos que cambian, y que pueden ser consultados en la guía de scrum en www.scrum.org, pero este post se centra en el principal aspecto en el que se centra el agilismo: “LAS PERSONAS” (El manifiesto ágil comienza con: PERSONAS E INTERACCIONES SOBRE PROCESOS Y HERRAMIENTAS, ver más en http://agilemanifesto.org/iso/es/), y dentro de esas personas el El Team Developer.

Dentro de Scrum tenemos varios roles interviniendo en la construcción del producto:

• Los stakeholders: cuyas expectativas y necesidades son priorizadas por el Product Owner
• El Product Owner : Encargado de lograr y transmitir la visión al equipo, decidir que se construye del producto, y del ROI del mismo.
• El Scrum Master: Encargado del proceso de scrum, remover impedimentos y realizar coach al equipo.
• Y El Team Developer (equipo de desarrollo): Encargado de autoorganizarse y construir el producto

En este camino de Scrum (el cual por no ser prescriptivo) deja definiciones abiertas donde uno se mueve con libertad, he observado que uno de los aspectos más complejos de comprender y asimilar es el equipos auto-organizados.

Digo complejo, pues estamos de un esquema  Mando y Control (en inglés Command & Control[1]) donde el Gerente de Proyecto es quien comanda la misión y el éxito o fracaso de ella dependerá de los lineamientos que dé, decidiendo:

• qué hacer
• cómo hacerlo
• quién debe hacerlo
• cuándo hacerlo

El éxito también dependerá del equipo, las herramientas, los stakeholders, etc., pero  en el ambiente de gerencia de proyectos y organizacional, es Vox Populi  que un buen gerente es factor determinante y principal para el éxito del mismo.

Ahora si pensamos en el nuevo esquema, en el que las responsabilidades de la gerencia de proyectos es fraccionada:

• El camino a seguir es dado por el Product Owner, definiendo el qué y el cuándo.
• El scrum master es un líder servicial que busca que se cumpla el proceso definido y se encarga de que el equipo sea cada vez mejor y tenga todas las herramientas e insumos para completar el trabajo comprometido removiendo los impedimentos.
• El equipo decide libremente (de lo ítemes de backlog priorizados para el sprint) con qué se compromete y cómo va realizarlo.

Bajo este esquema, queda el rol de la gerencia de proyectos inoperante y convirtiéndose en un reto profesional el hecho de pasar de Gerente de Proyectos (líder, amo y señor de la visión, del equipo, de la táctica y la estrategia) a Scrum Master (líder al servicio del equipo).

Y es por esto este post se centra en ceder el control, y el Gerente de Proyecto cede toda esa supremacía tan anhelada por algunos, a un ente con mayor poder: “AL EQUIPO”, pues este siendo un sistema complejo encuentra mejor la forma de autoregularse y controlarse de forma que va encontrando mejores caminos y formas para crecer como equipo y hacer crecer el producto.

Y hasta acá suena todo muy poético, pero es un proceso que toma esfuerzos tanto desde el punto de vista del gerente de proyecto que se transforma en Scrum Master (si así lo desea) como desde el equipo que antes eran personas que recibían órdenes y directrices a ser responsables del cómo y quién debe hacerlo, pasando de un “organismo subyugado” a un “organismo consciente de si mismo, estableciendo y encontrando sus propias reglas, en crecimiento, evolución y mejora” generando equipos para organizaciones 3.0.

A continuación enumeraré aspectos claves en esta transformación:

1. Ventajas:

• El compromiso con lo que se va adquirir durante el sprint lo adquiere el equipo y no otros externos a él
• En el planning el equipo escucha lo que se desea construir, realiza la estimación,  decide hasta donde es capaz de llegar y define la forma de construir.
• Durante la construcción el equipo decide qué construir, cómo construirlo y quien debe hacerlo. En ocasiones Scrum Master orienta al equipo para que estén siempre construyendo lo que tiene mayor prioridad y mayor riesgo, evitando desenfoque del equipo.
• Durante la ejecución del sprint el equipo tiene las herramientas (el tablero kanban, los burndown charts) que le permiten saber si lograrán o no el compromiso.
• En la reunión de review, el equipo realiza la entrega del producto construido al Product Owner y a los Interesados, recibiendo directamente la retroalimentación por el trabajo realizado.
• Igualmente, durante el review se reciben los honores por lograr el trabajo comprometido en el planning, o se pasa la pena de no lograrlo. (antes estos honores y penas eran del gerente de proyecto - y por la forma tradicional de construir software,  por lo general eran penas - ). La review también tiene el poder de realizar la motivación sobre el equipo, pues los aplausos le dará la razón en su forma de alcanzar la victoria y los fracasos le darán los elementos para mejorar en el próximo sprint (generalmente de 2 semanas) y lograr la victoria perdida en el vigente.
• En la retrospectiva guiados por el scrum master, el equipo encuentra como mejorar en Productividad, Calidad y Felicidad; identificando mejoras en su proceso de construcción, y en su forma de relacionarse como equipo, con el Scrum Master y el Product Owner.

1. Desventajas y riesgos

• Equipos que no se quieran comprometer y que elijan trabajar muy por debajo de su capacidad.
• Equipos que no estén dispuestos a aprender y a poner en prácticas las retrospectivas.
• Miembros de equipo que no se comprometan, pues a pesar de que estuvieron en el planning y junto con sus compañeros delimitaron el producto a construir durante la ejecución del sprint dejan a sus amigos "tirados" no realizando tareas con el profesionalismo requerido, es decir, inyectando bugs, trabajando a mucho menos capacidad de lo normal, etc.
• Mala comprensión de la autoorganización y autogestión, creyendo que esta característica no implica deberes, ni responsabilidades.
• Scrum Master aun con chip de gerente de proyectos, interesado en controlar al equipo y decirle exactamente qué, quién, cómo y cuándo hacer las tareas.
• Creer que esto ocurrirá por arte de magia con solo decir las palabras mágicas : “SCRUM : EQUIPOS AUTO-ORGANIZADOS”, falso, se requiere de mucho acompañamiento, coach y de personas receptivas y decididas a entender las reglas y compromisos que esto implica.

1. Beneficios

• Un compromiso alto sobre lo que se va a construir…
• Responsabilidad asignada a quien tiene el poder de lograr el resultado
• Un sistema complejo (el equipo) es dominado por reglas impuestas por ellos mismos y no bajo la autoridad y liderazgo del gerente de proyecto.
• El equipo no requiere de reuniones de seguimiento, pues el equipo con sus gráficas y radiadores de información saben en qué punto están y si van a lograr los objetivos.
• Como resultado de lo anterior, el equipo se "presiona" a si mismo (de forma natural) para lograr las metas trazadas conjuntamente.
• EL ÉXITO DE LO QUE SE VA A CONSTRUIR DURANTE EL SPRINT NO ES RESPONSABILIDAD DEL SCRUM MASTER (antes gerente de proyecto - e insisto, si es que quiso cambiar de rol -) SINO QUE ES ENTREGADA AL EQUIPO

Referencias:

[1] Field Manual 6-0, Mission Command: Command and Control of Army Forces, Headquarters United States Army, Department of the Army, Washington, DC, 2003.

[2] Cyment, Alan. El espíritu de Scrum,  El arte de amar los lunes. V0.2 - http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum