Mi querida estrella de mar Scrum

La estrella de mar Scrum es una metáfora muy poderosa que utilizo en muchas empresas para mostrar aquellas características que debe contar un equipo y organización para emplear Scrum con éxito.

La estrella puede ser utilizada por un lado para dejar en evidencia aquellas áreas requeridas o carencias, y por el otro, para ayudar a las personas a identificar disfuncionalidades invisibles.

La idea de la estrella no es apuntar a departamentos o personas específicas que estén bloqueando el avance de Scrum, sino que aportar una herramienta que facilite el establecer una conversación entre las partes sobre la dirección a tomar para emplear Scrum con éxito.

estrella de mar

Basado en mi experiencia, recomiendo dibujar de tamaño grande y presentar poco a poco la misma a un grupo de personas variado (IT, negocio, etc.) y consultar frecuentemente sus opiniones sobre que tan cerca o lejos la organización se encuentra del estado propuesto y porqué.

Debido a que normalmente todos los miembros tienden a contar una visión parcial del funcionamiento de la compañía, es frecuente que al introducir los primeros puntos los participantes se pongan de acuerdo que la empresa ya cuenta con dichos valores.

Es posteriormente cuando las personas comienzan a conectar y una discusión se establece, que  la visión compartida finalmente emana, lo que hace posible detectar las disfuncionalidades y alinear las partes, proponiendo un modelo más cercano a la realidad.

La estrella es también de mucha utilidad para exhibir que es lo que se entiende por Scrum y aquellos valores o prácticas que se consideran inaceptables si se desea entregar valor de negocio de forma frecuente,  estable y bajo intervalos regulares. Utilízala y verás los resultados.

Gracias por escucharme,

Erich.

¿Qué opciones tienes para implementar un marco de trabajo Ágil en tu empresa?

¿Quieres implementar un marco de trabajo Ágil y estás pensando en cómo hacerlo?

Sin dudas que será un desafío para ti y tu organización. Ágil y sus marcos de trabajo son conceptos fáciles de comprender pero de difícil implementacion. En realidad, aparte de la dificultad, hay dos alternativas para que puedas llevarlo adelante:

  1. Orgánico
  2. Salido de la caja (o “out-of-the-box)

La forma orgánica
La primera opción consiste básicamente en comenzar poco a poco con las diferentes prácticas (ej. hacer Scrum) esto es (imagínate que eliges Scrum), empezar con las retrospectivas y poco a poco al paso del tiempo, ir adicionando nuevos elementos. El proceso se hace de forma gradual hasta que la totalidad de las piezas hayan sido ensambladas y conectadas.

Desde el punto del modelo de cambio, parecería ser que ello brinda la posibilidad de que las personas puedan irse adecuando al marco de trabajo lentamente y les brinde cierto tiempo para ajustarse e incremente el confort, así como también la confianza de las personas en el éxito. Por el otro lado, si tienes una cantidad limitada de mentores/coaches ágiles, ello podría simplificar el trabajo para estos últimos ya que se podría pensar en estructurar llas prácticas o valores que se instruirán y en que tiempo. Ten en cuenta que aquí -en general- no se genera cadencia, motivo necesario para cambiar una organización.

Saludo de la caja (out-of-the-box)
La segunda opción consiste en sacar el producto de la lata (por ejemplo) de forma prescriptiva (Scrum) e implementar este en su totalidad, esto es, sin remover nada. Desde el comienzo se realizan retrospectivas, se emplean ciclos Sprint y todo aquello que forme parte del marco de trabajo. Esto último puede parecer de mucho impacto para cualquier empresa, lo que evidentemente aumenta el riesgo y conflicto. Pero… ¿Es esto así?

A mi criterio, el escenario orgánico es una trampa ya que brinda cierta seguridad al comienzo ya que los individuos creen que las cosas podrán ser realizadas de forma gradual, pero esconde un problema mayor que es el hecho de que se tengan que mantener los hábitos anteriores, lo que disminuye o anula la mejora continua y hace que se puedan tener conflictos por un largo período de tiempo entre las partes nuevas y anteriores.

¿Cómo solucionas que en la trasición orgánica haya un valor de la compañía que indique que se deberá trabajar en tantas cosas como sea posible  (multitarea) y otro que indique que se deberá mantener el foco?

Este tipo de coyunturas hace que el marco de trabajo se vuelva inestable, se generen comportamientos erráticos que no apoyen el crecimiento positivo y de mejora continua y que se creen nuevos estados que difieran en mucho de lo que se trata de conseguir con cualquier de los marcos de trabajo ágiles a nivel de equipo, flexibilidad y empresa. Esta variabilidad crea escenarios complejos, que aumentan la complejidad de la organización y dan como resultado situaciones inéditas.

Es así que en vez de disminuir el riesgo lo aumenta, creando estructuras inéditas, dando mayor trabajo a las personas, generando más desperdicio y ocupando los mentores ágiles por más tiempo en el aumento de disfuncionalidades de la compañía.

Si se quiere implementar una marco ágil, mi recomendación es que utilices entonces la opción de la lata mediante un trabajo previo de fondo:

1. Analiza la situación
2. Obtén el apoyo de aquellas personas con influencia política en la empresa
3. Busca a las personas clave
4. Analiza brevemente el tipo de proyecto (lee abajo)
5. Establece un equipo y comienza.

Una cosa más a tener en cuenta es que el proyecto que elijas no sea de un alto riesgo a nivel de implementación, como por ejemplo, desconocimiento de la tecnología o la solución, alta rotación de personas, dificultad con etapas, etc. Siempre selecciona un producto a desarrollar que le aporte valor a la empresa y que no haya riesgos técnicos. Algo que puedes hacer es buscar un proyecto que no ofrezca problemas si eligieses metodologías tradicionales.

Puedes también emplear un proyecto “spike” (proyecto prueba) siempre y cuando el objetivo del mismo sea exclusivamente probar el marco de trabajo. Recuerda, remueve aquellos factores conocidos que puedan producir mucha inestabilidad sobre el aprendizaje.

Ágil no es para ir más rápido sino que para entregar mayor valor al cliente (detectar lo que el cliente realmente quier). La primera es solamente una consecuencia de la segunda.

Finalmente, trata de obtener métricas sencillas (para comparar con otros proyectos o incrementar las oportunidades de aprendizaje) Y que pueda fácilmente informar sobre los resultados cuando te lo pregunten

Uno de los escenarios donde podría funcionar el modelo orgánico es cuando tienes que refinar por ejemplo un rol dentro de la empresa, donde en vez de cambiarlo de un día para el otro, deseas realizar pequeños experimentos.

También el modelo orgánico es de utilidad si los cambios son a través de toda la organización como ser Business Agile.

Gracias por escucharme,

Erich.

7 organismos internacionales donde obtener tu certificación Agile/Scrum

¿Deseas saber dónde obtener una certificación Ágil/Scrum? Esto es una pregunta común entre las comunidades que suele llevar a mucha confusión a los profesionales.

Son 7 las principales opciones del mercado y cada una de estas ofrecen puntos de vista con matices diferentes pero cierta convergencia. A su vez, algunos se centran en nichos de mercado mientras que otros intentan abarcar un segmento global.

1. Scrum Alliance

Uno de los sitios más antiguos y respetados que brinda varias certificaciones, aunque en los mercados hispanoparlantes la más conocida es la de Scrum Master.

– Scrum Master Certificado (CSM)
– Propietario de producto (CPO)
– Desarrollador Scrum (CSD)

A su vez, se ofrecen tres certificaciones para aquellos que requieran especializarse en Scrum y Agile:

– Profesional certificado (CSD)
– Coach de equipo Scrum (CSC)
– Coach Empresarial Scrum (CEC)

Para obtener tu certificación de Scrum Master deberás realizar un curso con un profesor certificado por Scrum Alliance (Certified Scrum Trainer) y luego hacer un examen desde tu casa. Este último es realmente sencillo aunque el hecho que sea de casa preocupa debido a que degradar el valor de la certificación. No obstante, finalmente los buenos profesionales se ven en la «cancha».

