El interés sobre el mundo de la Agilidad está creciendo sin duda alguna. He identificado tres tipos o fases de interés en la industria local.

1. Curiosidad: “Se está hablando mucho sobre Ágil y Scrum, ¿qué será eso?”
2. Impacto emocional inicial: “Parece que Ágil solucionaría nuestros problemas más importantes, pero no lo termino de entender muy bien.”
3. Determinación: “¡Quiero que mi organización lo implemente!”

La mayoría de organizaciones están entre las etapas de Curiosidad e Impacto Inicial Emocional. Durante estas etapas iniciales, todavía no hay mucho interés en querer adoptar realmente Scrum.

Para llegar a la etapa de Determinación, he visto que se requieren al menos uno de los siguientes factores:

• Requerimiento Explícito de Negocio: Usted es un proveedor de servicios de desarrollo de software y un cliente importante, o potencial, está requiriendo prueba de su adopción de Scrum. Este panorama no es nada raro, y menos raro aún es la recomendación (y hasta exigencia) de inversionistas de capital de riesgo para que las empresas usen Scrum.
• Por convencimiento propio: Usted ve en Scrum la herramienta que necesitaba para manejar requerimientos cambiantes, cerrar adecuadamente el abismo entre clientes y desarrolladores de manera que el equipo desarrolle lo que el cliente quiere, lograr mayor compromiso de los miembros de equipo o elevar la calidad de código entregado…

Es claro que pasar de “tengo que implementar Scrum” a “quiero implementar Scrum” es vital para facilitar la adopción. Incidentalmente, he observado un gran problema del “tengo que implementar Scrum” en varios proveedores de servicios de desarrollo de software que usan “Scrum” o “Ágil” como argumento de venta y en realidad no han adoptado Agilidad o ni creen en tales cosas, creando una falsa percepción de lo que realmente significa es Ágil o usar Scrum. [Si quiere saber si un proveedor está usando Scrum y a qué nivel, pregunte por las siguientes métricas durante la primera conversación: cuántos equipos Scrum tiene, por cuánto tiempo cada equipo ha mantenida más o menos la mismas personas usando Scrum, cuál es la velocidad de los equipos en Story Points por Sprint, cuál es la capacidad de carga de los equipos, cuál es la exactitud de las estimaciones y de los compromisos...]

Cuando por convencimiento propio se adopta Scrum, un sin fin de preguntas surgen respecto a la forma y velocidad en que la organización debe o puede adoptarlo.

Durante las últimas conversaciones con nuestros clientes de Prontitud, surge a menudo la pregunta: ¿Cómo convenzo al Gerente General (o a mi superior) de que adoptemos Scrum?  Esta pregunta es central en el proceso de transformación hacia Scrum. Si su organización no tiene un campeón en las altas gerencias con poder de decisión y económico que defienda y patrocine la adopción de Scrum, le espera un largo y pedregoso camino cuesta arriba.

Cuando me hacen esta pregunta, propongo tres posibles estrategias:

1. Que me permitan hablar directamente con el superior y hacerles una presentación sobre Scrum. He estado capacitando y viviendo la experiencia Scrum en la vida real, así que mi trabajo “vendiendo” Scrum por su valor real me sienta bien. Se logran sorprendentes resultados cuando la partes de negocios y altas gerencias tienen un claro panorama de Scrum y sus ventajas.
2. Realizar una Evaluación de Capacidad de Adopción de Scrum/Agilidad. Es más fácil convencer a las altas gerencias a primero hacer una evaluación antes de comprometerse a realizar una transformación organizacional. Esta evaluación me da la oportunidad de encontrar los dolores más grandes que tiene la organización y analizo la eficacia de Scrum para desaparecerlos. Presentar este tipo de análisis es muy convincente. El análisis lo obtengo a partir de conversaciones con los representantes de negocio y desarrollo en donde consigo respuestas a una gran cantidad de preguntas, algunas de las cuales son: ¿Cuánto apoyo hay desde las altas gerencias? ¿Cuánto entrenamiento se hará disponible a nivel institucional? ¿Habrá entrenamiento para el Product Owner? ¿Hay código fuertemente acoplado? …
3. Establecer un equipo piloto. Cuando las altas gerencias están con cierto convencimiento acerca el uso de Scrum, intento irme por la ruta de hacer un equipo piloto. Busco un proyecto o equipo que tenga criticidad media (desde el punto de vista del negocio) para entonces llevar a ese equipo a usar Scrum y medir los resultados en términos de incremento de valor entregado en cierto período de tiempo.  Una criticidad media es ideal porque es lo suficientemente crítico como para que su eventual éxito usando Scrum sea visible (y por lo tanto sea argumento convincente para escalarlo al resto de la organización), pero no tan crítico de manera que los gerentes digan que es muy peligroso intentar algo nuevo en algo tan crítico. Durante el período piloto, 1) la organización entera está consciente que hay un equipo que está recibiendo capacitación y coaching sobre Scrum con el fin de obtener un incremento de productividad en cierta cantidad de tiempo; 2) el equipo irradia información diariamente a todas las personas en la organización.

