De Scrum Master bueno a Scrum Master grandioso

Somos lo que hacemos repetidamente. La excelencia, por tanto, no es un acto, sino un hábito.

-Aristóteles

Así que ya eres o te consideras un(a) buen Scrum Master. Bien. Pero algo que aprendí en los últimos años es que siempre hay una acción de mejora, un camino que tomar que nos hará mejores. Qué tal si en vez de quedarnos allí, en ese claustro de “bueno”, damos un paso más allá, quizás más arriesgado, para convertirnos cada día no solo en mejores profesionales sino en personas sobresalientes, grandiosas. Trataré de explicar mi punto en los siguientes apartados:

Aprender del pasado

Quien olvida la historia, la suya y la de su entorno, está condenado a repetirla. Así que revisar una corta lista de cosas que han ido mal en el pasado y analizar con el equipo cómo podrían manejarse si se presentan nuevamente es una forma excelente de evitar esos mismos problemas. Las retrospectivas siempre son bienvenidas, no solo al final de cada iteración o hito del proyecto, sino siempre que se necesiten, como un instrumento de mejora continua.

Un buen Scrum Master hace esto, pero un gran Scrum Master proporciona además ejemplos vivos de lo que pasó, cuenta la historia completa. Recordemos que contando historias es como sobreviven las culturas y en ágil todo es acerca de la cultura. Mediante ejemplos, les decimos a las personas lo que esperamos de una manera diáfana. Si además los ejemplos son lo suficientemente buenos, estaremos proporcionando ideas valiosas sobre cómo los integrantes del equipo pueden lograr la meta final. No solo les estaríamos dando un contexto personal sino también profesional de algo que quizás no logren entender de otra forma.

Más allá de la ‘Definición de Terminado’

Un buen Scrum Master posibilita que el equipo en pleno tenga una Definición de Terminado (DoD); un gran Scrum Master se asegura de que la planificación conduzca a un plan claro y que el equipo en pleno tenga igualmente objetivos claros y alcanzables que vayan más allá de la DoD y que, si es necesario, existan objetivos intermedios que ayuden a lograr al objetivo final. Algunas metas pueden ser extensas en el alcance, pero deben describirse con simplicidad y de tal forma que comprometan al equipo y a la organización.

Los desafíos y el futuro

Un buen Scrum Master ayuda a preparar el entorno en el que su equipo creará productos con una excelente trama en su interior y que generen resonancia en los usuarios y soporta la implementación de Scrum en la organización. Un gran Scrum Master, además, prepara no solo al equipo sino a la organización para enfrentar los retos que llegarán: 

• dominar las tecnologías emergentes, pero también los enfoques y los cambios de paradigma que harán de los miembros del equipo personas más innovadoras, más proactivas y que entiendan mejor la filosofía ágil;
• compartir más para aumentar tanto la velocidad como la calidad de las decisiones -es  un asunto de mayor y mejor conocimiento;
• licenciar a todo el equipo y a todos en la organización para que se sientan empoderados y lideren el cambio y a crear valor continuamente; y
• anticiparse a las necesidades de los clientes, a identificar y resolver los problemas más rápido y a ir más adelante que la competencia.

Personas sobre Scrum Masters

Un buen Scrum Master sabe y promueve que el trabajo es importante, siembra la semilla en el equipo para que lleve un ritmo sostenido durante todo el proyecto a lo largo y ancho de toda la organización; un gran Scrum Master sabe y promueve que la vida es más importante que cualquier otra cosa, reafirma en el equipo que lo más importante son las personas, los desafíos personales e inspira a todos a que mantengan esas prioridades por encima de cualquier otro reto profesional, sin que se pierda de vista el compromiso, la responsabilidad y el foco de los miembros del equipo en los objetivos definidos.

Otros 10 consejos extraordinarios para ser un mejor líder