Otro punto a considerar es que los profesores certificados tienen bastante flexibilidad sobre como abordar los diferentes temas, por lo que dos personas certificadas con instructores distintos podrían tener puntos de vista dispares.
El examen de profesional de Scrum (CSP), a diferencia, es relativamente complejo y debe rendirse en un centro certificado, lo cual brinda mayor valor a quien lo obtiene y es comparable al examen de Practicante Ágil de PMP.
Scrum Alliance es uno de los organismos mas serios y con mayor reputación en el mercado y quien reúne el mayor número de miembros con certificaciones Ágil. A su vez, ha tratado de estandarizar los términos y procesos de Scrum en un libro de referencia disponible en AgileAtlas.org.

2. Organización Scrum (Scrum.org)

Ken Schwaber es uno de los fundadores de Scrum Alliance que luego decidió apartarse y seguir su camino, aunque hoy en día han realizado varias iniciativas juntos luego de muchos años de ausencia. Varios de sus exámenes están abiertos al público sin necesidad de tomar sus cursos y ofrecen un nivel de dificultad alto.
– Scrum Master profesional 1 y 2 (PSM I, PSM II)
– Propietario de producto profesional 1 y 2(PSPO I, PSPO II)
– Desarrollador profesional 1 (PSD I)

La organización a su vez exige a los instructores usar el mismo material, lo que ofrece mucha consistencia entre dos personas que atiendan a cursos dictados por instructores distintos. Por el otro lado, algunos argumentan que esto puede hacer que se pierda flexibilidad y se requiera un proceso más formal para incluir nuevos temas.

Cabe destacar que su curso de Desarrollador profesional está excelentemente implementado y es un candidato decisivo para aquellos que busquen tener conocimientos sólidos de técnicas Ágil aplicadas en equipos de desarrollo Scrum.

3. PMI-ACP (pmi.org)

El conocido Instituto de gestión de proyectos, el cual finalmente además de su clásico programa de cursos y certificaciones relacionadas a metodologías tradicionales, comenzó a ofrecer la certificación de Practicante Ágil luego de llevar adelante un período de prueba durante 2011.
Ellos cuentan con una comunidad de práctica de Ágil y recomiendan decenas de libros para la preparación del examen (muchos de los cuales son los mismos que sugiere ScrumAlliance) y también hay ediciones específicas que se centran en la preparación del examen. El nivel y preguntas son comparables al de Profesional Certificado de Scrum Alliance (CSP).
Si bien ha sido un jugador bastante tardío en la adopción de Ágil, cuenta con el apoyo de una gran comunidad.

4. NetObjectives

Esta compañía surgió de Al Shalloway, quien tiene un punto de vista pragmático sobre Scrum, Lean y Ágil. Una de las cosas que me gusta sobre AL (y que compartimos plenamente) es la creencia que el pensamiento sistémico es el corazón  de Ágil y Scrum.
Ellos ofrecen certificación de Scrum Master, Propietario del producto (Product Owner) y varios cursos sobre Lean y Ágil y  SAFe.
A diferencia con las instituciones anteriores, también brindan los exámenes de SAFe (Scaled Agile Framework), lo cual es un marco de trabajo de escalamiento de Scrum orientado a compañías de gran porte.
Excelente opción de certificación para aquellas empresas con cientos de empleados, no obstante, sigo pensando que SAFe promueve seguir ciegamente un conjunto de prácticas pero no brinda un cambio real de mentalidad hacia Ágil.
Netobjectives está recoendado para toda empresa que quiera alinear equipos con Lean y SAFe.

5. ICAgile

Están especializados en ofrecer material consistente y principalmente de calidad para universidades y organizaciones. Tienen 3 niveles de certificación, las que evalúan el conocimiento adquirido, pero también la experiencia del participante. Cuentan con un modelo que apoya a Universidades y empresas que deseen albergar cursos estándares sobre todos los aspectos de Ágil (no solamente Scrum).
Es una excelente opción para Facultades u otras organizaciones similares que requieran enseñar los distintos tópicos de forma unificada.

6. Academia de Ágil distribuido, SAFe (scaledagileacademy.com)

Ofrece certificaciones para empresas de gran porte mediante una versión de Scrum adaptada para que pueda ser utilizada en empresas más tradicionales con un alto número de equipos. A grandes rasgos, el marco de trabajo consiste en sincronizar diferentes pilas de producto a varios niveles y la aparición de nuevos roles, así como la extensión de los roles clásicos.
El modelo ofrece consistencia para las compañías que empleen actualmente metodologías tradicionales y desean moverse hacia Scrum, pero no es un buen candidato si se quiere promover un cambio de mentalidad.
La academia es el resultado del trabajo de Dean Leffingwell, quien publicó hace ya algún tiempo el libro de Scrum distribuido y ha ido creciendo hasta adoptarse como el marco unificado SAFe. En su libro, Dean, ofrece varias técnicas que pueden ser incluso empleadas en compañías más tradicionales sin cambio total de la cultura.

– Consultor SAFe (SAFe program Consultant)
– Agilista (SAFe program Agilist)
– Practitioner (SAFe program Practitioner)

7. Probador (tester) certificado Ágil (Instituto internacional de calidad de software, agile-tester.org)

El Instituto de análisis de negocio (iiba.org) en colaboración con la Alianza Ágil, ha editado a su vez una extensión de su libro de material de referencia donde se incluyen siete lineamientos para la práctica de análisis de negocio en entornos Ágil.
Vale la pena destacar también el trabajo de la organización Alianza Ágil, un organismo que no ofrece certificaciones pero brinda una gran comunidad para aquellos que deseen explorar diferentes aspectos de esta forma particular de pensamiento.

Es una organización de origen alemán que cuenta con un curso de 5 días centrado en la especialización para «testers» en un entorno Ágil.
Ellos creen que el conocimiento no puede ser simplemente enseñado pero que tiene que ser demostrado con práctica. Es por ello que el curso ocupa plenamente 5 días donde se evalúan no solamente las herramientas, sino que también las interacciones entre las personas. Al momento, cuenta con alrededor de 3000 personas certificadas, lo cual es un número bajo comparado con otras organizaciones, pero una excelente opción si se piensa que ataca un nicho específico de mercado.

Ten en cuenta que las certificaciones pueden cambiar cada varios meses, por lo que visita la página de la organización para tener la última versión de las certificaciones.

Ya puedes ahora sugerir a tu empresa el tipo de certificación adecuada basada en las características de tu compañía y las personas que la componen.
Si necesitas conocer más sobre como Innova1st puede potenciar equipos Scrum, visita nuestro sitio Web.

Gracias por escucharme,
Erich.

 

12 reglas sistémicas sencillas para líderes Ágil

Hace varios años atrás, Louise Diamond (una especialista en iniciativas globales para la paz), publicó 12 reglas para la resolución de conflictos mundiales y su encauce hacia la erradicación de las guerras. Pero… ¿Qué tiene que ver esto con Ágil?
En las entradas anteriores conocimos como el pensamiento sistémico es una parte fundamental del funcionamiento y núcleo para llevar adelante Ágil (parte 1 y parte 2). Vimos allí que las diferentes áreas de complejidad y la interconexión entre elementos, así como las propiedades emergentes de los sistemas complejos ayudan a entender características tales la de auto-organización.

Es entonces claro que en todos los sistemas humanos existen varios niveles de organización y que estos exhiben dinámicas comunes a los sistemas vivos: estos danzan entre un proceso de caos y su posterior re-adaptación y pacificación, repitiéndose nuevamente el ciclo en forma indefinida.

Una de las formas en las que distingo un equipo Ágil de alto rendimiento es apreciando su constante ciclo que varía entre el caos, la destrucción y nueva estabilización. Cuando algo se resuelve, aparece un nuevo elemento que producirá cierto caos, lo que sugerirá una modificación radical de su estructura y forma de trabajo, la que se estabilizará posteriormente generando una paz temporal. Esto es algo que un Scrum Master conoce perfectamente y proceso que vive como parte de su role.
Cada día un equipo Ágil afronta desafíos increíblemente complejos e interconectados, los que emanan de problemas técnicos, carencias en la organización o formas de trabajo y limitaciones personales. Es por ello que entender la naturaleza de las dinámicas de los sistemas complejos puede dar a luz una nueva forma de pensamiento y modificar la vía que resolvemos los problemas, nuestras asumpciones o las decisiones que tomamos como mentor Ágil, miembro de un equipo Scrum,  gerente de una empresa de software o cualquier otro role en la compañía

