Workshop Oficial Management 3.0

Workshop Oficial Management 3.0 - 1 Day

Estimad@s el próximo sábado 17 de Noviembre estaré realizando el workshop oficial de 1 día de management 3.0

Sobre el Workshop

Este es un Workshop Oficial de 1 dia, que entrega un certificado de asistencia a un curso de Management 3.0 https://management30.com/about/certificate-of-attendance/

El Workshop de 1 día busca ofrecer flexibilidad, adaptación y, lo que es más importante, talleres prácticos prácticos, los talleres de un día fueron tan divertidos, tan coloridos, prácticos y tan proactivos como la versión del libro que contiene muchas de las prácticas de Management 3.0. Pero, incluso mejor que el libro, ¡puedes entrenar y aprender de otros gerentes y líderes de equipo como tú!


Contenidos

Cada taller de Management 3.0 lo ayuda a encontrar respuestas a preguntas compartidas con otras personas que buscan mejorar su enfoque de gestión. Estas preguntas comunes incluyen:

• ¿Cómo podemos motivar a nuestros trabajadores?
• ¿Cómo podemos cambiar la cultura de la organización?
• ¿Cómo podemos cambiar la mentalidad de los gerentes?
• ¿Cómo podemos hacer que los equipos asuman la responsabilidad?
• ¿Cómo podemos mejorar el trabajo en equipo y la colaboración en equipo?
• ¿Cómo podemos los gerentes confiar en sus equipos?
• ¿Cómo podemos desarrollar las competencias de las personas?
• ¿Cómo podemos ser ágiles cuando la organización no lo es?

Si bien cada taller se adapta a las necesidades de los asistentes, al igual que estas preguntas, existen ciertos desafíos que enfrentan todos los gerentes, jefes de equipo, gerentes de proyecto y ejecutivos de nivel C. Cada taller incluye enfoques prácticos sobre estos temas:

• compromiso de los empleados (mapas personales)
• gestión del rendimiento (Metrics Ecosystem y OKRs)
• colaboración en equipo y experimentación (Celebration Grids)
• recompensas y reconocimiento (Kudo Box)
• narración de historias y diálogos de mejora (Diálogos de Mejora)
• motivación extrínseca vs. motivación intrínseca
• formando confianza
• Entrenamiento personal (Feedback Wraps)
• Delegación (Juntas de Delegación)
• planes de compensación (fórmula de salario y dinero de mérito)

... y cómo personalizarlo para las necesidades específicas de su equipo!



Lugar

Juana de Arco 2012, Oficina 13, PROVIDENCIA Metro Pedro de Valdivia, Santiago.
Valor

200.000 1 Persona
180.000 2 Personas
150.000 3 Personas o mas
*Pago vía transferencia electrónica y Paypal https://www.paypal.me/agileaguilar/
*El valor incluye material educativo y 2 coffe break mañana y tarde, no incluye almuerzo.

Cuenta Corriente 03-79418-0
Banco Santander
Fabian Aguilar Fuentes
Rut 15.535.897-1
Enviar Comprobante a faaguilar@gmail.com

Inscripción

https://www.workshopbutler.com/public/event/7uWsJJhq

Scrum in Action - Sabado 24 de noviembre 2018

CURSO: Scrum in Action
Sabado 24 de noviembre 2018

¿Eres Scrum Master? o ¿quieres serlo y tomaste algún curso de certificación?
Entiendes los conceptos de Scrum, sus valores y principios, sus eventos y artefactos pero tienes dificultades para aplicar esto en la práctica?

Si las preguntas anteriores te identifican este curso es para ti.

Objetivo del Curso

Dar herramientas reales y transmitir experiencia que permita a los Scrum Master ejercer correctamente su rol, y desarrollar a los equipos que lideren en el uso correcto de Scrum y el camino Ágil.
Al finalizar el curso poseerás una serie de herramientas y conocimientos más avanzados que te permitirán usar Scrum de manera efectiva y permear su uso en una organización.


Requisitos

Conocer el framework Scrum, sus principios, valores, artefactos y eventos por estudio autodidacta o haber realizado algun curso de certificación como scrumalliance, scrummanager, scrumstudy, etc.



Temario