En su artículo “10 Awesome Tips for Being a Better Leader” (10 consejos extraordinarios para ser un mejor líder), Carly Okyle, asistente editorial de Enterpreneur, enumera estas sugerencias para ser un gran líder. Pienso que todo Scrum Master debería celebrarlas como parte de su rutina diaria si quiere llegar a ser realmente grandioso. De hecho, ya he mencionado algunas de estas indicaciones de una u otra forma en los párrafos precedentes:

1. Lidera mediante el ejemplo
2. Algo de humildad siempre cae bien
3. Practica la comunicación efectivamente
4. Promulga y cerciórate de que las reuniones sean productivas
5. Conoce bien tus limitaciones
6. Encuentra un mentor, siempre hay alguien que puede enseñarte algo
7. Sé emocionalmente consciente
8. Ten cuidado con y evita los errores comunes en el liderazgo, por ejemplo, pensar que tienes que tomar todas las decisiones o no tener presente que lo más importante puede suceder cuando no estás presente
9. Aprender del pasado, sobre todo de los errores del pasado
10. Nunca dejes de mejorar, los grandes líderes y, de hecho, las grandes personas, están aprendiendo constantemente y tratando de superarse a sí mismas.

Adenda

Un  buen Scrum Master dispone de los instrumentos y recursos necesarios para remover impedimentos en el proyecto; un gran Scrum Master se prepara y prepara a su equipo para lidiar con la complejidad, la incertidumbre y los cambios inherentes no solo a los proyectos de TI, sino a la industria en general.

Finalmente, recuerda que un buen Scrum Master triunfa con el equipo, un gran Scrum Master hace que las personas en el equipo sean más exitosas que él/ella.

¿Y tú, qué estás haciendo por pasar de ser un buen Scrum Master a un Scrum Master absolutamente grandioso? Házmelo saber en el foro.

------------------------------------------------------------------------

Más sobre Scrum Master en:

De Jedi Master a Scrum Master

Vademescrum, Sección I: El Scrum Master 1

Planificación del Sprint: el primer paso para producir el máximo efecto

Cultura Ágil, ese oscuro objeto del deseo

Ágil es algo que eres

Foto de http://pixshark.com

Para implementar una verdadera Cultura Ágil se requiere un nivel más alto de confianza de lo que es necesario en los enfoques tradicionales.  Responsabilidad y transparencia son dos de los beneficios clave de tener una Cultura Ágil. Más sobre Cultura Ágil en “Cultura Ágil: ese oscuro objeto del deseo”

Para alcanzarla, para establecer una verdadera Cultura Ágil, debemos revisar las ideas que tenemos de los enfoques tradicionalistas e iniciar un camino que quizás sea o se vea poco confortable para muchos en la organización, puesto que ese camino hacia la cultura ágil expone las debilidades existentes no solo en la estructura sino en el comportamiento organizacional, es como si el ojo del Gran Hermano se posara sobre todos los miembros de la organización y les permitiera observarse a sí mismos, como en un espejo virtual, y al resto del entorno: clientes, proveedores, socios de negocio y mercado potencial, a observarlos desde el exterior.

Por ejemplo, respuesta ante el cambio sobre seguir un plan, uno de los valores del Manifiesto Ágil, es apenas una de las divergencias filosóficas cardinales entre los enfoques enraizados desde siempre en el desarrollo de software y esta visión emergente que significa ser ágil. Sobre este valor en particular, pueden leer mi artículo relacionado aquí. Más sobre el Manifiesto ágil en este enlace.

La Cultura Ágil es un continuum:

• Empieza con la persona, se irradia primero hacia los equipos y luego a toda la organización, y termina en la persona.

Cuando hablamos de los productos, además de los atributos de excelencia que deben tener, es relevante interiorizar que:

• El responsable de la calidad de un producto es Todo el Equipo Ágil. Además, una vez que el equipo entregue el producto, que este deje la sala de desarrollo, es porque está preparado para salir a producción.
• Un error, una falla, no se ve como un evento crítico sino como una oportunidad de aprender acerca de los componentes del producto (el código, por ejemplo), del proceso y de cada uno de los miembros del equipo.