Veamos una adaptación de los 12 conceptos sencillos inicialmente creados por Diamond pero ahora adaptados a equipos Ágiles:

1. Conecta lo desconectado
En sistemas complejos, todos los elementos o agentes están interconectados, como en una red gigante.  Ellos son también interdependientes, lo que le sucede a uno afecta a todos los demás. Por lo tanto: Conecta lo desconectado.
Es necesario que todos los elementos de la empresa comiencen a ver la implicación de esto último y potencien el compartir conocimiento entre todos los departamentos de la compañía como tarea del día a día. Scrum o cualquier otra forma de trabajo Ágil debería no ser una isla dentro de la empresa sino una forma de pensamiento. Busca los elementos donde la Densidad Social es Baja y trabaja en aumentarla.

2. Conéctate a tierra con la imprevisibilidad
La complejidad es la naturaleza y el estado de los sistemas vivos y el mundo en que vivimos. Lo que sabemos sobre los sistemas complejos es que hay múltiples agentes o elementos, combinándose e interactuando de maneras impredecibles y no lineales. Ello indica que las decisiones a menudo conducen a consecuencias no deseadas. Por lo tanto: Conéctate a tierra con la imprevisibilidad.
Tener un plan a largo plazo puede ser eficaz solamente si se toma como un mapa de intención para mantener a las personas alineadas, pero éste debe asumirse como un elemento orgánico y no fijo y ello ser comunicado con transparencia a todos los miembros de la organización. Por su naturaleza orgánica, invertir tiempo y dinero en planes fijos a largo plazo es ineficaz y podrá sumergir la compañía en el síndrome de análisis parálisis. Crea mapas de intención pero no mapas de ruta (roadmap), a no ser que sean de muy alto nivel.

3. Crea las condiciones para los vínculos de calidad
En la red enorme de interconexiones, los puntos o nodos en donde los agentes se reúnen son las relaciones u oportunidades para la interacción. Estas interacciones determinan lo que va a pasar con el sistema. La naturaleza y la calidad de estas relaciones, por lo tanto, son de importancia crítica. Por lo tanto: Crea las condiciones para que los vínculos sean de calidad.
Debes propiciar el entorno adecuado para que las personas establezcan vínculos de calidad y duraderos. Podrías emplear los valores de Scrum como un buen comienzo y los postulados Ágiles. Por ejemplo, los individuos que tengan más carga del trabajo que pueden realizar y efectúen constante multitarea, así como los entornos físicos que no apoyen a los individuos no crearán condiciones para la calidad de los vínculos. Propicia también la negociación y discusión global de los temas con consenso general.
En una escala de 1 a 5 (menor a mayor) ¿Cuál crees que es el valor de la calidad interacciones en tu empresa? ¿Tienen todos la misma perspectiva sobre éste valor? ¿Cómo podrías mejorarlo?

4. Re-equilibra los flujos a través de las fronteras
Sabemos que todos los sistemas intercambian energía, la materia y la información a través sus límites. Cuando somos capaces de identificar los desequilibrios en los flujos – atascos, sobre o sub-acumulación, etc – podemos cambiar las cosas para que sea más equitativo y sostenible. Por lo tanto: Re-equilibra los flujos a través de las fronteras. Trabaja en reducir las colas cada día sin bajar la calidad, analiza los vínculos más débiles  y refuérzalos. Aplicar la teoría de colas es entonces indispensable, y tener facilitadores efectivos es la clave.

5. Modifica el patrón para la sostenibilidad y el bienestar del conjunto
Todos los sistemas vivos desarrollan patrones. A menudo, estos patrones se auto-refuerzan y se arraigan profundamente y parecen difíciles de cambiar. Muchos de ellos son comunes y reconocibles en sistemas humanos. Los patrones también aparecen en formas similares a distintos niveles de la organización. Por lo tanto: Modifica el patrón para la sostenibilidad y el bienestar del conjunto antes de pensar en modificar el role de facilitador que parece el problema. Analiza los patrones y planifica un cambio estructurado. Puedes leer más sobre planificar un cambio y resistencia institucional en mis artículos parte 1 y parte 2.

6. Presta atención a las partes más pequeñas y a las partes grandes
Sabemos por los sistemas vivos que todo es un todo en sí mismo y, al mismo tiempo, parte de un todo más grande. Por lo tanto: Presta atención a las partes más pequeñas y a las partes grandes. Resolver los problemas personales de un conjunto de empleados puede aceitar la eficiencia de los equipos, lo que a su vez, apoyará nuevas formas de trabajo y ayudará a consolidar la visión global de la empresa. En cada nivel hay características únicas y también temas y patrones. Ser capaz de moverse hacia atrás y adelante entre ellos, de la misma forma que funciona un lente telescópico, nos da más información para encontrar mejores soluciones. Utiliza mapas visibles y radiadores visuales para dejar implícitas las partes y sus relaciones y trabaja en mejorarlas.

7. Presta atención a las redes emergentes
Los sistemas vivos se organizan a través de las interacciones de sus agentes o partes. La organización se lleva adelante mediante redes– es decir, grupos de partes unidas y juntas de una manera descentralizada por un período de tiempo. Por lo tanto: Presta atención a las redes emergentes y su auto-organización (ej. quipos Scrum y sus dinámicas cambiantes).
Sin la comprensión de cómo funcionan las redes, no puedes esperar el abordar eficazmente estas situaciones. Existen nuevas redes emergentes o grupos/modas en tu empresa a las que deberás prestar atención y apoyar o desestimular. Ellas podrán aportar nuevas tendencias, ideas o caminos que deberán ser incentivados. Emplea la curiosidad y fomenta el saber porque están allí antes de tomar una decisión. Existe una dinámica que he utilizado por años que consiste en evaluar los distintos tipos de señales que obtienen las personas de la organización (consistentes, inconsistentes, a amplificar o desestimular), mapéalos con las redes emergentes con post-it y discútelo con las personas involucradas.

8. Busca coherencia dentro del caos
Los sistemas se mueven entre diferentes grados de estabilidad e inestabilidad, esto es, orden y el desorden. Cuando el desorden o caos se vuelven demasiado grandes, las cosas se desmoronan. Cuando el orden es demasiado rígido, las cosas no pueden crecer o desarrollarse. Sin embargo, un cierto grado de inestabilidad o estar al borde del  caos puede propiciar poderosos momentos de cambios creativos. Por lo tanto: Busca coherencia dentro del caos.
Los equipos de Scrum de alto rendimiento necesitan alternar entre estos estados para obtener el máximo potencial. Esto es normal y esperado pero debes prestar principal atención a disminuir la variabilidad. Pon reglas muy simples y claras, y ayuda a las personas a que sean muy disciplinados pero que se deje margen para la mejora y entropía.

9. Mira a lo intangible, así como lo concreto para ver su potencial
Todos los sistemas vivos existen como un campo de potencial único y unificado;  el observador es un integrante de la situación, el pensamiento sus consecuencias y las soluciones creativas su punto de surgimiento. Por lo tanto: Mira a lo intangible, así como lo concreto para ver su potencial.
El asignar un integrante a un equipo que, por ejemplo fué su jefe o líder técnico cuando se empleaban formas de trabajo  tradicionales, puede traer consecuencias tangibles a un equipo debido a situaciones anteriores no tangibles. Ello derivará seguramente en la destrucción de la auto-organización del mismo y deterioro de su moral.
Las decisiones deben tomarse con una visión global y crítica de las políticas de la empresa, acciones y su repercusión. Analizar ellas con los involucrados y emplear el consenso incrementa el potencial de suceso. Si tienes equipos Scrum que son de un proveedor externo, rota los líderes de equipos a otro grupo donde no hayan tenido ese cargo anteriormente.