La transición a Scrum es un esfuerzo intencional institucional y estratégico con miras a resultados concretos. Es un esfuerzo que no se logra con solo leer unos libros de Scrum y unos blogs, requiere entrenamiento y guía. El conocimiento de los libros y blogs proveen un fundamento invaluable, el entrenamiento y guía provee la experiencia para entender el contexto organizacional para realizar la transición de forma exitosa. La transición requiere de una estrategia.

El inicio de la conversación lo marcaron dos realidades:

• La adopción de Scrum es un esfuerzo organizacional intencional: Si no hay un “champion“, “sponsor” en los altos mandos, es muy probable que el esfuerzo sea fútil. Si el valor de Scrum no es percibido en el upper-management, se está cuesta arriba. Al ser organizacional, los stakeholders experimentan una forma diferente de hacer las cosas. La adopción es arriba hacia abajo, no al revés.  Ahora bien, “de arriba hacia abajo” es la consecuencia, la causa es que alguien del upper-managament compró la idea. Tiene sus ventajas cuando todo empieza como un “grass-roots movement” o de “guerrilla” en las trincheras de ingeniería pues la inquietud llega arriba en algún momento y allí se puede convencer a alguien para que apoye la iniciativa para que entonces baje con respaldo.
• Fallar en concretizar el rol del Product Owner causa la mayoría de fracasos en adoptar Scrum. Y cuando digo “fracaso” me refiero que el proyecto no cumplió las expectativas, es decir, el proyecto falló.

Elaboraré un poco sobre el Product Owner, y trataré con mi explicación aclarar porqué no tener un Product Owner te lleva al fracaso (hey por eso hay certificaciones/cursos para llegar a ser un Product Owner, imagínese):
Mike Cohn en su libro Succeeding with Agile: Software Development Using Scrum menciona que el Product Owner tiene dos responsabilidades generales:

1. Proveer la visión.
2. Proveer los límites o condiciones, las restricciones.

La primera es generalmente clara, pero lo segunda se aborda muy poco.
Sin embargo la segunda responsabilidad es vital pues describe las realidades dentro de las cuales la visión debe concretizarse.
Los límites o condiciones vienen normalmente en la forma de restricciones:

• Lo necesito para Setiembre.
• Necesitamos reducir el costo por unidad a la mitad.
• Debe correr al doble de la velocidad.
• Debe usar solo la mitad de memoria que lo que usa ahora.
• Y por supuesto, una intrínseca, hasta obvia: No debe tener pulgas [bugs, defectos, seguiré llamándolos pulgas] según lo especificado.

Esas restricciones las da el Product Owner, pero a su vez son restricciones que fueron puestas sobre él por los stakeholders de una u otra forma.

El Product Owner jamás debe permitir que los usuarios finales reciban un “producto pulguiento”. Esa restricción de ser claramente transmitida al equipo desde el día uno. Si en la primera iteración el equipo entrega incrementos [User Stories "completos" según el equipo] pulgosos, el Product Owner no los puede aceptar. Él es responsable por eso. Si hay un problema de habilidades [QA, buenas prácticas, diseño, etc..] en el equipo, eso debe escalarse inmediatamente. Usando Scrum, se detecta ese problema muy temprano si no se ha detectado en el momento de conformar el equipo.

Realmente el Product Owner pasa muy ocupado: Recibiendo requerimientos y coordinando con todos los stakeholders, actualizando el Product Backlog, confirmando que las restricciones se están cumpliendo.

Un buen Product Owner es aquel que complementa sus habilidades con Product Management. Como consejo:en algunos casos es más fácil decirle al upper-management que necesitamos un “Product Manager” en lugar de decir ocupamos un “Product Owner“.

Espero ser claro en este punto: El equipo de desarrollo no puede transgredir los limites establecidos por el Product Owner, a menos claro, que esos límites sean absurdos, cínicos, imposibles. El equipo no anda por la libre haciendo lo quiere. El equipo debe complacer completamente las expectativas del Product Owner según las restricciones que él establezca.

Y atención: El Product Owner define el “qué” y las restricciones, el equipo define el “cómo”. En el ámbito del “cómo” (de nuevo, según las restricciones) el Product Owner no tiene autoridad. El ScrumMaster ayuda al equipo a encontrar un “cómo” que mejore continuamente y lo lleve a ser hiper-productivo.

Product Management

¿Conviene tener un departamento o equipo de Product Management? La respuesta a eso depende si la institución debe crear varios productos de cierto tamaño los cuales deben obedecer a una estrategia institucional que se revise cada cierto tiempo.
Ser un Product Manager es una de las profesiones más difíciles pero importantes. Por eso es difícil encontrar alguien que quiera aceptar un puesto así. Debe construir un producto tomando como entradas:

1. La estrategia de negocio: “Durante este año iremos en esta dirección”.
2. Las opiniones y requerimientos de los stakeholders, que a veces son varios: Muchos managers queriendo meter la cuchara.
3. La retroalimentación continua de los usuarios finales.
4. Las tendencias de mercado. Coordinar constantemente el departamento de ventas y el de mercadeo.
5. Requerimientos para cumplir con las leyes estatales y regulaciones institucionales internas.
6. Criterio técnico del equipo de desarrollo.