En su libro, “Being Agile”, Mario Moreira nos dice que “crear o adoptar una cultura ágil no se hace por accidente” y yo agrego: tampoco se hace por decreto. Moreira enumera algunas actividades que te ayudarán a moverte a una cultura ágil:

• Reconocer que moverse a Ágil es un cambio cultural
• Compartir los Valores y Principios Ágiles (continuamente)
• Establecer y compartir objetivos y motivaciones
• Obtener retroalimentación continua de los empleados. (Podemos extrapolar esto a conseguir retroalimentación de los socios de negocio, de los clientes, de los proveedores, es decir de todo el ecosistema organizacional)
• Adaptar el sistema de recompensas para alinearlo con la nueva cultura
• Identificar técnicas para ayudar a mitigar la resistencia de manera agradable
• Evaluar a la administración y ver si los empleados tienen una personalidad que les permita alinearse con la nueva cultura
• Comenzar a vivir los valores y principios que te ayuden a alcanzar la cultura que estás buscando
• Proporcionar mecanismos de comunicación que se alineen con la cultura que quieres
• Identificar y aplicar los procesos, métodos, prácticas y herramientas ágiles que estén alineados con tus objetivos
• Aplicar un enfoque de inspeccionar y adaptar para medir el progreso

Debo insistir en que la vía hacia una transformación ágil, más que adopción, es un salto en la evolución, en el sentido de los saltos que ha dado la naturaleza durante millones de años, solo que aquí no tenemos tanto tiempo, pero un cambio de este nivel puede llevar un quinquenio, quizás una década, sobre todo para organizaciones que llevan 30 o 40 años usando enfoques y técnicas tradicionales.

Es decir, no se trata simplemente de cambiar un proceso por otro e institucionalizarlo, no se trata estrictamente de pasar de “manual” a “automatizado”, o de ir de integración bajo demanda a integración continua. Estas apenas son señales de que “lo estás haciendo ágil” y, en últimas, ágil no es solo algo que haces, ágil también es algo que eres.

-----------------------------------------------------------------------------