10. Articula, comunica y valida las historias que te dices a ti mismo con el resto de integrantes de la organización
Los sistemas existen dentro de su propio contexto único. Para los sistemas humanos, este contexto es un relato interno que da sentido a nuestras decisiones y acciones. Por lo tanto: Articula, comunica y valida las historias que te dices a ti mismo con el resto de integrantes de la organización.
Las ideas que nos guían a tomar decisiones son las historias que nos repetimos a nosotros mismos una y otra vez y que consideramos verdaderas o falsas (independientemente de si han demostrado ser ciertas o no en la práctica). Las condiciones cambian y las viejas suposiciones ya no son válidas, aunque muchas veces, sigamos pensando lo mismo. Valida entonces tus suposiciones con el resto o con pequeñas hipótesis, considera el pedir ayuda como un valor fuerte y no débil de la empresa y presta principal atención a modificar asumpciones personales en base a la información provista por el resto de integrantes de la organización. Fomenta la cultura de pedir ayuda y aceptar el cambio como una conducta positiva. Si exiges mejora continua a los equipos o resto de la organización, haz tu también mejora continua. Da el ejemplo.

11. Define y revisa los objetivos y propósito
Las partes de un sistemas se cohesionan en torno a un objetivo común y compartido. Por lo tanto: Define y revisa los objetivos y propósito.
En Scrum empleamos un objetivo claro y conciso y nos aseguramos que todos los miembros de la empresa lo conozcan. Aquí, cada ciclo Sprint tiene una meta específica que se alinea con el objetivo del producto y la visión de la empresa. A su vez, el Propietario del producto (Product Owner) debe ofrecer un 70% de las historias de Usuario de un Sprint que apoyen la meta y visión de la compañía, así como el Sponsor debe tener un objetivo y visión que apoye la iniciativa, y el  CEO lo suyo para la organización.

12. Aprende y cambia en base a los mensajes internos y externos
Los sistemas vivos son sistemas de aprendizaje. Esto quiere decir que se adaptan a partir de la retroalimentación que reciben de sus ambientes internos y externos. Por lo tanto: Aprende y cambia en base a los mensajes internos y externos, pero asegúrate antes de dominar lo que haces antes de apresuradamente cambiar.
En Scrum y otros marcos de trabajo Ágil, la utilización de retrospectivas hace que los equipos puedan ofrecer 2 niveles de retroalimentación, uno hacia el propio grupo y otro hacia la empresa. Esto no es excluyente y se debe fomentar el aprendizaje y mejora continua en todos los procesos, así como la retro-alimentación honesta desde/hacia todos los miembros de la compañía sin importar su cargo. Una buena técnica para fomentarlo ello es que los miembros de los equipos brinden retroalimentación activa y sin miedos al CEO u otros cargos que se consideren superiores en la empresa.

Gracias por escucharme,
Erich.

10 consejos para la empresa en tiempos de crísis

1. Invierte dinero solamente en los proyectos que te permitan generar ganancias en el corto plazo.

2. La mejor solución a un problema es la que cuesta menos hacerla, incluso si cuesta más en el largo plazo.

3. Mantén controlada la deuda técnica en cualquier decisión que tomes y trabaja constámente en reducirla.

4. Las opciones que resuelven un problema rápido tendrán preferencia a aquellas opciones que ofrezcan soluciones superiores a largo plazo (tener en cuenta el punto 3).

5. Mantén la excelencia de calidad en tus productos y trátala como un elemento no negociable.

6. Reutilizar o reciclar conocimientos o materiales es mejor que adquirir algo nuevo.

7. Fomenta activamente las conexiones entre personas y motivación en los equipos y brinda el entorno adecuado para aumentar la creatividad. Incluso si no hay dinero, se pueden siempre encontrar opciones creativas que no cuesten a la empresa.

8. Ofrece liderazgo con transparencia total y expone la totalidad de las opciones claramente a todos los niveles de la empresa para brindar una meta concisa. Utilizar pensamiento sistémico es una buena opción para analizar la repercusión de cada meta.

9. Reduce la cantidad de informes que no producen valor y quédate solamente con aquellos que apoyan la toma de decisiones y son comprendidos por la totalidad de la empresa.

10. Analiza el flujo de trabajo y centra a cada individuo de la empresa a que ayude a elimina el desperdicio (todo aquello que no produce valor a tu cliente) y reducir las colas.

Prueba los 10 puntos, mejóralos, y vuelve al punto 1.

Gracias por escucharme,
Erich.

Lo que olvidaron enseñarte: pensamiento sistémico (II)

En la parte anterior te expliqué de forma práctica el pensamiento sistémico y su relación con las metodologías tradicionales, ahora quiero ahondar más y ver patrones no tan obvios, así como también su relación con Agile y Scrum.

Pensamiento sistémico y Scrum/Agile
Comencemos viendo el primer enunciado del manifiesto Ágil, el que imagino habrás escuchado en reiteradas ocasiones y artículos:

«Individuos e interacciones sobre procesos y herramientas»

La visión que tiene un practicante principiante de Agile es que debe poner a las personas sobre los procesos. Esto aunque es correcto, es tan solo una pequeña parte del iceberg. Practicantes más avanzados suelen tener una visión más amplia y complementaria.

Propiedades emergentes y conexiones
Como indiqué anteriormente, el sistema de pensamiento sistémico y modelos complejos elige una aproximación que radica en que se deberá entender al sistema en su totalidad comenzando por las personas y sus interacciones (conexiones), para así poder predecir su comportamiento.

«Una vez que vemos la relación entre estructura y comportamiento, podemos comenzar a entender como funciona el sistema, que le hace producir resultados pobres y como modificarlo para obtener un mejores patrones de comportamiento.» Donella Meadows

Si se desea influenciar o modificar una caraterística del sistema, se tendrá que atender a la totalidad del mismo en vez de un elemento en particular (el equipo como tal en vez de las personas en particular). Para ello existen dos reglas adicionales que derivan del pensamiento sistémico:

1. Dividir un sistema en partes para analizarlo destruye al sistema que se está tratando de entender. Esto va de acuerdo con la idea de que todo está interconectado y que si se destruye la conexión se modifica o elimina el sistema. Querer analizar el comportamiento de un perro cortándolo en 2 partes destruirá toda posibilidad de análisis.

2. Los sistemas muestran características que no son propiedades de ninguna de las partes que lo constituyen. Por ejemplo, auto-organización es una propiedad que no está asociado con la persona como entidad única.

Imagínate que te vas de vacaciones con 3 amig@s y deciden alquilar una bicicleta. Pese a diferencias de peso, fuerzas actuando en diferentes direcciones (entre las cuales se encuentra el rozamiento y el viento), engranajes y otros factores, se pondrán casi automáticamente de acuerdo y la bicicleta comenzará a rodar.

bycicle1

Este sistema muestra una capacidad que no corresponde con ninguna de las 3 personas, lo cual es una propiedad emergente: la auto-organización (aunque existen más propiedades emergentes en el ejemplo ¿Las puedes ver?).
Ahora comienzan los 3 a dar pedal y encuentran que todas las fuerzas se ajustan hasta lograr un balance. He aquí una propiedad emergente exclusiva de los sistemas auto-organizados: ¡el equilibrio!
Mas adelante como la carretera no está en el buen estado que creías inicialmente, se topan con el primer bache. Aquí pueden ocurrir 2 situaciones, pero omitamos por ahora el caso donde los 3 terminan en el suelo :-).
Lo que pasaría es que de manera conjunta, estabilizarán las distintas fuerzas (incluyendo la velocidad) hasta encontrar nuevamente un equilibrio.
Eso que parece trivial se da como resultado de la auto-organización. Organismos no conectados no podrían alcanzar este estado.
Es por ello que existe una característica que emana de los organismos auto-organizados que hace que los mismos puedan realizar los ajustes (autocorrección) necesaria para volver a un balance.

«Los organismos auto-organizados buscan pueden auto-corregirse luego de un cambio en el sistema «

Para el caso que el bache sea muy grande, entonces se podría terminar en el suelo, lo que es a su vez otro estado de equilibrio.
Piensa ahora esta situación con los equipos de Scrum. Eres un mentor y el equipo encuentra un problema, ¿Deberías resolverles el problema por ellos o presentarlo ante el grupo para que su auto-organización pueda actuar, realizar los ajustes y encontrar nuevamente un estado de equilibrio?