El éxito de un equipo de Scrum estriba dos factores:

• Product Managenement: Una buena definición del Producto y evolución del mismo.
• Project Management: Un ciclo de desarrollo de software iterativo incremental basado en la retroalimentación constante y la auto-regulación de un equipo multifuncional.

Después de haberse realizado este evento de naturaleza única en Costa Rica, haré una retrospectiva del evento:

Cosas que se hicieron bien, para seguir haciendolas:

• Capacidad de adaptación: Después del Visual Studio Agile Morning tuve oportunidad de recibir impresiones de los asistentes de manera que se pudo cambiar la dinámica de la tarde sin perjudicar el contenido ni expectativas de la tarde.
• Fomentar discusión constructiva: La insistencia de los conferencistas en preguntar por dudas u opiniones a favor o en contra le dio un agradable sabor, especialmente en el tarde.
• Experiencias reales: La teoría es buena solo en el tanto que la realidad la valide.  Cualquiera puede dar un conferencia de un tema cualquiera, solo el que la ha puesto en práctica puede expresar mejor el valor obtenido.
• El presentador es el show: Filminas ligeras, presentadores dinámicos.

Cosas a mejorar:

• Teoría primero, práctica después: Debimos haber presentado el material teórico en la mañana y el práctico en la tarde.
• Código en exceso aburre: No es que no haya sido provechoso ver código, pero se valora más el motivo por el que una práctica de codificación es ágil, que la práctica. La próxima vez mostraremos más transfondo ágil y menos código en las sesiones sobre buenas prácticas ágiles.
• Separar físicamente simulaciones de las conferencias:  Las simulaciones requieren pocas personas y mucha facilitación. Un AgileFest puede fácilmente tener simulaciones corriendo al mismo tiempo que se dan conferencias.

El AgileFest fue intensamente educativo. Hubo muchísimo conocimiento expuesto y muchísimo interés en absorberlo. Costa Rica sigue dando sus primeros pasos en la adopción del pensamiento ágil, y en Prontitud seguimos facilitando esa adopción.

¡Nos vemos en el próximo AgileFest!

Agradecimientos:

El auditorio de la Universidad Latina en San Pedro de Montes de Oca fue muy cómodo y adecuado para el evento. Muchas gracias al Ing. Christian Sibaja, Decano de la Facultad de Tecnologías de Información. La Universidad Latina está haciendo un excelente trabajo al promover este tipo de actividades y al apoyar a diferentes grupos de usuarios. De veras que hay mucho énfasis en dar en las carreras de Software y Telemática herramientas y conocimientos actualizados.

El evento tuvo mucha difusión también gracias a al Centro Tecnológico de Entrenamiento (CTE). Gracias a Mario A Sanabria, Gerente General. CTE está expandiendo su rango de cursos y certificaciones para satisfacer necesidades empresariales de alto nivel para mejorar productividad. Excelentes instructores y amigos los que trabajan en CTE.

El Manifiesto Ágil fue el escrito público que unificó en un solo lugar las ideas fundamentales y principios detrás del éxito que varios profesionales del desarrollo del software por fin tenían.

Lo más llamativo del Manifiesto es que rompía con los preceptos tradicionales de la administración de proyectos.

Escúchennos a Elmer y a mí comentar al respecto.

La validez de esta pregunta radica en el énfasis de la palabra “valor”. Precisamente cualquier interés que se tenga en Scrum debe estar basado en el valor que Scrum por sí mismo provea, así que primero me dirigiré tratar valor que provee Scrum como marco de trabajo para el desarrollo de software, luego abarcaré el valor de asistir a un Taller de Certificación de Scrum.

Padecimientos en el mundo del software

El desarrollo software tradicional alrededor del mundo tiene dos enfermedades:

1. Interrupción del flujo del “valor”. Me refiero al flujo que empieza desde que el cliente define el valor que quiere obtener y que termina cuando obtiene el producto que debiera reflejar ese “valor”.  Me refiero a la incapacidad de sintetizar las necesidades del cliente (customer value) y transmitirlas fielmente a equipo de desarrollo para ser implementadas. Esto se traduce en, en el mejor de los casos, completar un producto que cumple con el documento de requerimientos, pero no con las expectativas del cliente.
2. Desperdicio. Le reto a que dedique un momento para calcular cuánto tiempo (mejor aún, tradúzcalo a dólares) que es desperdiciado en:
   • Reuniones irrelevantes para la mayoría de los asistentes.
   • No llegar a tiempo a reuniones que sí son relevantes para todos los asistentes.
   • Yendo y viniendo entre el Departamento de Desarrollo y el Departamento de QA.
   • Discutir e implementar cosas que no son prioritarias.
   • Planear con detalle microscópico tareas que al final no terminan haciéndose tal y como se planearon.
   • Tener un equipo que tiene el rendimiento de un grupo disjunto individuos.
   • Encontrar problema muy tarde en el progreso del proyecto, tan tarde que corregirlo es muy costoso.
   • Etc… puedo seguir enumerando muchas más, pero no quiero aburrir.