0. Base y Mitos de Scrum
1. ¿Como iniciar un equipo Scrum? ¿Inception? ¿Team Building?¿Sprint 0?
2. Armando el Product Backlog  y el Story Mapping
3. Y el DOD ¿como se construye?¿cuando se usa?
4. La primera Planning ¿Como? ¿y la velocidad del equipo? ¿Que capacidad? ¿y la estrategia de ataque del sprint?
5. La daily efectiva
6. La reunión de refinamiento ¿cuando? ¿como? ¿que?
7. La review ¿como ejecutarla? ¿Para quienes? ¿Su agenda?
8. La retrospectiva ¿ Siempre la misma dinámica? ¿que dinámicas? ¿Como se que esta bien ejecutada?
9. De un equipo novato a un equipo ágil.
10. El sprint día a día, la deuda técnica.

Valor

Hasta el 31 de octubre 200.000 luego 250.000
*Pago vía transferencia electrónica y Paypal https://www.paypal.me/agileaguilar/
*El valor incluye material educativo y 2 coffe break mañana y tarde, no incluye almuerzo.

Cuenta Corriente 03-79418-0
Banco Santander
Fabian Aguilar Fuentes
Rut 15.535.897-1
Enviar Comprobante a faaguilar@gmail.com
Fecha

Sábado 24 de noviembre de 9:00 a 18:00 horas

Lugar

Urban Station Eliodoro Yañez 869, PROVIDENCIA Metro Salvador Providencia, Santiago.

Consultas
https://www.linkedin.com/in/faaguilar/
faaguilar@gmail.com
Inscripción https://goo.gl/forms/gOzzy3rqWVIpvWj33

Desmitificando el Rol de Scrum Master

Desmitificando el Rol de Scrum Master


Debo confesar que esta entrada la estoy escribiendo con emocionalidad y es que es demasiado el mal entendido del Rol de Scrum Master no solo por personas ajenas al rol si no también por los propios Scrum Master y las organizaciones.

En base a lo que se, el Rol del Scrum Master tiene las siguientes responsabilidades:

• Enseñar al equipo Scrum a usar correctamente Scrum (todos sus eventos, artefactos, valores y principios).
• Enseñar al Product Owner a ser un buen Product Owner.
• Enseñar a la Organización Scrum y Agilidad.
• "Coachear" al equipo Scrum en la transparencia, la comunicación, la toma de decisiones, la búsqueda del valor, la mejora continua, incertidumbre, empirismo, etc. 
• Ser un Facilitador tanto en los eventos Scrum como en los impedimentos del trabajo (y eso no significa que el SM deba hacerse cargo de remover todos los impedimentos).
• Ser un líder que da el ejemplo.

A todo lo anterior llamemos lo: "lo que debería ser".

Como yo lo veo y como se darán cuenta, es un Rol muy muy complejo, no es sencillo y como muchos indican ser Scrum Master es un camino de aprendizaje y mejora constante.

¿y que es lo que "No debería ser un Scrum Master"?

• Gerenciar el proyecto.
• Definir y responder por plazos.
• Tomar decisiones de arquitectura.
• Definir los requerimientos.
• Ser el jefe del equipo.
• Ser el responsable de la productividad.
• etc..

¿Donde esta mi emocionalidad en esta entrada?