«Instruir al equipo de como ser auto-organizado», Oferta de trabajo en Infojobs.net

Esta última frase corresponde a la descripción de una oferta de trabajo de Scrum Master ofrecida en Infojobs esta semana. ¿Crees ahora que es posible que alguien instruya a un equipo sobre como ser auto-organizado?

Hay entonces 5 preguntas que te pueden guiar hacia el pensamiento del modelo sistémico:

1. ¿Qué estímulo obtiene que resultado?
2. ¿Afecta el resultado consistentemente cada vez que se emplea el mismo estimulo?
3. ¿Qué variables hay y cual es su relación?
4. ¿Los efectos son inmediatos hoy hay un retraso?
5. ¿Cuales son las variables emergentes y su connotación local y global?

Los sistemas de pensamiento evitan caer en la trampa de partir el sistema para su análisis y aceptan que ellos deberán ser evaluados en su totalidad como un todo (veremos luego como bajar de nivel sin perder la perspectiva global). Ello preserva todas las conexiones en el sistema y permite que surjan las viariables emergentes.

Hay que entender que todo se baso en el concepto de relaciones que tienen una causa y un efecto y que los modelos resultantes pueden ser muy complejos. Ello es lo opuesto a la creencia o el forzar un circuito cerrado donde todos los resultados pueden ser planeados por adelantado y predecibles.

El pensamiento sistémico asume que existen relaciones entre los eventos en el sistema que pueden ser medianamente conocidas y debido a ello, predecir el comportamiento global del sistema. La idea fundamental es que si llevamos adelante un conjunto de procedimientos, entonces podremos saber con más exactitud sobre los efectos.

Esta aproximación no es nada nueva, ya Aristóteles hace 2400 años nos decía:

«Todo aquello que conste de un conjunto de partes, y que no solamente sea la suma de sus partes como una pila de elementos no relacionados, existirá como un todo más allá de sus partes e invariablemente tendrá una causa»

Agile ofrece el enunciado visto anteriormente el cual puede ser malinterpretado por un practicante novato. Un practicante de Agile más avanzado verá una implicación más profunda donde conocerá la diferencia entre ser Ágil y practicar Ágil. Esto último implica que el marco de trabajo no puede funcionar correctamente en el largo plazo si no se tiene un pensamiento Ágil.
Muchos equipos y empresas intentan utilizar Scrum aplicando tan solo sus prácticas, infravalorando el pensamento sistémico o de causa-efecto, lo cual da equipos disfuncionales y fracaso en el corto plazo.

«Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.», principio Ágil

Por otro lado, el modelo de pensamiento sistémico implica que la gran parte de las cosas a controlar hace de forma indirecta. Un ejemplo claro de ello es la auto-organización de los equipos Scrum ¿Funcionaría la auto-organización en un equipo porque existe una órden de la compañía que indica que hay que trabajar de esta forma? o ¿Habría que presioanar otros «interruptores» para obtener este resultado?
Estos otros interruptores podrían ser: la motivación, el entorno adecuado, confiar en ellos, brindar un entorno adecuado, etc.

«Respuesta ante el cambio sobre seguir un plan», postulado Ágil

La única forma de enfrentar en un modelo sistémico a un nuevo elemento que desestabilice al sistema (o caos) es mediante una respuesta a los cambios que consiga un nuevo equilibrio.

«Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.», principio Ágil

Como Ágil se basa en un modelo sistémico, apoya la  característica emergente de los elementos auto-organizados  que consiste en buscar constantemente a un estado sostenible.

Debes tener en cuenta que en un sistema de muchas partes inter-relacionadas, la simple explicación de causa y efecto no es suficiente. La naturaleza sistémica de las influencias y otros factores que contribuyen, tales como contextos dentro de otros contextos, adicionan complejidad adicional a la visión general.

Lo que si es claro es que no se pueden pensar más como flujos lineales o gráficos con flechas de unos a otros, ahora tenemos que considerar varios bucles y las dinámicas ocurriendo en las distintas partes del sistema como un elemento vivo.
Esto se logra viendo a los procesos como movimientos cíclicos (grandes bucles) y dinámicos moviéndose e influenciando el uno al otro.
Para ello el pensamiento sistémico ofrece los llamados modelos causales, los que permiten plasmar mediante formas especiales de bucles las dependencias entre los elementos, así como también su comportamiento. Una vez realizado el esquema global, se puede alimentar el mismo con valores y ver su resultado.

Sistemico

En el modelo sistémico el comportamiento de un sistema emerge de la estructura de sus bucles de retro-alimentación. La raíz de las causas no son nodos individuales (como en el modelo orientado a eventos). Ellas son el resultado de las fuerzas que emergen de de un bucle particular.

Esto se puede efectuar con lápiz y papel y el aprendizaje de la creación de los bucles causales no lleva más que un par de días y sentido común, tiempo y esfuerzo. Los modelos causales pueden servir también como forma de alinear a un grupo y buscar puntos de conexión entre las personas.
Una cosa que suelo hacer con los equipos de desarrollo es mostrar mi modelo causal de una situación y pedirle a los integrantes que dibujen el suyo. De esa forma podemos conocer los diferentes puntos de vista de un problema y buscar una solución basada en la fusión de los distintos dibujos.
El siguiente articula el efecto del estrés en un equipo de desarrollo. La letra «S» indica que si el elemento al inicio incrementa(+), el que está en la punta también(++). «O» por su parte indica que si el elemento del principio se incrementa(+), el de la punta bajará(+-). Para el caso que el del comienzo baje, entonces se deberá invertir el signo del final para hacer su evaluación (-+).

diagramaMental

Corresponde a mi diagrama mental (¡que puedes no estar de acuerdo!) que indica que si las estimaciones son más precisas (+),  bajará los costes del cliente, a su vez la confianza del equipo aumentará, lo que disminuirá los conflictos y la presión sobre dichas personas, dejando más tiempo para la investigación y desarrollo.
Si la precisión de los estimados baja, el coste al cliente aumentará, la confianza del equipo bajará, lo que incrementará los conflictos, disminuirá los tiempos para investigación y aumentará la presión. Como ves es un círculo que puede ser vicioso o virtuosoy se pueden emplear vínculos no medibles en otros diagramas como ser la presión o confianza del equipo. Este diagrama contiene un bucle de retroalimentación y 2 que lo potencian.
Los diagramas entonces contienen bucles causales, en los cuales las interconexiones de causa y efecto se expresa como una red de bucles de refuerzo  que o exponencia el crecimiento o declive (en el ejemplo 1 bucle y 2 de refuerzo). A su vez se cuenta con bucles de balance, los que actuan para contrarrestar la energía de los bucles de refuerzo. Sumado a esto se adicionan variables de entrada (y salida) las que alimentan los ciclos y la velocidad de rotación.

Estos mapas mentales te pueden ayudar a conocer de antemano los resultados posibles en una modificación de contexto, por ejemplo, la pérdida de motivación de un equipo Scrum, nuevo miembro del grupo, cambio en la empresa, nueva política, etc, asi como también detectar ciertas restricciondes que esten frenando al equipo o compañía ne producir más y darte una idea de que áreas atacar/eliminar.
Esto último no es muchas veces intuitivo, ya que por sentido común se realizaría lo contrario.

Si se desea ir un paso más allá, puedes transferir el modelo a una herramienta de software, la que te permitirá verificar los posibles resultados de un cambio o detectar una restricción de forma dinámica (alterando valores).

El comprender los modelos de bucles, interacciones y propiedades emergentes ponen claridad a varias características que hacen que Scrum funcione y son un paso importante y necesario para cualquier practicante Agile.

La creación de los modelos causales puede resultar en comportamientos dinámicos muy complejos, que hagan dificil predecir el futuro. No obstante, la idea es el comprender plenamente el pasado para actuar en el presente e influenciar el futuro tanto como sea posible.

Te recomiendo una lectura sobre pensamiento sistémico detallada (Systems Thinking and Complex Systems en Inglés), lo que sin lugar a dudas te redituará en un crecimiento exponencial en la comprensión de Agile y aumentará las posibilidades de éxito de tu empresa.