Dándole valor al valor

La columna vertebral de Scrum es el Product Backlog. Este artefacto es una lista de requerimientos priorizada por “valor” desde el punto vista del cliente. El formato que tiene y el tratamiento que recibe durante todo el proceso de desarrollo de Software Scrum hace que constantemente esté validado contra las expectativas del cliente.

Scrum es iterativo basado en retroalimentación. Esto permite manejar de forma realista y exitosa la naturaleza incierta inherente a todo proyecto de software. Esa incertidumbre que es tan bien manejada por Scrum viene de dos frentes:

1. Desde el negocio. La mayoría de las veces, el cliente solo tiene una idea de lo que quiere. Lo único que tiene claro es que le duele algo y quiere algo que alivie ese dolor. Aún en el rarísimo caso que el cliente ya tenga una lista de requerimientos priorizada, la realidad es que conforme pase el tiempo se enterará de nuevas restricciones de mercado, o mejor aún se le ocurrirán mejores ideas. Y si tiene oportunidad de ver creciendo el producto implementado, va a querer cambiarlo para mejorarlo. Observe que asocio “cambio” con “mejoría”, por lo que adoptar una política de castigar el “cambio” no ayuda a entregar lo que el cliente realmente quiere.
2. Desde la plataforma tecnológica. Un producto de software es la suma de miles de decisiones de naturaleza tecnológica que son imposibles de conocer de antemano. Esto es cierto aún si el mismo equipo ha desarrollado proyectos anteriores usando la misma plataforma tecnológica.

Scrum logra el manejo de estas incertidumbres mediante el mantenimiento constante del Product Backlog, el manejo de Sprints cortos y la dedicación exclusiva de un Product Owner como ente enteramente responsable de mantener el Product Backlog, y por lo tanto, de entregar lo que el cliente quiere. La herramienta más poderosa que tiene el Product Owner para lograr este cometido son los Sprint Reviews.

En resumidas palabras, Scrum dedica su existencia a que el concepto de valor sea fidedignamente transmitido al equipo de desarrollo.

Desperdicio es el enemigo

El ScrumMaster es quien lidera la lucha contra el desperdicio. En su rol de facilitador del equipo y líder servil, es también un vigilante constante del timeboxing de las reuniones y en contra de divagaciones durante las mismas.  Constantemente revisa que haya fluidez de tareas en el Taskboard y asegurándose que el equipo trabaja según la prioridad establecida para los User Stories del Sprint.

No hay que olvidar el claro rol del ScrumMaster: Desaparecer impedimentos, recordar constantemente la visión, dar constate visibilidad al estado del proyecto.

En Scrum se busca detalle microscópico en el Sprint en el que se va a trabajar,  pero visión panorámica para el resto del Backlog, evitándose el sobre-planeamiento común en la administración tradicional de proyectos.

En lugar de tener un grupo de personas trabajando en un proyecto, Scrum promueve pasar de grupo a un equipo. Reflexione sobre diferencia: tendrá un equipo cuando el rendimiento combinado de las personas sea mucho mayor que la suma por separado del rendimiento de cada persona. La forma en que se facilita desde el Planning Meeting hasta el Daily StandUp ayudan sincronizar al equipo, a empoderarlo para ser auto organizado en lugar que micro-manejado.

Pero todo eso lo puedo leer en blogs y libros

De eso no hay la menor duda. ¿Cuán complejo es el fundamento teórico del fútbol, es más, del ajedrez? Nada complejo, tienen reglas sencillas. Aún así, no es lo mismo ver a unos niños de escuela jugando futbol que un partido de futbol mundialista, aunque en el fondo están usando el mismo conjunto de reglas para jugar. Por más que sepa todas las reglas de ajedrez, le es fácil reconocer que requiere de las enseñanzas alguien con mayor destreza para  desarrollar pensamiento analítico y estratégico.

¿Cuáles son los retos a los que se enfrentará al implementar Scrum en su empresa? ¿Cuáles son los principios detrás de Scrum que son los que al final vale la pena siempre recordar cuando se deba tomar una decisión? Una vez teniendo una panorama completo de Scrum, en cuáles aspectos debe profundizar, dadas sus circunstancias? ¿Cuáles advertencias (basadas en mucha experiencia en equipos de Scrum) sobre adopción de Scrum me pueden ser útiles?

Scrum delinea conceptos que al oírlos explicados suenan con tan sentido común. Sin embargo recuerde que el sentido común deja de ser “común” cuando se está inmerso en el diario manejo de problemas y vacas sagradas de los ambientes de trabajo. Además, no es lo mismo reconocer un concepto a interiorizarlo.

Finalmente, aquí dejo un brevísimo video que recoge las impresiones de dos profesionales cuando les pregunté sobre cuál era el valor de haber asistido al Taller de Certificación de Scrum impartido por Michael Vizdos en Costa Rica:

Prontitud es la representante para Costa Rica de ScrumManager.

¿Todas las personas que asisten a mi taller obtienen la certificación?