Pues me ha tocado entrevistar a muchos Scrum Masters con experiencia... que solo cumplen 1 o 2 puntos de lo definido como "lo que debería ser" y que no siguen aprendiendo, desarrollándose, mejorando su rol....es decir hasta allí llegaron!, sin entender todo lo que debería poder hacer! ni como mejorar como Scrum Master! Y aquí me quiero detener para no generar malos entendidos o falsas dicótomas (Martín Alaimo Explica muy bien este tema acá https://www.youtube.com/watch?v=dqBUrK4cNqw )

No pretendo transmitir o explicar que un Scrum Master el día 0 debe ser "lo que debería ser". Al contrario es muy muy probable que el Scrum Master el día 0 (ya sea por, inmadurez de la organización y su rol, inmadurez del equipo, etc.) haga muchas mas cosas de las que "No debería ser". Y eso es natural es parte del proceso y no pretendo decir que un Scrum Master en esa posición sea un mal Scrum Master.

Lo que pretendo transmitir y este es el mensaje principal es que si un Scrum Master inicia su rol en el "No debería ser" y han pasado 10 sprints o 6 meses y no se ha movido ni un poco hacia "lo que debería ser", entonces no esta haciendo un buen trabajo y se quedo pegado en un rol de "Agile Project Manager"


Un Scrum Master debe tener habilidades para enseñar, para facilitar, debe ser humilde, vivir el proceso empírico y buscar su mejora continua y tener un hambre de conocimiento.


Si eres Scrum Master si quieres ser un verdadero Scrum Master y ejecutar tu rol como se debe...
Muévete del Agile Project Manager hacia el verdadero Scrum Master, día a día, paso a paso, desarrolla a tu equipo para que cada día sea mas ágil y ayuda a tu organización a entender verdaderamente tu rol.

personalmente recomiendo:

1° ejecuta el assessment gratis de scrum.org y mide tu conocimiento del core de Scrum.
https://www.scrum.org/open-assessments/scrum-open

2° lecturas que recomiendo

https://www.amazon.com/Agile-Estimating-Planning-Robert-Martin-ebook/dp/B004X1D3TC/ref=sr_1_9_twi_kin_2?s=books&ie=UTF8&qid=1527111834&sr=1-9&keywords=User+Stories+Applied

https://www.amazon.com/Liftoff-Start-Sustain-Successful-Agile-ebook/dp/B01IQ2FLY8/ref=mt_kindle?_encoding=UTF8&me=

http://www.caroli.org/book-fun-retrospectives/

https://www.amazon.com/User-Stories-Applied-Software-Development/dp/9332573700/ref=sr_1_3?s=books&ie=UTF8&qid=1527111834&sr=1-3&keywords=User+Stories+Applied

https://www.amazon.com/Scrum-Pocket-Guide-Practice-Publishing-ebook/dp/B00GY6WRTG/ref=sr_1_19_twi_kin_2?ie=UTF8&qid=1527111839&sr=8-19&keywords=scrum

https://www.amazon.com/Coaching-Agile-Teams-ScrumMasters-Addison-Wesley-ebook/dp/B003QP47YG/ref=mt_kindle?_encoding=UTF8&me=


Saludos!

CURSO: Scrum in Action

CURSO: Scrum in Action

¿Eres Scrum Master? o ¿quieres serlo y tomaste algún curso de certificación?
Entiendes los conceptos de Scrum, sus valores y principios, sus eventos y artefactos pero tienes dificultades para aplicar esto en la práctica?

Si las preguntas anteriores te identifican este curso es para ti.

Objetivo del Curso

Dar herramientas reales y transmitir experiencia que permita a los Scrum Master ejercer correctamente su rol, y desarrollar a los equipos que lideren en el uso correcto de Scrum y el camino Ágil.
Al finalizar el curso poseerás una serie de herramientas y conocimientos más avanzados que te permitirán usar Scrum de manera efectiva y permear su uso en una organización.


Requisitos

Conocer el framework Scrum, sus principios, valores, artefactos y eventos por estudio autodidacta o haber realizado algun curso de certificación como scrumalliance, scrummanager, scrumstudy, etc.



Temario

0. Base y Mitos de Scrum
1. ¿Como iniciar un equipo Scrum? ¿Inception? ¿Team Building?¿Sprint 0?
2. Armando el Product Backlog  y el Story Mapping
3. Y el DOD ¿como se construye?¿cuando se usa?
4. La primera Planning ¿Como? ¿y la velocidad del equipo? ¿Que capacidad? ¿y la estrategia de ataque del sprint?
5. La daily efectiva
6. La reunión de refinamiento ¿cuando? ¿como? ¿que?
7. La review ¿como ejecutarla? ¿Para quienes? ¿Su agenda?
8. La retrospectiva ¿ Siempre la misma dinámica? ¿que dinámicas? ¿Como se que esta bien ejecutada?
9. De un equipo novato a un equipo ágil.
10. El sprint día a día, la deuda técnica.

Valor

Hasta el 31 de mayo 130.000 luego 160.000
*Pago vía transferencia electrónica y Paypal https://www.paypal.me/agileaguilar/
*El valor incluye material educativo y 2 coffe break mañana y tarde, no incluye almuerzo.

Cuenta Corriente 03-79418-0
Banco Santander
Fabian Aguilar Fuentes
Rut 15.535.897-1
Enviar Comprobante a faaguilar@gmail.com
Fecha

Sábado 16 de junio de 9:00 a 19:00 horas

Lugar

Urban Station Eliodoro Yañez 869, PROVIDENCIA Metro Salvador Providencia, Santiago.

Consultas
https://www.linkedin.com/in/faaguilar/
faaguilar@gmail.com
https://goo.gl/forms/X9vcQ5EL2pvmQ7u82

Los Scrum Master están matando Scrum!

Los Scrum Master están matando Scrum!

Tengo tu atención?
de que va esto?

Cada día son mas y mas las organizaciónes que comienzan a usar Scrum como framework ágil para enfrentar sus proyectos de tecnología..lo cual es bueno pero...

También son cada día mas los Profesionales que veo ejerciendo el rol de Scrum Master en equipos que intentan ser ágiles y en donde el Scrum Master esta...muy demasiado lejos de su rol..

¿Que pasa cuando pones a un Scrum Master en un equipo que no es ágil y donde el propio Scrum Master esta aprendiendo Scrum o acaba de aprender Scrum?

Pues en la mayoría de los casos el equipo no termina haciendo Scrum, no se viven los valores o principios ni el pensamiento ágil, todo termina siendo un fracaso y la empresa termine diciendo... "eso de la agilidad son cuentos, no funciona!" o creen estar haciendo Scrum cuando no tienen ni la mitad de los reales beneficios.

Y es que la verdad a estas alturas no estamos para discutir si la agilidad funciona o no... la agilidad funciona! existe evidencia, estudios, empresas, ejemplos, etc... lo que no funciona es como las empresas están intentado primeramente hacer agilidad (Agile Delivery con Scrum)

¿Que esta pasando entonces?

Bueno varias cosas...
1° Se esta llenando de Scrum Master sin experiencia..o sin pensamiento ágil por varias razones:
A.- Empresas envían a sus Jefes de Proyectos a cursos de Scrum en donde al cabo de 2 días terminan certificados o no...y finalmente la empresa piensa que ya tiene un Scrum Master y lo peor es que el antiguo jefe de proyecto también termina creyendo eso....pero en realidad su Pensamiento no cambio!
B.- Profesionales con buena intención están tomando cursos y certificándose de Scrum Master, como evolución de su carrera profesional, basándose en la demanda de roles del mercado. (lo que están muy bien). Pero la falta de experiencia y muchas veces no cambiar la forma de pensar les termina pasando la cuenta.

2° Supongamos que el nuevo Scrum Master si aprendió, tomo las practicas y valores de la agilidad, las hizo suyas y es como ve la vida desde ahora!
A.- La empresa en realidad no entiende el Rol del Scrum Master y le sigue exigiendo y midiendo como un Jefe de Proyecto, obligandolo a seguir actuando y pensando de esa forma.
B.- Lo asignan a ser Scrum Master de 10 equipos...o es Scrum Master para 1 equipo pero Jefe de Proyectos en 3 mas. Por tanto no llega un punto en que pueda desarrollar bien su rol.

Conclusión: Los Scrum Master están matando Scrum!

Bueno....en realidad no...

Lo que esta matando Scrum es..:
1° La Faltan de profesionales con experiencia....aun que valoro mas que la experiencia las ganas, valores y principios, el pensamiento ágil, el querer cambiar las cosas!
2° La fuerte demanda del Rol y el oportunismo (poco criterio) de organismos por vender certificaciones de Scrum Master lo que termina desprestigiando este bonito rol!
3° La falta de guía y humildad que nuevos Scrum Master están teniendo y creer que la agilidad son solo practicas para memorizar y no una forma diferente de pensar y enfrentar los desafíos.

¿Que puedo hacer si soy uno de estos Scrum Master que esta matando Scrum?

Mi humilde consejo o tips...son los siguiente:

1.- Elige bien tu escuela para aprender Scrum y Certificarte (ScrumAlliance o Scrum.org)
2.- Entiende que certificarte como Scrum Master es solo el primer paso al mundo Ágil y jamas ha pretendido ser una consagración.... con esto digo ahora es cuando deben comenzar a aprender, leer y profundizar temas.
3.- Busca un referente, guía, alguien que te puedo ayudarte a recorrer este camino.

Y dejo para el final lo que para mi es clave... si eres o fuiste Jefe de Proyecto:

a. Entiende que tu foco son básicamente 3 cosas, que el Scrum Team ejecute correctamente el framework, ser el coach del Scrum Team, ser un agente de cambio fuera del equipo.
b. Tu foco no debe estar en el objetivo del Sprint (ese es el pensamiento de un jefe de proyectos que vive la urgencia del hoy y pone toda su energía en cumplir los compromisos de la gantt)
c. Tu foco para decirlo en fácil debería ser, 20% de tu tiempo en facilitar impedimentos que el equipo pueda tener para cumplir los objetivos del sprint... y.. ¿por que tan poco?.. porque no es tu deber remover esos impedimentos sino mas bien generar los canales y comunicaciones para que el propio equipo sea capas de removerlos. Otro 20% en enseñar agilidad fuera del equipo, a la organización, y el 60% de tu tiempo restante en preguntarte ¿Que le falta a este equipo para ser ágil y usar bien el framework? ¿Como puedo hacer que este equipo se auto-gestione? ¿Como puedo hacer que el equipo aprenda a identificar sus fallos y mejorar? ¿Como puedo hacer que el equipo no necesite mi rol?

Querido nuevo Scrum Master antiguo Jefe de Proyecto, los objetivos del Sprint son para el Dev Team, ese ya no es tu desafió...tu desafió es desarrollar en el equipo su pensamiento ágil, empírico, la mejora continua, la auto-gestión, el conocimiento, el uso del framework Scrum...y otras cosas que sera tu desafió descubrir.... y no dejes que te sigan midiendo como jefe de proyectos!

Saludos!

Mejorar Equipos para Lideres de Equipo y Managers

¿Como mejora el rendimiento o capacidad de mi equipo?

A menudo veo preocupación en como mejorar el rendimiento o capacidad de los equipos y donde finalmente la única acción concreta que realizan los lideres o managers es la presión, es decir pedirles y pedirles mas trabajo a los equipos a modo de que en base a esta presión su rendimiento mejore.

Esto, seria una buena idea si estuviéramos hablando de esfuerzo físico, de un equipo atlético, etc. Por que efectivamente mediante la presión controlada y al exigir cada ves mas... es que aumenta la capacidad respiratoria, muscular, la coordinación, etc. (Con al correcta alimentación y descanso).

Pero, estoy seguro de que no están liderando a un equipo de deportistas profesionales, por tanto la estrategia no es la presión ...La presión en la era del trabajo del conocimiento, no genera una mejora de rendimiento o de capacidad sostenible en el tiempo, al contrario, en el corto plazo si provee una ilusión de mejora, pero en el largo plazo es insostenible y solo genera estrés, baja calidad en el trabajo y que los miembros de equipo comiencen a buscar un nuevo empleo.

La manera de enfrentar esto es, bajando el rendimiento del equipo.

¿Bajando el rendimiento del equipo!!?

Exacto!, si por periodos de tiempo bajamos el rendimiento del equipo dedicado al trabajo diario y destinamos por ejemplo un 20% de su tiempo a mejorar, sus procesos, sus técnicas, sus conocimientos, etc... entonces luego de aplicar estas mejoras el rendimiento del equipo sufrirá un incremento sostenible en el tiempo!!

Cuantas veces me he topado con la triste realidad de equipos o áreas con problemas claros que todos conocen deben mejorarse, pero que nadie aborda... ¿por que?   porque están demasiado ocupados en el día a día.

Es responsabilidad de los lideres y managers decidir y planificar efectivamente de que forma y en que periodos los equipos dedicaran parte de su tiempo a mejorar  y menos tiempo al trabajo del día a día.

¿Tu que acciones concretas estas tomando para mejorar el rendimiento o capacidad de tu equipo? Recuerda que no son deportistas profesionales.

¿Agilidad?, Culto y bala de Plata

¿Agilidad?, Culto y Bala de Plata


Hago esta entrada en mi blog inspirado en una frase que compartí en linkedin, donde capte varias ideas y experiencias de contactos de mi red.

Vamos por parte...

Ciertamente la agilidad se presta para malos entendidos por varias razones..
Primero porque cuando se declaro el manifiesto ágil no se estableció un concepto formal y claro de lo que era agilidad y segundo porque la agilidad de esos tiempo al día de hoy a cambiado y finalmente cada uno de nosotros puede llegar a tener su propia definición de agilidad con un núcleo claro pero matices diferentes..

Otra parte que complementa a este mal entendimiento es que muchos ven la agilidad como algo utópico o casi una secta y es que para muchos agilistas o "evangelizadores"  la agilidad es como eso...algo sagrado y lo transmiten de esa forma, donde pareciera mas fanatismo que realmente un conjunto de practicas, valores, principios y forma de trabajo basada en la experiencia, lean, trabajo de equipo, desarrollo de personas, sentido común, etc.

Ya sea por falta de experiencia y otros factores muchas transformaciones hacia la agilidad se han abordado de la forma incorrecta y han fracasado..dejando ese sabor de que la agilidad no sirve.

En mi experiencia y propio conocimiento

La agilidad no es ninguna bala de plata que viene a resolver todos los problemas, mas bien te invita a hacerte cargo de ellos de manera real y mejorar constantemente.

No me considero un fanático de la agilidad, mas bien soy un fanático de hacer las cosas bien y estoy convencido de que hoy la mejor forma de trabajo es a través de la agilidad y mañana quizás sea otra cosa... pero la agilidad es difícil de hacer dado que requiere que pensemos y actuemos muy diferente de como estamos acostumbrados.

La agilidad no es un fin es un medio, mediante el cual equipos de trabajo y organizaciones logran de mejor manera los pasos hacia los objetivos que persiguen y aprenden en cada paso.

En la era de la revolución industrial 4.0 o era digital, la agilidad se ha vuelto una habilidad primordial requerida por las empresas para competir y sobrevivir en la incertidumbre de los diferentes sectores industriales donde las tecnologias cambian constantemente y la amenazada de nuevos competidores que cambien las reglas del juego es constante.

En mi experiencia la agilidad necesita de la innovación, y viceversa. A través de la innovación la organización debe generar ideas que le permitan competir y estas ideas deben ser ejecutadas con agilidad para ser probadas de manera temprana en el mercado y obtener resultados a modo de mejorar esa idea o cambiar de rumbo y probar una nueva.

La innovación debe ser tratada como una habilidad de la organización en donde las buenas áreas o gerencias de innovación mas que ellas mismas innovar deben lograr que la organización completa innove de esta forma se genera realmente la habilidad en la compañía y de la misma forma la agilidad empresarial , las nuevas gerencias ágiles que muchas empresas están creando, mas que ellas trabajar con agilidad deben educar y soportar a que el resto de áreas de la organización trabajen con agilidad, eso es lo que realmente generara en la organización la habilidad que se busca con la agilidad.

Idea dedicada a Karla Figueroa que comento en linkedin: Scrum es un framework ligero que permite trabajar con agilidad.. el rol del Scrum Master es Crucial para un correcto entendimiento del framework, uso y transmisión al resto de la organización. (acá muchos pensaran que cuando un equipo ya lleva mucho tiempo trabajando en Scrum y es avanzado no necesitan de un Scrum Master... bueno quizás si o quizás no) lo cierto es que el rol es fundamental pero muchas veces fracasa su uso porque el rol del Scrum Master puede estar mas implementado, ya sea por poca experiencia, falta de compromiso de la organización o de los otros roles, falta de entrenamiento y entendimiento de roles, etc.

Certificaciones Scrum

Certificaciones Scrum

En esta entrada intentare dar una guía respecto de todo el abanico de entidades certificadoras que existen de Scrum, primero basado en las hechos y al final una recomendación (opinión), puede que hiera sentimientos en personas que ya tienen certificaciones de las organizaciones que aquí discuto...aun que no es el sentido ofender las certificaciones de nadie.

Aclaración: Ninguna certificación te hace mejor en tu rol, hay gente no certificada muy buena en Scrum porque han aprendido de la teoría y de la practica y se han rodeado también de mentores asombrosos y gente certificada muy mala que se queda con la certificación y nada mas, por tanto una certificación no es realmente una garantía absoluta del nivel profesional mas solo del conocimiento académico y de la capacidad de estudio de una persona.

Por otro lado esta entrada pretende ser una guía basica y no profunda en detalle de cada una de las organizaciones.

Hechos

Scrum Alliance: Fundada en 2001 por grandes maestros como Ken Schwaber y Mike Cohn, es la entidad mas antigua de Scrum y la mas conocida mundialmente, posee varios track de certificación desde Scrum Master, Product Owner, Scrum Developer, Team Coach, Enterprise Coach, etc.
Todas sus certificaciones requieren de manera obligatoria la asistencia a un curso, en promedio los cursos tiene un valor de 1000USD e incluyen 2 intentos de examen.

Scrum.org: Fundada en 2009 por Ken Schwaber (co-creador de Scrum y fundador también de la Scrum Alliance), tuvo diferencias respecto de en lo que se transformo la Scrum Alliance y creo su propia organización. Conocida mundialmente, posee también varias certificaciones, a diferencia de la ScrumAlliance no exige tener un curso oficial de Scrum para rendir los exámenes, los exámenes de la Scrum.org son los mas difíciles de todas las entidades certificadoras.


Scrum Manager: Fundada en 2006, es muy conocida principalmente en habla hispana, posee 2 certificaciones una de Scrum Manager y otra de Scrum Level, los cursos son obligatorios para obtener las certificaciones, una ves certificado ofrece varios cursos gratis de perfeccionamiento y mantenimiento del nivel de certificación.


ScrumStudy: Es una empresa de Vmedu, dedicada a la educación y certificación principalmente online, desarrollo el SBOK que es una guía de Scrum propia que combina Scrum con ámbitos tradicionales de la gestión de proyectos. Provee varias certificaciones de Scrum, sin requisitos previos, que deben ser mantenidas cada 3 años modelo similar al del PMI.


Scrum Institute: Se publicitan como las certificaciones mas baratas del mercado, no tienen prerequisitos y solo basta con dar un examen on line. Incluso te certifican como Scrum Trainer con un examen online de 50 preguntas.


Opinión

Ahora vamos...no busco ofender con mi opinión...pero..

Scrum Institute: Lo descarto como centro certificador que pudiera recomendarle a alguien me parece un chiste lo fácil que son sus examenes y PEOR que por 99 dolares y 50 preguntas te certifiquen como entrenador Scrum!

Scrum Study: También lo descarto como centro certificador que pudiera recomendarle a alguien, lo veo mas serio que el Scrum Institute, pero de todas formas sus exámenes son sencillos y no tienen prerequisitos.

Scrum Manager: Tiene un buen espíritu y buenos entrenadores, su entrenamiento es mas serio a pesar de que el examen de certificación que tienen es muy fácil al nivel de Scrum Study. Si en tu país dan curso de Scrum Manager no lo descarto como opción pero no es la primera.

Scrum Alliance: Sin duda como uno de las organizaciones con mas historia y mas reconocida a nivel mundial la recomiendo, sus cursos son muy buenos y son ejecutados por facilitadores de alto nivel (Ser un entrenador de la Scrum Alliance no es sencillo es un proceso largo y de varias etapas), si tienes el dinero y hay facilitadores de la Scrum Alliance dando cursos en tu País entonces es una de las mejores opciones que puedes tomar.

Scrum.org: Los exámenes mas difíciles de Scrum son los de la scrum.org no solo miden la comprensión del framework sino también la aplicación en escenarios reales. Me atrevo a decir que alguien que tome un curso de la Scrum Alliance no podrá pasar un examen de la Scrum.org sin antes estudiar bastante. Como sus certificaciones no piden un curso obligatorio puedes pagar por dar el examen no sin antes estudiar MUCHO, ahora si en tu país tienes la oportunidad de asistir a un curso oficial de la Scrum.org (si tienen cursos y entrenadores oficiales) entonces....tómalo! yo no he tenido la oportunidad... pero la leyenda dice que son los mejores...y deben serlo para poder prepararte para sus exámenes, ademas que el proceso de acreditarte como entrenador de la Scrum.org es el mas complejo de todos!

Independiente de lo que te recomiende siempre tendrás el facto del dinero..¿ que certificaciones puedes o estas dispuesto a pagar? y disponibilidad.. ¿que cursos y entrenadores están disponibles en mi país?

Saludos!

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