Lee la última parte del artículo aquí.

Gracias por escucharme,
Erich.

Lo que olvidaron enseñarte: pensamiento sistémico (I)

Pensamiento sistémico es un área que no se incluye en los cursos de Scrum Master, Propietario de producto, o metodologías tradicionales y considero que  su exclusión está intimamente relacionada con el fracaso de varios proyectos de software.

El pensamiento sistémico y los modelos complejos son el nucleo para todos los que deseen realmente ser asertivos con la implementación y utilización del pensamiento Agile y particularmente del marco de trabajo de Scrum/DSDM. A su vez, puede ser una herramienta de principal apoyo a aquellos individuos que empleen marcos de trabajo más tradicionales.
Podrías por ejemplo llevar adelante Scrum, pero su resultado sería sin lugar a dudas menos efectivo si no conoces los modelos de pensamiento sistémico y como analizar su complejidad.

Pensamiento sistémico y el modelo tradicional
Imagínate por un segundo que tiras una moneda al aire y quieres predecir de que lado caerá. En realidad, la probabilidad de que aciertes será bastante alta.
Imagínate ahora que trabajas en una empresa que emplea metodologías tradicionales y que te solicita documentes el proceso y protocolo. Esto se podría ver algo así:

1. Se obtiene una moneda
2. Se tira al aire empleando una fuerza moderada que a su vez estimule su giro
3. Se espera a que la moneda caiga
4. Se estima que la moneda caerá aproximadamente un 49.5% cara, 49.5% cruz y 1% en el borde.
5. Se repite el proceso

Podrías predecir que el resultado final será de +- 50% cada lado; a mayor número de tiradas más será la exactitud de tu predicción. A su vez, si la empresa te solicitase dibujar un plano de una máquina para tirar monedas, ella podría desarrollarse y verificarse con los resultados aproximados descritos en el documento. El proceso podría verse algo así:

1. Análisis y caso de uso (lo realizado anteriormente)
2. Construcción del prototipo
3. Validación de los valores de resultado con estimaciones previas (49.5,% 49.5%, 1%)
4. Instalación de la máquina en donde el cliente solicite
5. Mantenimiento y reparación para el caso que algo falle
(el fallo se detectaría si la moneda no es lanzada o cuando no exista una relación entre los resultados estimados. Esto podría darse, por ejemplo, debido a que la misma ya no es lanzada con giro y aterriza siempre en la misma cara).

Imaginemos ahora otro escenario:  trabajas en una empresa y te solicitan que reduzcas el precio de un producto en 1%. Evidentemente sería posible documentar los pasos pero… ¿Podrías hacer lo mismo con las consecuencias?

Si bajas el precio del producto, esto podría traer como resultado un conjunto innumerable de consecuencias, desde un aumento de la venta, una guerra feroz con la competencia, clientes que sospecharían que la reducción implica también una bajada en la calidad o sientan que el producto no es más exclusivo, tiendas de bajo coste queriendo venderlo o de alto rechazando al mismo, etc. A su vez, esto quizá afectaría a otros productos de tu compañía, lo que podría terminar en una venta mayor a la esperada o la empresa dando quiebra unos años mas tarde. En el primer caso, podrías obtener un ascenso, lo que aumentaría tu sueldo y te permitiría comprar una casa y darle empleo a un conjunto de persona;  en el segundo, que tuvieseses que buscar un nuevo trabajo, lo que quizá te daría tiempo para estudiar sobre pensamiento sistémico y aplicarlo en tu futura posición.
Como ves, un simple y único evento acarrea un número inimaginable de consecuncias y escenarios, aunque podría también no pasar nada -aunque muy improbable-  y es otro resultado.
¿Cuál es la diferencia entre el primer y segundo ejemplo? ¿Son estos eventos totalmente impredecibles o existen reglas que permintan «domesticar» sus posibles resultados?

everythingConnected2

Cuando tiras una moneda, este evento te involucra a ti en primera persona y se realiza en un ambiente «controlado«. Cuando bajas el precio, la situación es completamente diferente ya que existe un número elevado de entidades inter-relacionadas.

«Un sistema es un conjunto de elementos interconectadas de tal forma que produce sus propios patrones de conducta»

Los clientes están conectados con el precio, competidores al valor de tu producto y margen de mercado disponible, prestigio de la marca, el gobierno a las regulaciones de mercado antimonopólicas, etc. El efecto de las consecuencias factibles es claramente ilimitado.

El modelo de pensamiento sistémico
La pregunta evidente es… ¿Porqué es esto así?
Obviamente se da como consecuencia directa de la conexión entre las partes involucradas. Si no hubiese una conexión entre ellas, el ciclo de causa-efecto pronto se dentendría de la misma forma que una rueda a la que no se le da más impulso dejaría de girar. Es interesante tener en cuenta que el ciclo de causa-efecto es a su vez retroactivo, esto es, existe un conjunto de causas que dieron como resultado la bajada de precio en el presente, por lo que la misma iniciará consecuencias en el futuro, haciendo la expansión de ellos en el tiempo y espacio.

«El ciclo causa-efecto es siempre retroactivo»

Future__Present__Past_by_JusT_ShanT

(c) 2011, Ishan Arora

Es importante destacar que el requisito indispensable por lo que ello ocurre es porque se trata de un sistema abierto, y es esa exposición la que genera la causalidad de hechos.

«Para que un sistema tenga una energía constante, el circuito debe estar abierto, ya que la energía debe ser importada del exterior, desde el exterior de sus límites .»

Déjame ponerte un ejemplo de la importancia del sistema abierto… imagínate un equipo de desarrollo de un producto de software donde no exista una retroalimentación por parte del cliente. Evidentemente la motivación y el «feedback» externo que es la energía que hace girar la rueda se irá perdiendo poco a poco hasta el punto donde los integrantes del proyecto no estén interesados en continuar adelante o hayan finalizado con todas las tareas.

«Parte de la energía es almacenada para impedir la desintegración futura, otra parte es transformada por y para las necesidades del sistema.»

Se podría adicionar más energía al sistema y así girar la rueda incrementando el salario del empleado, pero una vez que el mismo se acostumbre al monto, el proceso iría en declive hasta frenarse nuevamente. Es por ello que hay que no pasar por alto cuales son los motivos que apoyan a un equipo de personas.

Pensamiento sistémico y modelos parcialmente abiertos
En las metodologías tradicionales se tratan a los modelos como  parcialmente abiertos (una rueda con pocos agentes externos que la muevan o en ciertos momentos). Las causas suelen tener una sinergia al comienzo del proyecto y congelarse tanto como sea en etapas posteriores. Ello se logra documentando diferentes variables al inicio, como ser los requisitos y riesgos.

agujeroEllo se llevará adelante mediante la evaluación de los problemas (efectos) vistos en proyectos anteriores, esto es, que la idea de que caiga un meteorito y destruya el servidor conteniendo los códigos fuente o haya un ataque extraterrestre (mas allá del suceso del cine)  sea una posibilidad remota, por lo que se descarte.

Para el caso de aparecer un riesgo documentado durante la vida del proyecto, se seguirán los pasos articulados inicialmente en el documento. Es importante entonces preguntarse:

¿El modelo tradicional resulta efectivo cuando se trabaja con elementos inter-relacionados?

A mi parecer, la causa-efecto de un modelo medianamente cerrado tiene varios inconvenientes: un cliente podría descubrir por sí mismo nuevas formas de resolver un problema mientras se encuentra el software en etapa de desarrollo, las cuales no podrían ser fácilmente adicionadas a la aplicación por tratarse de un sistema medianamente cerrado o controlado. Cualquier adición o cambio podría introducir o abrir nuevos caminos, lo que este tipo de metodologías trata de mitigar.
Por el otro lado, podría haber riesgos no documentados y tener que interrumpir una etapa para buscar una solución o dejarlo para el final del desarrollo por no haber personas disponibles para atenderlo.
Adicionalmente, la base de las metodologías tradicionales tal cual se conocen se basan en un modelo semi-estático de piezas (o recursos) que se encajan o remueven para el fin de satisfacer una demanda (modelo Tayloriano). Esto queda claro cuando se emplean los gráficos de GANTT, en donde se adicionan o remueven personas u otros elementos a un proyecto sin evaluar su causa-efecto. El proceso funciona en base a saciar necesidades, esto es, se asocia una persona a un determinado proyecto porque tiene los conocimientos requeridos para llenar la necesidad.