Usted obtendrá un certificado emitido desde España, por la empresa ScrumManager, en el que hace constar que usted ha participado en el taller y que por tanto comprende las bases de la adopción de SCRUM y de una Administración de Proyectos Ágil.

¡Inscríbase ahora!

¿Qué sigue?

Si usted está interesado en convertirse en un CSM, por favor siga leyendo.
Por favor, con David Alfaro o con Elmer Fonseca si usted está interesado en ser notificado cuándo el próximo taller está disponible públicamente.

Propósito

Aprender y comprender:

• Las razones, fortalezas y debilidades de los modelos de procesos y prácticas de la industria del software.
• A gestionar proyectos y equipos de programación con los criterios de procesos y agilidad más adecuados a las características de su empresa y de su producto
• Las fortalezas y debillidades y criterios de decisión entre gestión predictiva y la gestión ágil.
• Los criterios y estrategias para la gestión ágil de organizaciones, proyectos y equipos para desarrollo de software.
• Todos los componentes del modelo Scrum de forma práctica:
  • Propietario de producto: responsabilidades, visión, plan de producto y product backlog.
  • Responsabilidades y artefactos del equipo: estimación y métricas ágiles, pila del sprint (sprint backlog), gráfico de avance (burndown), pizarras kanban.

Responsabilidades y estrategias de la organización en la implantación y mejora de una “Scrum Management”

Este curso ofrece el conocimiento y comprensión necesaria para la adopción flexible y global de agilidad en empresas de software. Flexible porque además de las prácticas concretas del modelo Scrum, cubre los principios y criterios para su adecuación a la propia empresa y gestionar su mejora continua; y global porque, además de la aplicación de Scrum en la gestión de proyectos, cubre las implicaciones de la agilidad en el resto de la empresa.
Es una formación basada en la práctica: simulaciones de scrum, plan de producto, product backlog, estimación ágil, vídeos y ejercicios de simulación. Los alumnos que deseen realizar y superen los ejercicios de capacitación al final del curso, obtendrán la acreditación profesional oficial de Scrum Manager.

Descripción general

Esta es su oportunidad de aprender acerca de Scrum – en el mundo real – de los expertos del sector. Venga preparado para desafiar las creencias viejas y estar abierto a nuevas formas de pensar acerca de cómo enfocar el trabajo en el futuro.

Requisitos

• Revisión de “La Guía de Scrum” – por Ken Schwaber – Disponible en htp://www.scrumalliance.org/resources/598 para su descarga.
• Conocimientos básicos de Administración de Proyectos bajo las mejores prácticas del PMI (PMBOK)
• Haber leído uno de los libros de Scrum
• Comprender los fundamentos de la gestión de proyectos
• Comprender requerimientos y descomposición de requerimientos
• Haber estado en (o estrechamente involucrado con) un proyecto que construye o mejora un producto
• Querer saber más sobre cómo Scrum funciona, cómo utilizarlo y cómo ponerlo en práctica en una organización
• Para alguien con estas habilidades, no sólo para expertos.

Temas

Marco Scrum Manager
Producción basada en procesos
Mapa general de modelos de procesos y prácticas
Gestión predictiva de proyectos fortalezas y debilidades.
Principios ágiles
El escenario de nuestras empresas

• The New New Product Development Game
• Características de los campos de Scrum

Gestión de proyectos ágil: objetivos, fortalezas y devilidades
Ciclo de desarrollo ágil
Principales modelos ágiles
Criterios de gestión predictiva / ágil
El modelo Scrum

• Introducción: principios, valores, reuniones, elementos y roles.
• Requisitos y visión del producto
• Pila del producto (product backlog)
• Pila del sprint (sprint backlog)
• Sprint
• Incremento
• Reunión de planificación
• Revisión diaria
• Reunión de cierra
• Retrospectiva

Medición

• Introducción
• Criterios para el diseño y aplicación de métricas
• Unidades: velocidad, trabajo, tiempo.
• Gráfico de producto (burn-up)
• Gráfico de sprint (burn-down)
• Estimación de póquer
• Valores, principios y conclusiones

Audiencia

Este taller está enfocado principalmente hacia las personas que están interesadas en conocer las metodologías ágiles para el desarrollo de Software, y aquellos interesados en conocer sobre la Administración Ágil de Proyectos, aprovechando los conocimientos que se tengan acerca de la propuesta que hace el PMI, sobre la gestión de proyectos..
Funciones dentro de sus organizaciones actuales pueden incluir:

• Arquitectos
• Analistas
• Desarrollador
• Especialistas en documentación
• Ejecutivos
• Gerentes
• Project Managers
• Testers
• Miembros de Equipo

Duración

Dos días.
Nota: Planee ir a los dos días tiempo completo (8:30-4:30 hora local).

Instructores

Elmer Fonseca:
Socio fundador de Prontitud, Ingeniero en Computación.
Tiene más de diez años de experiencia en el mercado de soluciones de software y de networking,
Es máster en Administración de Proyectos, ha dado charlas con respecto a la Administración Ágil de proyectos.
Experiencia en el sector privado y gobierno. Es miembro del PMI y de la comunidad Agile Community of Practice del PMI.

