Management 3.0

Management 3.0

Es un movimiento de innovación, liderazgo y management.

¿Que!?

vamos lento...

¿Que es un equipo ágil?
En pocas palabras se podría definir como un equipo de alto desempeño, cross-funcional, auto-gestionado, con altos niveles de cooperación, comunicación, mejora continua y orientados a entregar valor al cliente.

Tener un equipo así no es fácil, requiere tiempo, dedicación e involucramiento por parte de los lideres o managers de cualquier organización, pero no un involucramiento del tipo Command & Control, sino uno dedicado a desarrollar equipos empoderados y orientados a la resolución de problemas. Muchos lideres o jefes o managers cual quiera sea su rol aun prefieren dedicarse al "micro-management" y decirte a sus equipos el como trabajar y que hacer todo el tiempo, y mientras mas parecido lo hagan a como el jefe dijo...mejor evaluados son, aun que quizás lo que hicieron no tiene valor para la compañía, en consecuencia terminan liderando equipos dependientes de cada palabra o acción que comanden, sesgando su visión de managers a una operacional y no a una estratégica como debería ser.

Todo lo anterior para mi describe a un no muy buen.. Líder o Gerente.

Bueno por otro lado hay lideres o gerentes que si buscan desarrollar a sus personas, equipos, ponerles objetivos y que ellos como profesionales busquen la mejor forma de lograr esos objetivos. Lamentablemente esto no se enseña en las escuelas de negocio o de management  y depende de la propia habilidad del Líder o Gerente desarrollar estas capacidades en sus equipos.

aproximadamente en 2011 Jurgen Appelo  http://jurgenappelo.com/  lanzo el libro Management 3.0 "Leading Agile Developers, Developing Agile Leaders"  https://goo.gl/Bh4bUb 

El cual explora claramente como el management es uno de los principales problemas o limitantes de tener equipos ágiles y también enseña una series de practicas que cualquier manager podría usar para desarrollar este tipo de equipos.

Por el titulo del libro podríamos decir que aun estaba muy orientado al software a pesar de que si releemos la definición que di arriba de equipo ágil, esta es en realidad aplicable a cualquier negocio y debería ser el sueño de cualquier Buen Manager.

El libro, sus ideas y las practicas descritas en él funcionaron bastante bien y comenzó a generarse todo un movimiento que busca finalmente tener equipos ágiles dentro de las empresas, ok...saquemos la palabra ágil ya que aun se relaciona mucho solo con el software...y déjenme decirlo de nuevo...

El libro, sus ideas y las practicas descritas en el funcionaron bastante bien y comenzó a generarse todo un movimiento que busca finalmente tener equipos motivados, auto-gestionados, de alto desempeño y felices.

En 2014 Jurgen publico el libro Woukout https://goo.gl/zDTT1j el cual describe una serie de juegos, herramientas y practicas para tener trabajadores motivados, comprometidos, mejores gerentes ( y menos gerentes también).

Finalmente en 2016 salio el libro Managing for Hapiness: Games, Tools and Practices to motivate any team  https://goo.gl/MHT3gj 

entonces..

¿Que es Management 3.0?

El Management 3.0 es un movimiento de innovación, liderazgo y management que reinventa la forma de hacer liderazgo y ejecutar el management como grupo y no como una responsabilidad que descanse solo en los gerentes.

Describe y provee herramientas para desarrollar equipos de alto desempeño que trabajen junto a los managers para lograr los objetivos de negocio, dando prioridad a la motivación intrínseca de los trabajadores y su felicidad.
Enseña y describe formas de organizar y desarrollar equipos, conocerlos, motivarlos, generar y compartir conocimiento, dar espacio para experimentación, auto-organización,etc.

Todo lo anterior aplica perfecto para cualquier organización!

Posee mas de 30 practicas descritas en https://management30.com/practice/

Y mundialmente se hacen constantemente Cursos y Workshops de Management 3.0 a lideres, gerentes, ejecutivos, etc.

Daily Scrum

Daily Scrum

Otro tema en el que he visto confusiones en los equipos y conceptos errados en Scrum Masters entrenados.

Quien haya estudiado algo de Scrum sabe que es una reunión diaria del Development Team, que tiene un tiempo máximo de 15 minutos y como objetivos principales generar sincronía en el trabajo del equipo y un plan de acción hasta la próxima Daily.

Lo que muchos ignoran es...

1° La reunión debe ser conducida por el propio Development Team y no por el Scrum Master, lo único que debe hacer el Scrum Master es enseñarle al equipo a respetar los 15 minutos máximos, cuando el equipo ya sabe esto... ni siquiera es necesaria la participacion del Scrum Master en la Daily, el solo debe asegurarse de que esta suceda.

2°Las preguntas...
- ¿Que hice Ayer?
-¿Que problema tengo?
-¿Que haré hoy?

No son esas las preguntas!
entre 2011 y 2013 las preguntas cambiaron, orientándose al objetivo del Sprint y al trabajo en equipo.

¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?

aconsejo fuertemente revisar la guía oficial de Scrum mantenida por sus autores http://www.scrumguides.org/

Saludos!

Definition of Ready

Definition of Ready

Definition of Ready es un artefacto que algunos equipos Scrum utilizan para evitar problemas típicos durante un Sprint, pero que no es un artefacto oficial de Scrum, ya que puede ser un arma de doble filo!

¿Cuantas veces te han pedido hacer un desarrollo y no estaban los ambientes listos, o los datos de prueba o los mockups y así varias cosas que no te permiten avanzar en el desarrollo, pero que cuando el tiempo se acaba es tu culpa por no terminar a tiempo!?  ¿Te suena familiar?