Ello aunque es correcto, implica solamente una visón parcial de la situación donde no se analiza la repercusión o efecto del cambio en la cadena de conexiones en el sistema en su totalidad y su causa. Es importante preguntarse entonces:

¿En una empresa de software, la creación de un producto se parece más al ejemplo de la moneda o al de la bajada de precio?

El pensamiento sistémico ofrece una forma diferente de aproximar las situaciones, y aunque es la base del pensamiento Agile, las técnicas pueden ser empleadas en cualquier forma de trabajo.

En la segunda parte de este artículo iré más allá mostrándote porqué el nucleo de Agile y Scrum es sistémico y considero su desconocimiento puede ocasionar el fracaso de uno o más proyectos de software.

Gracias por escucharme,
Erich.

¿Scrum Master de tiempo parcial/ compartido? (4 de 4)

El tema de un Scrum Master a tiempo parcial es una de las inquietudes que más he encontrado al hacer consultorías, en los cursos de certificación que he dictado o en mis trabajos previos como Scrum Master.

¿Debería ser el pusto de Scrum Master de jornada completa o puede ser un role compartido?

Parte de la respuesta lo abordé en las entradas anteriores; detrás de esto está la suposición implícita que el Scrum Master no es un role de jornada completa. La mayor parte de las conjeturas se basan en la idea que el fusionar dos roles puede hacer un ahorro sustancial de dinero y así incluir las responsabilidades de ambos en una sola persona.

Es casi inmediato el comprender que un un miembro del equipo de programación es de jornada completa porque sin el no habría software posible, se le puede ver escribiendo código, se lo ve sentado enfrente del computador y ello implica su necesidad. El Propietario del producto es otro ejemplo, se pasa todo el día planificando las características del producto y trabajando en el mapa de ruta, negociando con las partes interesadas, priorizando, descomponiendo historias de usuario, etc. Sin embargo, es difícil para las personas que recién comienzan con Scrum el imaginar un Scrum Master como de tiempo completo.
He trabajado como Scrum Master por mucho tiempo en diferentes empresas y paises, desde pequeñas hasta muy grandes.Es un trabajo muy dificil ya que requiere de muchas habilidades y energía y debo decir que la mayor parte de mis días comenzaban temprano en la mañana, transcurrían muy frenéticamente y finalizaban siempre con mucho trabajo.

Por otra parte, las empresas que recién comienzan también piensan que es el grupo quien dicta lo que se hará y nunca el Scrum Master. Esto en realidad no es tan así, ya que este último puede indicar que se necesita mejorar un área, por lo que se debería probar una técnica por 2 semanas. Luego el equipo tendría que evaluar si funciona, y de ser así incluirlo.

En mi criterio, quienes se preguntan que hace un Scrum Master de tiempo completo no conocen lo que este hace en realidad. Raramente en las empresas que trabajé como Scrum Master tendría tiempo para «compartirme» entre dos grupos. Estoy de acuerdo con Bernd Schiffer sobre las tareas que debe hacer un Scrum Master y he complementado ellas con otras que han ido surgiendo con el paso de los años:

1. Facilitar cualquier reunión del Equipo; incluyendo preparar, moderar y procesar posteriormente los resultados de la reunión

2. Organizar y moderar las retrospectivas.

3. Asesoramiento individualizado a los miembros del equipo

4. Mediar en conflictos que surjan durante el desarrollo del rpoducto

5. Ayudar al equipo a tomar decisiones

6. Fomentar la auto-organización del equipo

7. Mediar en el conflicto general entre los objetivos del Equipo y los objetivos del dueño del producto (alta
calidad técnica vs. más características).

8. Continuamente aprender, leer y reflexionar sobre cualquier cosa con respecto a Agile (por ejemplo, visitar grupos de usuarios, asistir a conferencias, leer libros, escribir blogs, etc)

9. Dar soporte a los miembros del equopo y a la organización con respecto a todo lo que es Agile.

10. Ayudar al Equipo a crear radiadores visuales.

11. Dar retroalimentación al equipo.

12. Fomentar el uso de prácitcas de ingeniería dentro del equipo de desarrollo

13. Desafiar al equipo con innovaciones de gestión Agile.

14. Intercambiar constantemente puntos de vista, técnicas y experiencias con otros Scrum Master de la empresa a través de comunidadades de práctica.

15. Ayudar al Equipo y Propietario del producto a escribir y separar las historias de usuario

16. Ayudar a las partes interesadas y dueño del producto a comprender como escribir y separar las historias de usuario.

17. Ayudar a las partes interesadas y propietario del producto a crear una visión del producto.

18. Ayudar al propietario del producto a comprender como organizar los elementos de la pila y enseñarle técnicas.

19. Ayudar al Equipo de desarrollo, dueño de producto, partes interesadas a con la entrega de la planificación

20. Estar familiarizado con el producto y el trabajo del equipo

21. Reunir a personas que deberían hablar entre sí pero no lo hacen

22. Estar en contacto con las partes interesadas regularmente

23. Ayudar al Equipo de desarrollo y al propietario del producto para que proporcionen información significativa, apropiada y puntual a la dirección.

24. Ayudar a promover la comunidad de Scrum y Agile dentro de la organización

25. Organizar eventos de intercambio para los miembros del equipo, propietario del producto, partes interesadas de la organización

26. Facilitar e implementar la diseminación de conocimiento en el grupo, por ejemplo organizando las sesiones «Brown Bag»

27. Compartir perspectivas por toda la compañía

28. Ser la persona de contacto para todo el mundo, tanto sea el Equipo de desarrollo, partes interesadas, etc sobre Scrum/Agile

29. Dar oportunidades de aprendizaje a las personas en la organización a través de charlas, talleres de trabajo, u otros foros y dejarles que aprendan conceptos importantes sobre Agile.

30. Ayudar al equipo a identificar y deshacerse de los impedimentos

31. Sugerir nuevas métricas para que el equipo de desarrollo las use como catalizadores para el cambio.

32. Reflejar los valores de Agile y Scrum al equipo.

33. Recordar al Equipo de desarrollo sus disposiciones, normas y políticas

34. Ayudar continuamente al equipo de desarrollo a mejorar sus procesos

35. Plantear cuestiones a las personas de desarrollo a través de la observación desde una visión de fuera del Equipo.

36. Realizar preguntas abiertas [poderosas].

37. Comprobar todos los modelos que el Equipo utilizasa (Sprint Backlog, métricas, etc. y demostrarles las diferencias entre el modelo y la realidad.

38. Ayudar al Equipo a centrar la atención actuando como un amortiguador entre las distracciones exteriores y el equipo.

39. Ayudar al equipo a mantener las herramientas de Scrum (Pizarra de tareas, Tablón de acciones, gráficos, pils, etc.)

40. Ayudar al equipo y al propietario del prodcuto a establecer una definición de hecho apropiada.

41. Preveer el futuro, como quiere el equipo trabajar la próxima semana, el próximo mes, año…

42. Construir y articular un objetivo o meta común para el equipo.

43. Ayudar al equipo a construir un grupo de valores que lo identifiquen.

44. Colaborar con futuros aspirantes de Scrum Master.

45. Ayudar al Equipo a mejorar sus habilidades sociales, especialmente con respecto a conversaciones constructivas.

46. Establecer las actitudes positivas y re-afirmarlas

Puede que me haya olvidado de alguna, pero a grandes rasgos están la mayoría.
Nuevamente la pregunta hay que tener en mente que se considera un equipo de alto rendimiento y cual es el principal motivo para eliminar este role.
Realmente te recomiendo como buen punto de partida interiorizarte con los Sistemas de pensamiento y Sistemas complejos para así poder entender la repercusión de un cambio de este tipo.

Esto finaliza la entrega de 4 partes de porqué un Scrum Master no debe ser de tiempo parcial o compartido con otro role de Scrum.

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)