*La imagen interior es de [http://kidskidskids.tumblr.com/]

Libro: ‘La práctica de inteligencia de negocios: guías para lograr proyectos exitosos’

“El escritor escribe su libro para explicarse a sí mismo lo que no se puede explicar.”

[Gabriel García Márquez, escritor colombiano]

Siempre me da mucho placer realizar este tipo de anuncios. Conozco a Mauricio hace casi dos décadas y hemos tenido la oportunidad de trabajar juntos en distintos proyectos, incluyendo algunos de Inteligencia de Negocios, y de compartir más allá de la práctica profesional. Sé de su pasión por la lectura, por los hechos de la Historia y conozco también del esfuerzo monumental que es escribir y más si se trata de un libro como este. Por eso sé que para Mauro escribir este volumen se convirtió en una osadía, pero finalmente está aquí, el fruto de muchísimas horas de desvelo y estudio.

En el libro, Mauro nos embarca en una lectura amena que inicia con los conceptos generales de la práctica de la Inteligencia de Negocios, pasando por el propósito y los elementos de la práctica, los métodos y las herramientas usadas, lo que él llama ‘la hoja de ruta de un proyecto de Inteligencia de Negocios’ y dedica capítulos enteros a temas vitales como las pruebas y la calidad del producto, el despliegue, gestión de cambios y actividades posteriores a la implantación, hasta llegar a la infraestructura requerida en los proyectos de inteligencia de negocios.

De todo esto, el capítulo VI es mi favorito, porque habla de las personas y de la relación cliente – proveedor, asunto natural cuando se trata de una organización orientada a los servicios de tecnología de la información. Mauro habla de los roles principales a tener en cuenta cuando se trata de tener éxito en los proyectos y en particular dedica una sección a los roles típicos en las organizaciones con iniciativas de Inteligencia de Negocios.

Y a través de todo el texto, Mauro también aborda el tema de cómo se implementan todos estos elementos con métodos y prácticas ágiles como Scrum. De tal suerte que este es un compendio sensato de lo que cualquier interesado, persona u organización, debe tener en cuenta al momento de llevar a cabo proyectos de Inteligencia de Negocios.

Contraportada de 'La práctica de inteligencia de negocios' de Mauricio Cotes

Una de mis partes favoritas en todo el libro tiene que ver con el uso de las metodologías. El pensamiento de Mauro no se circunscribe a un método en particular, permitiendo la elección al lector. Eso es excelente, porque no entra y no promueve  o siembra elementos dogmáticos en el texto, es una apertura sistémica.

De hecho, su ‘conclusión en relación con el uso de las metodologías’ es algo que no solo es aplicable a proyectos de Inteligencia de Negocios. Mauro nos dice:

 “Finalmente, es ideal que el proveedor tenga la posibilidad de configurar la metodología de manera tradicional o ágil dependiendo de las condiciones, premisas y la negociación hecha con el cliente. El cuerpo metodológico seleccionado debe ser configurable, debe estar documentado, los practicantes deben aprehenderlo y ser conscientes del propósito de cada uno de los elementos que lo constituyen.

Los practicantes de los roles encargados de la contratación y negociación deben tener en cuenta las premisas mencionadas y ofrecer la modalidad apropiada de trabajo según el caso.”

En definitiva, en ‘La práctica de inteligencia de negocios’, Mauro saca a relucir sus veinte años de experiencia en el tema. Es un libro escrito desde la pragmática del autor, con el suficiente soporte teórico, pero sobre todo, con la idiosincrasia nuestra, la del trópico, con la visión de nuestra economía y de nuestra forma de hacer proyectos, lo que lo convierte en un documento valioso para cualquier estudiante y profesional y para cualquier organización que piense en serio acerca de la práctica de la inteligencia de negocios.

Es un trabajo minucioso, que te ha costado encorvarte durante muchísimas y largas horas, pero finalmente tú y todos nosotros tenemos la mejor recompensa: un sumario de todo tu fogueo en el asunto. ¡Enhorabuena, Mauro, felicidades por este gran logro!

¿Quieres conseguir el libro?

Escríbanle un mensaje electrónico a Mauro a la dirección: rmcotes@hotmail.com. Él les dará más detalles de cómo obtenerlo.

Sobre medir y controlar o de cómo Tom DeMarco admitió su equivocación

“El Control conduce al cumplimiento; la autonomía conduce al compromiso”

― Daniel H. Pink (Autor de “A Whole New Mind: Why Right-Brainers Will Rule the Future”)

Imágen tomada del artículo de Computer.org

En 1982, Tom DeMarco escribió su renombrado libro “Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982). La primera frase del libro, su primerísima idea, quedó ensamblada en los anales de la industria de software durante las siguientes décadas y nos ha llegado intacta hasta esta era. Se trata de su: “No puedes controlar lo que no puedes medir”.

Este pensamiento influyó de manera certera en los modelos de calidad, procesos de producción, enfoques de mejora* y herramientas de construcción de software, quizás como ninguna otra idea de aquellos tiempos. Pero incluso Tom DeMarco cambió de opinión. En 2009 publicó este artículo en la IEEE Computer Society: “Software Engineering: An Idea Whose Time Has Come and Gone?”  (Ingeniería de Software: ¿una idea cuyo momento ha pasado?)” que pueden encontrar haciendo clic aquí.

En el artículo, DeMarco reflexiona sobre si este consejo era correcto en ese momento, sobre si todavía era relevante (al momento de escribir ese artículo en 2009) y que si todavía creía que las métricas eran un deber ser para cualquier esfuerzo exitoso de desarrollo de software. Sus propias respuestas fueron unos tajantes no, no y no.

Es bien conocida la historia de que los enfoques rígidos más tradicionalistas adhirieron completamente a este precepto y crearon áreas de proceso y de conocimiento dedicadas en su totalidad al establecimiento, gestión y control de métricas en los proyectos (de software). A partir de allí, se empezó a medir el éxito o fracaso de los proyectos, en principio, con tres de esas medidas: el tiempo, el presupuesto y la calidad, siendo esta última un poco más abstracta y más subjetiva si se quiere. Después, con muchas otras que no vale la pena mencionar aquí.