David Alfaro:
Socio Fundador de Prontitud,Ingeniero de Software.
Tiene más de diez años de experiencia en el mercado de soluciones de software.
Es Scrum Master Certificado, ha dado numerosos cursos y talleres en torno al desarrollo ágil de desarrollo de Software con Scrum.

¿Cómo inscribirse?

¡Inscríbase ahora!

¿Qué significa trabajar con un Certified Scrum Trainer?

Garantiza que se está trabajando con un grupo muy pequeño de personas en el mundo que le puede enseñar a ser un CSM (Certified ScrumMaster) y que yo también soy un Certified Scrum Pactitioner que trabaja con equipos de Scrum diariamente. Doy entrenamientos porque me encanta enseñar a la gente acerca de Scrum. Y aprender más sobre Scrum. Siempre.

Todos los Talleres CSM (algunas personas lo llaman un curso, yo lo llamo un taller) impartido por instructores certificados Scrum utilizan los mismos materiales de base para enseñanzar.

La mayoría de Certified Trainers de Scrum han trabajado con Ken Schwaber (uno de los fundadores de Scrum, y sí, he trabajado con él y fuí enseñado directamente por él – no por ningún otro entrenador) y se reúnen cara a cara por lo menos una vez al año (en algún lugar del mundo) para asegurarse de que nuestras enseñanzas base y conceptos sean coherentes. Usted puede leer más acerca de lo que todos los instructores certificados de Scrum utilizan como base para sus materiales. Esta información es la vigente en nuestra última reunión de instructores.

No importa lo que haga, asegúrese de que su certificación es entregada por un entrenador certificado de Scrum. Si usted tiene alguna pregunta … póngase en contacto con la Alianza Scrum directamente por correo electrónico o teléfono.

Si bien cada entrenador Scrum Certificado utiliza la misma base de materiales para la enseñanza, cada uno de nosotros presentará maneras únicas y diferentes.

¿Todas las personas que asisten a mi taller obtienen la certificación?

No. Usted tiene que estar comprometido y activo en los ejercicios y conversaciones. ¡Por favor! Además, antes de ser certificado como un ScrumMaster tendrá que pasar un examen administrado por la Alianza Scrum, el organismo de certificación. Información acerca de esta prueba se puede encontrar en: http://www.scrumalliance.org/pages/certified_scrummaster_csm ¡Inscríbase ahora!

¿Estás esperando un recetario Scrum?

No hay ningún recetario para Scrum. Hago hincapié en esto a menudo durante el taller. Yo uso muchas de las técnicas ágiles que enseño con el fin de elaborar y presentar este taller. Un ejemplo es el hecho de que la mayoría de mis talleres son co-enseñados (con otro entrenador Scrum Certificado) y el uso de “emparejamiento” como una técnica para ofrecer el taller. Esto le da, a mi cliente, dos personas diferentes con experiencia para hacer hacer preguntas y obtener diferentes puntos de vista y comentarios. Además de revisar y adaptar después de cada taller (y algunas veces durante el día). Tenemos mucho material para compartir con ustedes, y si es adecuado hablar con un determinado grupo de personas sobre un tema en particular, nos ajustaremos cuando sea necesario (revisar y adaptar).

Recuerde …

Usted saldrá de este taller de dos días con lo que puso en él. Preste atención, participe y piense en qué cosas discutir – y así usted se convertirá en un ScrumMaster Certificado. Incluso le enseñaré el apretón de manos secreto si lo desea (solo este secreto celosamente guardado vale la pena el precio de la entrada!).

El viaje – su viaje – ha comenzado una vez que se convierte en un CSM. Este es un viaje que sego caminando todos los días.

Lo invito a ponerse en contacto conmigo o con David Alfaro si tiene alguna pregunta antes de inscribirse.

Si desea ver más información acerca de mi estilo, eche un vistazo a mi sitio de aplicación Scrum (o blog, dependiendo de su interpretación). Yo lo mantengo regularmente. El sitio está ganando impulso en nuestra industria, y se están aprendiendo lecciones de ahí. La enseñanza es algo que me gusta hacer. Y me recuerda los conceptos básicos importantes que debo recordar como Certified Scrum Practitioner que trabaja con equipos diariamente. Yo no enseño este taller como mi trabajo de tiempo completo, yo realmente hago trabajo con equipos todos los días para ayudarles a aplicar Scrum, y enseño con el fin de ayudar a otros que están sinceramente interesados en comenzar a usar Scrum.

¿Qué sigue?

Si usted está interesado en convertirse en un CSM, por favor siga leyendo.

Por favor, póngase en contacto conmigo con David Alfaro si usted está interesado en ser notificado cuándo el próximo taller está disponible públicamente. A continuación aparecen los detalles de mi taller. Por favor, revise y quiero saber si usted tiene alguna pregunta.

Idioma

Inglés. Tendré el apoyo de David Alfaro cuando algo requiera clarificación en español, si es necesario.

Propósito