¿Scrum Master de tiempo parcial/ compartido? (3 de 4)

Quizás la aseveración de que un Scrum Master no genera valor esté fundamentada en discusiones antiguas sobre el role. Lo cierto es que un buen Scrum Master siempre incrementa el valor entregado al cliente, por ser una persona exclusivamente focalizada en ayudar a mejorar el proceso. La mejora de un proceso genera un aumento en la entrega de valor al cliente.

Los 3 frentes del Scrum Master
El Scrum Master trabaja esencialmente en 3 frentes para mejorar el valor:

1. Con el propietario del producto
Enseñándole formas de trabajo dentro del modelo Scrum y asegurándose que la interacción con el equipo sean óptimas. Es muy común que el PO esté muy ocupado y tienda a descuidar al equipo o intente utilizar técnicas que no concuerdan con los valores de Agile.

2. Con el equipo
Remover impedimentos y realizar experimentos con los procesos del equipo para descubrir nuevas formas de hacer las cosas.
Es importantísimo destacar que hay un trabajo previo del Scrum Master cuando se conforma al equipo, en donde encausa el mismo a definir su identidad de grupo y reglas de trabajo (paso fundamental, muchas veces olvidado).

3. Con el cliente
En algunos casos, el Scrum Master puede asistir al propietario del producto en explicarle a los clientes sobre el marco del trabajo; también tiene un role fundamental en las reuniones de revisión del producto, asegurándose que se realice de la forma adecuada y se encause efectivamente.

Sinergia de los procesos
La sinergia de estos 3 procesos generan a su vez 3 ciclos de retroalimentación:

1. Hacia el equipo
Mejorando sus procesos y formas de hacer el trabajo y eliminando cualquier desperdicio.

2. Hacia la empresa
Haciendo que los procesos que impiden el tener un producto más rápido puedan ser optimizados.

3. Hacia el producto
Tratando de obtener aquellas funcionalidades que son realmente importantes y descartando el resto.

El role de un buen Scrum Master requiere conocimiento de técnicas en diferentes campos, tales como:

1. Motivación
2. Descubrimiento de valores y énfasis
3. Resolución de conflictos
4. Técnicas de negociación.

Esto hace que para cubrir este role se requieran conocimientos específicos ya que de lo contrario se tendrá un sistema sub-óptimo (ver mi definición en mi entrada anterior); el rotar a este role u otra modalidad se pueda hacer pero no es recomendable.

Normalmente las empresas que le quitan importancia al role de Scrum Master son aquellas que se focalizan menos en mejorar los procesos. ¿Un sistema con personas y computadores más inteligentes pero un proceso inferior son más efectivas que lo contrario?

Humano menos iteligente + computador débil + mejor proceso
fué superior a
Humano más eficiente + computador potente + proceso inferior”
Del libro “Metáforas del Ajedrez, Inteligencia artificial y el cerebro humano”

Esto último se dió como derivado de un largo estudio científico. El proceso es siempe el rey.

La creencia del incendio
He visto esta idea en muchas empresas de Latino América y España de cuando hay un incendio todos deben dejar de hacer sus cosas y focalizarse en apagar el fuego. En mi creencia, es que esta forma de pensamiento radica en hábitos que se arrastran
y tienen su origen en las metodologías tradicionales.

Ello además de provocar un daño en la moral de las personas y los grupos, genera inestabilidad en el sistema, lo cual aumenta la imprevisibilidad, cosa que termina generalmente bajando la calidad de una aplicación de software y destruyendo al sistema en si.

La aproximación de Scrum
Scrum se basa en una aproximación diferente, la cual consta de la creación de un sistema lo mas estable posible. Ello se logra -entre otros- mediante la libertad de un equipo a decidir responsablemente sobre que características será capaz de absorver y desarrollar en un ciclo de tiempo fijo. Para el caso que haya un problema, se deberá re-negociar con el propietario del producto el alcance en vez de apagar el incendio. Esto brinda mayor estabilidad al sistema, lo que permite entre otras cosas estimaciones mas certeros, aumentar la confianza del cliente sobre las fechas de entrega y disminuir el estrés del equipo.
En mensajes anteriores se mencionaba también el caso de SM rotativos. Este es otro ejemplo que agrega inestabilidad al sistema.

La estabilidad del sistema
Los miembros de un equipo deben ser tan estables como sea posible. Como dije antes, el proceso es el rey; esto es correcto y apoya a los valores de Agile y Scrum en su totalidad. Todo proceso en Scrum y cualquier metodología Agile debe apoyar al 100% a las personas y ayudar a entregar la mayor cantidad de valor posible al cliente. Es muy común cuando se comienza a utilizar Scrum en empresas más tradicionales que la parte gerencial no entienda el funcionamiento del marco de trabajo e introduzca procesos que no apoyen a las personas, equipo ni entrega de valor.

Por ello, el proceso es el Rey. Scrum nunca podrá funcionar si los procesos no apoyan a las personas ni a la entrega de valor.

Lee la tercera y última parte aquí

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)

¿Scrum Master de tiempo parcial/ compartido? (2 de 4)

La idea de Scrum es ofrecer un marco de trabajo que promueva un flujo contínuo.
Básicamente, podríamos imaginarnos un sistema donde no exista fricción representado por un valor 0 y valores positivos si hay elementos en este que puedan frenar el flujo de trabajo.
El modelo de Scrum trata de minimizar la fricción dentro del sistema de varias formas. Algunos factores son técnicos (fricción) y otros del proceso (impedancia). Estos factores incluyen:

1. Como el trabajo a llevar adelante es seleccionado y por quién.
2. Tamaño y secuencia del trabajo a realizar
3. Estructura de la organización
4. Personas realizando el trabajo y sus interacciones

A mayor fricción e impedancia, mayor será la lentitud para desarrollar el software pero también se incrementará la cantidad de tareas a realizar (o lo que es igual a mayor coste).

¿Qué pasa al tener 2 roles en 1?
Al tenerse 2 roles en 1, la persona no será capaz de realizar ambas a la vez, lo que generará una cola. Esto quiere decir que habrán tareas que deberán hacerse primero y otras después de los distintos roles. Este tipo de conductas adiciona mayor impedancia al sistema (sub-óptimo), lo que hace que el desarrollo sea más lento.

Ahora bien, se podría argumentar que ambas tareas no son realizadas al mismo tiempo, pero la realidad indica que cualquier situación que implique tener que elegir cual efectuar primero de distinos ámbitos estará dilatando la segunda, lo que generará una o mas colas.

El efecto de las colas
La cola influye no solamente sobre un proceso, sino sobre cualquiera que dependa del resultado. Si un equipo necesita que el SM ayude a remover un obstáculo pero este no está disponible hasta que no se haga otra tarea del role complementario, entonces se estará en esta situación.
Las colas aunque parezcan pequeñas, hacen que el sistema nunca pueda ser óptimo y derivan en un sistema sub-óptimo.

A su vez, para hacerlo aún mas complejo, si hay conflictos entre los roles como mencioné anteriormente, ello aumentará la complejidad de forma innecesaria en el sistema generando mayor desperdicio.
El desperdicio le cuesta dinero al cliente, por lo que existen dos opciones:

1. La empresa absorve dicho coste
2. Lo transfiere al cliente

Estas variables son solamente algunas de las que pueden alterar el sistema, haciéndolo más caro. En situaciones más extremas, el sistema podría volverse inestable. Por ejemplo, si el SM se va de vacaciones (o se enferma), se estarían perdiendo 2 roles, que podrían ser asumidos por otro miembro pero generaría inicialmente desperdicio, colas y un posible período de inestabilidad del sistema.

La inestabilidad de un sistema afecta directamente a los estimados de un equipo. Un Scrum Master reemplazando temporalmente a otro S.M. en un caso así generaría menor impedancia.

Es por ello que Scrum propone un modelo ideal donde la fricción e impedancia sean lo más cercano a 0.

Proponer desde un comienzo un sistema sub-optimo es para mi un error.

Lee la tercera parte aquí.

(artículo que corresponde a mi opinión en tema  del grupo Linkedin de Agile Spain sobre Scrum Master parcial/compartido)