Bueno el DoR (Definition of Ready) busca resolver esto y es un artefacto que construye el Development Team en un acuerdo con el Product Owner. La idea es que se listen en él todas aquellos cosas que el equipo establezca deban cumplir los elementos del Product Backlog para que sean candidatos de entrar en un Sprint, y no podrán entrar en un Sprint hasta que no cumplan con el DoR.

¿Por que es peligroso?

Porque es fácil caer en la mala practica y que el DoR se transforme en requerimientos que un Product Backlog Item deba cumplir en un 100% y finalmente eso jamas suceda..quitando agilidad al equipo... por ejemplo si se pidiera en el DoR que "Cada historia debe tener al menos 10 criterios de aceptación detallados y debe ser acompañada por mockups finales de todas las posibles ventanas". No suena poco ágil esto?

El Maestro Mike Cohn habla en detalle de esto si quieres profundizarlo
https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready

Saludos

Las Fuerzas en Scrum

Las Fuerzas en Scrum

En Scrum existen 3 fuerzas representadas por cada uno de los roles que Scrum prescribe. Cada fuerza tiene un propósito y razón de ser y el Scrum Team debe buscar el equilibro de estas fuerzas.

¿Cuales son estas fuerzas?

• do the right thing, hacer lo correcto, fuerza representada por el Product Owner a traves del manejo y priorización del Product Backlog, el le dice al Development Team que es en lo que deben trabajar, es decir, que es lo correcto por hacer.
• do the thing right, hacer las cosas bien, fuerza representada por el Development Team, ellos deben enfocarse en hacerlo bien técnicamente, ellos saben y son los expertos en construir el producto o descubren cual es la mejor forma de construir el producto.
• do it agile, hacerlo ágil, fuerza representada por el Scrum Master, el ayuda a todo el equipo a trabajar de manera ágil y a desarrollar el pensamiento ágil.

Estas fuerzas deben estar en equilibrio siempre si queremos hacer Scrum correctamente (por algo Scrum tiene estos roles no?)

Si por ejemplo solo nos enfocáramos en las fuerzas de do the right thing y do it agile estaríamos generando productos sin la calidad técnica necesaria, por tanto con una deuda técnica importante que haría que en el corto plazo nuestro producto fuera in-mantenible y una bomba de tiempo.

Por otro lado si nos enfocamos solo en do the right thing y do the thing right, estaríamos generando el producto que el Product Owner quiere, pero muy probablemente con un exceso de análisis y tecnicismos que le quitarían agilidad al proceso, ya que el software siempre es mejorable, así como al arquitectura etc y si buscariamos hacer siempre lo optimo técnicamente, no terminaríamos en varios Sprint haciendo que el Time to Market fuera excesivo.

Saludos

Definition of Done

Definition of Done

Hace unos días participe en un curso de Product Owners certificado por la ScrumAlliance. Fui como alumno porque estoy interesado en convertirme en entrenador certificado y necesito cumplir algunos requisitos..pero bueno esa es otra historia.

En este curso había mucha gente que ya era o participo en cursos de Scrum Master y me llamo la atención el desconocimiento que existe respecto del DOD. así que voy a explicar prácticamente las dudas que vi en este curso y que no se resolvieron en el.

Vamos allá...

Definition of "Done" es un artefacto de transparencia de Scrum y como artefacto es un objeto vivo que todos pueden mirar o consultar ya sea de forma física (escrito en un muro por ejemplo) o virtual (un documento compartido).

¿Para que sirve?

Al final de cada sprint un equipo Scrum debe entregar un incremento de producto que sea potencialmente liberado en producción, eso quiere decir Done, por tanto el entregable de cada sprint debe cumplir con lo que sea necesario (estandards, convenciones, lineamientos, documentos, etc) para que sea candidato de poner en producción sin problemas y que no sea necesario hacer nada mas!

El artefacto se construye para que todo el Equipo Scrum sepa como conocimiento común con que estandars, convenciones, lineamientos, documentos, etc se deben cumplir para considerar que lo que hizo el equipo durante el sprint se considere Done, evitando así malos entendidos y generando transparencia y alineamiento de expectativas en ese ámbito.

¿Cuando se crea?

Se debe crear al principio!
¿Por que?
Porque tiene directa influencia con la estimación o el esfuerzo que se necesita realizar para considerar que algo este Done, no es lo mismo tener un DoD que te pida que debes cumplir con 3 cosas a uno que te pida cumplir 10, probablemente te llevara mas esfuerzo cumplir 10 cosas por tanto afecta directamente lo que el equipo de desarrollo puede hacer durante un Sprint

¿Cuando se usa?

Se usa todo el tiempo!
Claro todo el tiempo a medida que el equipo avanza va verificando la lista para ver si ya cumplió con todo y puede considerar que algo este Done.  No se usa solo al final del sprint, si esperas al final del sprint para verificar que algo este Done estas en problemas!

¿Como se construye?

Debe armarlo el development Team, pero debe contener como mínimo las definiciones que establezca el área de TI o arquitectura u operaciones o quien sea que establezca aquellos requisitos que debe cumplir un elemento de software para pasar a producción. Ahora en la practica sabemos que muchas veces cumplir con estos requerimientos implica ir a comités o excesiva documentación, etc. Es importante que los sponsors del proyecto ayuden a una negociación para tener DoD ágiles y que no terminen siendo un bloqueo eterno para poner software en producción.

el DoD no esta escrito en piedra, no necesitas gastar demasiado tiempo intentado definir lo que debería ser, siempre puede evolucionar, mejorar y eso es un principio básico de todo lo que hagas.

Saludos