Enseñar a alguien cómo ser un ScrumMaster en su organización.

Descripción general

Esta es su oportunidad de aprender acerca de Scrum – en el mundo real – de uno de los expertos del sector. Venga preparado para desafiar las creencias viejas y estar abierto a nuevas formas de pensar acerca de cómo enfocar el trabajo en el futuro. Objetivos Al completar exitosamente el taller (y esto es con cualquier Certified Scrum Trainer), habrá una prueba realizada por la Alianza Scrum (el organismo de certificación que le dará su certificado). Los detalles de este examen se puede encontrar en: http://www.scrumalliance.org/pages/certified_scrummaster_csm

Requisitos

• Revisión de “La Guía de Scrum” – por Ken Schwaber – Disponible en http://www.scrumalliance.org/resources/598 para su descarga.
• Haber leído uno de los libros de Scrum
• Comprender los fundamentos de la gestión de proyectos
• Comprender requerimientos y descomposición de requerimientos
• Haber estado en (o estrechamente involucrado con) un proyecto que construye o mejora un producto
• Querer saber más sobre cómo Scrum funciona, cómo utilizarlo y cómo ponerlo en práctica en una organización
• Para alguien con estas habilidades, no sólo para expertos.

Temas

Los temas pueden variar de un taller a otro. La razón principal de esto es debido al hecho de que cada público tiene diferentes necesidades y requisitos. Posibles temas incluyen:

• Material Introductorio
• Scrum 101
• Rol del Scrum Master
• Rol del Product Owner
• El Equipo
• “Listo”
• Retrospectivas
• Nuevas ideas y Preguntas
• Backlog y User Stories
• Estimación y Planeación
• Informes de Experiencia
• Equipos de Alto Rendimiento
• El Cambio Duele
• Conflicto y Retroalimentación
• Siguientes pasos

Audiencia

Este taller está enfocado principalmente hacia las personas que están interesadas en convertirse en un ScrumMaster Certificado. También me gustaría recomendarlo a los Product Owners o miembros de equipo que pueden estar trabajando en los equipos de Scrum en el futuro. Funciones dentro de sus organizaciones actuales pueden incluir:

• Arquitectos
• Analistas
• Desarrollador
• Especialistas en documentación
• Ejecutivos
• Gerentes
• Project Managers
• Testers
• Miembros de Equipo

Duración

Dos días. Nota: Planee ir a los dos días tiempo completo (8:30-4:30 hora local).

¿Cómo inscribirse?

¡Inscríbase ahora!

Tomando esto como base, podemos entonces proceder a enumerar algunas de las habilidades que debe poseer un Gerente de Proyecto, a saber: Capacidad de Liderazgo, Habilidades de Comunicación, Habilidades para Resolver Problemas, Habilidades Interpersonales, Habilidades para Administrar el Tiempo y Capacidad para el manejo de Estrés.

Estas habilidades están enfocadas a la dirección de las personas y las relaciones entre ellas. Ahora bien, la manera en como se dirigen estos dos aspectos, es la clave para ser efectivos en la gerencia de un proyecto y el recurso humano implicado.

Recordemos que la forma en como hacemos las cosas depende de nuestro carácter, y este a su vez, está determinado por nuestros hábitos, los cuales pueden llegar a generar nuestra efectividad o inefectividad.

Pero, la efectividad está en función de dos cosas: lo que se produce (metas, objetivos) y los medios o bienes de producción para obtener el producto deseado. Así que, si se quiere ser efectivo siempre, se debe tener esto presente en todo momento, lo cual, si lo vemos desde otro punto de vista, significa que debemos tener hábitos que nos hagan actuar continuamente con esto en mente.

Por tanto, para ser un Gerente de Proyectos efectivo debemos tener hábitos basados en buenos principios, que nos lleven a una dirección efectiva de las personas y las relaciones entre ellas.

Entonces: ¿qué hábitos debe tener un Gerente de Proyecto Efectivo? ¿Cómo pueden estos hábitos contribuir al desarrollo las habilidades anteriormente citadas que debe tener un Gerente de Proyecto?

Es interesante analizar el modelo de dirección que propone Stephen Covey en su libro “Los 7 Hábitos de la Gente Altamente Efectiva”, puesto que si logramos desarrollar estos siete hábitos, entonces, de forma automática obtendremos las habilidades que un Gerente de Proyecto debe tener.

Pero veamos brevemente el modelo propuesto por Covey y cómo este nos puede ayudar a ser efectivos en la gerencia de proyectos.

Los 3 primero hábitos tienen que ver con el interior de la persona, con el dominio sobre uno mismo, estos son: 1- Proactivadad, 2- Comenzar con un fin en mente y 3- Establecer primero lo primero.

Los siguientes 3 hábitos tienen que ver con las relaciones interpersonales 4- Pensar en ganar/ganar, 5- Procurar primero comprender y luego ser comprendido y 6- Sinergizar.

El último hábito: “Afilar la sierra”, tiene que ver con el hecho de que debemos procurar una mejora continua en todo lo que hacemos, en revisar constantemente nuestras actitudes con el fin de determinar si estamos poniendo o no en práctica los 6 hábitos anteriores.