Esa institucionalización de métricas derivó a su vez en algo que con el tiempo se convirtió en uno de los mayores desincentivos para quienes trasegamos por los laberintos azarosos de la construcción de productos de software: el trabajo intensivo, esas largas jornadas de trabajo de doce, dieciséis y más horas diarias durante largos períodos de tiempo previos a la entrega del producto. Mi amigo y colega Jorge Abad dice en su blog Lecciones-Aprendidas.info que eso trajo como consecuencia la destrucción de hogares, de familias enteras y yo le creo.

Esta forma de trabajo extrema, cuya consecuencia principal, además de la citada por Jorge, era la de un bajón en productividad, acompañado de una entrega de producto con mala o malísima calidad, con el tiempo degeneró en algo mucho más grave que es de todos conocido: desmotivó a las nuevas generaciones a estudiar carreras relacionadas con la TI: Ingeniería Informática, de Sistemas, de Software y afines. El mismo Tom DeMarco (¡otra vez!) enunció en su otro libro, “Peopleware : Productive Projects and Teams” (2ª edición, 1999), que “no trabajamos horas extras en demasía para terminar el trabajo a tiempo sino para protegernos de culpa cuando inevitablemente no conseguimos hacer el trabajo a tiempo.” En efecto, lo hacíamos simplemente para cumplir, no para ser más productivos, ni para mejorar la calidad del producto. Y a eso nos llevó la fuerza ejercida por el modelo de Comando y Control y de la medición de cosas que no reflejaban la realidad del proyecto, al menos no la realidad de las personas que ejecutaban el proyecto.

La reflexión de DeMarco en el artículo que ya he citado termina también de manera asombrosa para quienes seguimos sus cánones durante casi tres décadas: “Consistencia y predictibilidad aun son deseables, pero nunca han sido las cosas más importantes. En los últimos 40 años, por ejemplo, nos hemos torturado con nuestra incapacidad de terminar proyectos de software a tiempo y en el presupuesto. Pero esta nunca ha sido la meta suprema. La meta más importante es transformación, creando software que cambie el mundo o que transforme una compañía o cómo esta hace negocios.”

Bien sabemos ya que lo más importante en los proyectos de software es la entrega continua y frecuente de Valor al negocio, desde el inicio del proyecto. Y que nunca más apostaremos o usaremos artes adivinatorias para establecer la fecha de entrega, ni qué parte del producto entregaremos en ese momento, ni cuánto será su costo. En cambio, empezaremos con planes y alcance iniciales y nos enfocaremos en la revisión continua de esas restricciones a medida que vamos avanzando. Finalmente, nuestra meta será siempre entregar el mejor producto posible, teniendo presente que ningún método con el enfoque de receta de cocina (léase métodos tradicionalistas) hará mejor lo que es mejor. Esta es la filosofía ágil.

Coletilla

Aquella aciaga prescripción de DeMarco sobre lo que se puede medir y controlar derivó en procesos rígidos, tradicionalistas, que dieron poder solo a algunas personas en la organización; pero lo realmente hermoso, lo humanamente divino, es que los métodos y las prácticas ágiles dan poder a todo el mundo… o a nadie.

--------------------------------------------------
* Por ejemplo, H. James Harrington, reconocido autor de libros sobre mejora de procesos, calidad, desempeño y gestión del conocimiento, y fundador del laureado Instituto Harrington, extendió el pensamiento de DeMarco, diciendo: “Medir es el primer paso hacia el control y eventualmente hacia la mejora. Si no puedes medir algo, no puedes entenderlo. Si no puedes entenderlo, no puedes controlarlo. Si no puedes controlarlo, no puedes mejorarlo.”

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas

Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos tipo CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se está hablando en el  #RSGECU2015.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.

No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.