Capacidad de Liderazgo: el gerente de proyectos debe ser líder del equipo de trabajo que lo acompaña en la realización del proyecto, pero antes de querer ser líder de alguien más, uno debe ser primero líder de sí mismo. Es allí, en donde hábitos como el de la proactividad ayudan a ir en busca de ese liderazgo personal, al saber de que cada uno de nosotros es responsable de sus propias acciones y que tiene la libertad de elegir.

Por otra parte, el hábito dos, es el hábito del liderazgo personal, porque nos ayuda a definir hacia donde vamos, que es lo que queremos para nosotros mismos. Cuando tenemos muy claro que queremos para nuestras vidas, nos ayudará a clarificar mejor que es lo queremos lograr en cada uno de los proyectos que tengamos la oportunidad de gerenciar. No podemos ser líderes de otros si no somos primero nuestros propios líderes. Sin embargo, una vez que logremos ser líderes de nosotros mismos, el hábito de pensar en ganar/ganar nos ayudará a desarrollar excelentes habilidades en el liderazgo interpersonal.

El liderazgo interpersonal requiere visión (2do hábito de Covey), requiere proactivdad (1er hábito) y otras características del liderazgo personal basado en principios. Pero más importante aún, es que si logramos liderar bajo la filosofía de ganar/ganar vamos a crear relaciones duraderas, relaciones que valen la pena y que hará más fácil a las demás personas seguir a su líder de forma voluntaria, y con todas las ganas de hacer las cosas bien.

La capacidad de liderazgo en ocasiones requiere ser buenos en el arte de delegar, y el 3er hábito cuando nos enseña a establecer primero lo primero, nos enseña cual es la manera más efectiva de delegar tareas a otras personas.

Habilidades de comunicación: los gerentes de proyectos tienen que ser buenos comunicadores. El problema es que la mayoría de las personas no somos buenos comunicándonos, básicamente por que no sabemos escuchar. Cuando alguien nos dice algo nos precipitamos, buscamos arreglar las cosas de inmediato, sin embargo, es mucho mejor cuando escuchamos primero, de forma empática, así cuando ya sea necesario dar un consejo o tomar alguna acción determinada, tenemos todos los elementos suficientes para hacer una buena prescripción.

En ocasiones es necesario hacernos entender, es decir, necesitamos que otros nos comprendan, así que siguiendo lo que implica una buena comunicación podremos lograrlo.

Habilidades para resolver problemas: un buen Gerente de Proyectos debe ser un buen solucionador de problemas y para resolver problemas se necesita entre otras cosas mucha proactividad, se necesita ser un buen comunicador, lo que implica comprender primero y asegurarnos también de que somos comprendidos.

Hay situaciones en las que para resolver un problema se necesita la interacción de varias personas del equipo de trabajo, es allí donde el sexto hábito, el de sinergizar toma una trascendental importancia, y el Gerente de Proyecto debe aprender a generar una cooperación creativa entre los miembros de su equipo de trabajo, para la resolución de problemas y para todas las demás actividades del proyecto.

Habilidades interpersonales: es importante que el gerente de proyecto desarrolle una relación con cada persona del equipo de proyecto, debe conocerlos a fondo, sus cualidades, sus intereses, sus fortalezas y flaquezas. Las buenas habilidades interpersonales permiten establecer empatía con cada uno de los miembros del equipo y sin lugar a dudas, en este campo es de suma ayuda el hábito de ganar/ganar, el cual nos permite crear relaciones estables y duraderas. Es importante también la sinergia que se pueda alcanzar con cada uno de los miembros del equipo, con el fin de fortalecer cada vez más la relación interpersonal existente.

Habilidades para Administrar el Tiempo: un buen Gerente de Proyecto administra muy bien su tiempo y sin lugar a dudas el tercer hábito (Establezca primero lo primero) nos da una guía práctica y efectiva sobre la manera en como cada uno de nosotros debe administrar su tiempo, tomando como base sus principios y sus prioridades en la vida; dentro de las cuales, sin duda, estarán las prioridades del proyecto.

El séptimo hábito “Afilar la sierra”, es el hábito de la mejora continua, tanto en la puesta en práctica de los primeros 6 hábitos del modelo de Covey sobre la dirección de las relaciones interpersonales, como en otras dimensiones de la naturaleza humana.

Es importante notar que estos son hábitos, puede ser que tengamos algunos de ellos, otros quizás no, pero eso no quiere decir que no podamos llegar a convertirlos en nuestros hábitos.

Claro que no es fácil, como no es fácil adquirir el hábito de la lectura para quienes no lo tienen, o el hábito de una buena alimentación, pero con trabajo y esfuerzo se puede lograr. Eso es lo que representa el sétimo hábito, ayudarnos a que los primeros seis sean parte integral de nuestras acciones diarias. Solamente así lograremos ser Gerentes de Proyecto altamente Efectivos.

Por: Elmer Fonseca Umaña
Análisis sobre cómo aplicar la obra de Stephen R. Covey a la Adminstración de Proyectos