 |
| Los Pilares de Scrum. Clic en la imagen para ampliar.
Sin ninguna duda, para que Scrum sea eficiente y efectivo, cada uno de estos pilares debe estar en pie, deben promoverse desde las personas y los equipos hasta toda la organización y deben apoyarse sin restricciones. Sin uno o más de estos pilares, cualquier implementación de Scrum está condenada a un cataclismo anunciado.
Déjame saber en el foro como te ha ido con la puesta en macha de estos pilares mientras implementas Scrum en tu organización.
Puedes descargar el PDF de la imagen en alta resolución haciendo clic aquí.
O me la solicitas a mi correo: lucho.salazar@gmail.com.
|
Mostrando las entradas con la etiqueta Métodos Agiles. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Métodos Agiles. Mostrar todas las entradas
miércoles, junio 01, 2016
Los Pilares de Scrum
martes, enero 19, 2016
Agilidad: algunas características intrínsecas
 |
| Infografía: Agilidad 101. Clic en la imagen para ampliar. |
AGILIDAD
La habilidad de las personas, equipos y
organizaciones de crear Valor, a la
vez que promover y responder al cambio para tener éxito en un entorno incierto.
Algunas características intrínsecas a la Agilidad son:
RETORNO
DE LA INVERSIÓN
Ágil proporciona ROI en forma de beneficios
cualitativos como el mejoramiento de la moral del equipo y principalmente ROI
en la forma de beneficios cuantitativos, expresado en términos económicos,
mediante la entrega continua y frecuente de soluciones con Valor.
MARCOS
DE TRABAJO
Estamos descubriendo formas mejores de desarrollar
software. Los marcos de trabajo ágiles son iterativos e incrementales y de
Valor. Scrum y otros métodos y prácticas ágiles se basan en la teoría empírica,
es decir, aprendemos de la experiencia. El propósito final de las prácticas
ágiles no es tanto el hacer como el encontrar formas mejores del hacer.
TIEMPO
Entregamos productos frecuentemente, incluso todos
los días. Las iteraciones son períodos muy cortos de tiempo que finalizan con
la entrega de productos que generan Valor del negocio.
DOCUMENTACIÓN
Valoramos más las soluciones en uso que la
documentación exhaustiva. La meta de ágil es encontrar el balance adecuado
entre la documentación y la comunicación cara a cara. La documentación es una
parte importante de todo producto, pero la documentación exhaustiva como tal no
asegura el éxito de un proyecto. De hecho, aumenta la probabilidad de fracaso.
INNOVACIÓN
En la forma de mejoramiento continuo. Las prácticas ágiles nos permiten encontrar
formas innovadoras para crear productos y servicios mejores, más baratos, más
livianos, más rápidamente y de una forma más conveniente y personalizada para
nuestros clientes.
PERSONAS
Valoramos más las personas y la comunicación cara a
cara entre las personas. Lo más importante en el ecosistema ágil somos las
personas. Los equipos son autoorganizados y nuestra mayor prioridad es
satisfacer al cliente.
MEDICIÓN
Las mediciones se hacen mediante observación directa
en el lugar de trabajo, el Gemba, y medimos
la realidad de la organización y de los proyectos con el ánimo de encontrar
continuamente opciones de mejoramiento. Fomentamos la retroalimentación
continua en todas las direcciones.
miércoles, octubre 28, 2015
El enfoque Iterativo e Incremental, ¡una vez más!
El enfoque Iterativo e Incremental, ¡una vez más!
Mucho se habla de esto, de hecho iba a titular este artículo: “Todavía otra lección más sobre el enfoque iterativo e incremental para construir productos (de software)” pero entonces pensé en cambiar ligeramente la dirección del tema… Pero no tanto.
Iterativo e incremental son de esos principios que pueden resultar artificiosos para quienes intentan aplicarlos por primera vez. Su interpretación se presta a confusiones y a desacuerdos y finalmente los productos que surgen de los así llamados ‘proyectos iterativos e incrementales’ terminan siendo una colcha de retazos, pedazos de funcionalidades que no se integran bien entre sí y que terminan ocasionando más problemas al usuario de los que intentan resolver.
En breve, ‘iterativo’ quiere decir ‘en períodos cortos de tiempo’. El término clave es ‘cortos’. ¡De menos de un mes, gritamos a los cuatro vientos los agilistas! Durante este período se diseña y se construye, en el sentido extenso de la expresión ‘diseñar y construir’, una parte del producto que llamamos ‘incremento’. Pero no es cualquier parte del producto la que se construye. Sin embargo no voy a detenerme mucho en ello. Pueden consultar más sobre ‘Iterativo e Incremental’ aquí, gracias a Javier Garzás, o en cualquiera de estos lugares:
- Iterative vs. Incremental Development, by Jeff Sutherland
- Incremental versus iterative development, by Alistair Cockburn
- Don’t Know What I Want, But I Know How to Get It, by Jeff Patton
O algunos de los míos:
- Desarrollo de software por iteraciones, de hace 12 años
- O este otro de hace tres año y medio: Gerencia de Proyectos Iterativos: de cómo el software se puede construir por incrementos
- O esta traducción que hice de un artículo de Mike Cohn: Ágil necesita ser tanto iterativo como incremental
Entre muchos otros. Y no puedo terminar esta breve presentación del tema sin referirme a esa imagen que ya se está convirtiendo en icónica y que ilustra muy bien este par de conceptos: se trata de la imagen de Henrik Kniberg, actualizada:
Pero a dónde verdaderamente quiero llegar esta vez es a este asunto del ‘Incremento de Valor’, ¿qué quiere decir eso realmente? Así que empecemos de nuevo:
El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor
Resuelta la trama de ‘Iterativo e Incremental’, lo que queda es entender qué significa ‘producto de Valor para el cliente o usuario’, qué significa ‘Desarrollo de producto dirigido por el Valor’. Vamos a ver si lo logramos entender:
En este enfoque, conocido también como ‘desarrollo guiado por el valor’ o VDD, por sus siglas en inglés, el cliente o usuario juega un papel primordial:
- Es el cliente o usuario del producto quien determina o establece su valor, no el equipo de desarrollo
- Es el usuario o cliente quien solicita el producto, o esa porción del producto, es decir, fue ese usuario o cliente quien priorizó el desarrollo de ese incremento en ese momento del tiempo (del proyecto)
- El incremento resuelve un problema pequeño o parte de un problema grande al usuario
- Le permite obtener retorno de la inversión que está haciendo (ROI): reduce los costos para el negocio o aumenta las ganancias… ¡o ambas cosas a la vez! En últimas, al entregar el producto hay o se genera una compensación para el usuario, además de la satisfacción aumentada y de la felicidad recargada, no solo de él como receptor de un objeto de valor, sino de todo el equipo de desarrollo y, por qué no, de todos los demás interesados, dado el logro de objetivos.
Foto de FreeDigitalPhoto.Net
- Varias o muchas personas se benefician de inmediato con el producto (con su uso), ya sea porque lo están usando directamente (usuarios, clientes) o porque otros lo usan (patrocinadores, otros interesados, alta gerencia, etcétera)
- El producto está diseñado para humanos, sus componentes hacen resonancia unos con otros e impactan el modus vivendi de las personas, aunque solo para mejorarlo
Human-driven development o HDD –Desarrollo de Software Para Personas. Foto de FreeDigitalPhoto.Net
- El riesgo del proyecto, inherente a cualquier tentativa de construcción de software, se reduce dramáticamente luego de las primeras entregas. Si hemos de fallar, que sea rápido, en porciones pequeñas y muy barato. A partir de allí, el ascenso hacia el logro de los objetivos es vertiginoso y siempre positivo.
- El crecimiento del producto es orgánico, se parte de un mínimo producto viable o ‘mercadeable’ (MVP por sus siglas en inglés) y el producto completo va creciendo alrededor de este MVP, en entregas sucesivas y constantes. Y ya que llegamos a este apartado, olvidémonos del “viable” en el MVP, la V ahora es por Valor, como en Mínimo Producto de Valor. Recordemos que este MVP es el primer objeto con el que el cliente o usuario podrá interactuar, así que el impacto a conseguir debe ser máximo, debemos hacer que se convierta en un objeto de deseo. A propósito de deseo, entonces en vez de llamarlo MVP, nombrémoslo MDP, por las siglas en inglés de Mínimo Producto Deseable. Es un juego de palabras, apenas para mi Gazafatonario, pero ayudan a entender lo que queremos realmente con esta generación de valor desde las primeras de cambio.
- Se disminuye considerablemente la incertidumbre, tanto la del proyecto como un todo, como la del producto que se empieza a usar. Esto ocurre porque con cada entrega el equipo conoce mejor a su usuario y aprende mucho más rápido de sus necesidades y ambiciones. A la postre, el equipo construye el software para aprender y medir el impacto del uso real del producto. Después de todo, el proceso de creación de conocimiento se acelera si ellos entregan rápido un conjunto mínimo de elementos del producto priorizados por los objetivos que el cliente quiere alcanzar.
No son las únicas condiciones, si acaso algunas de las más importantes. En cualquier caso, la próxima vez que te soliciten un plan de trabajo para un proyecto, ya sea a mediano o a largo plazo, ten el coraje de responder: ¿quieres un plan a mediano/largo plazo o Valor en términos cortos?
Nota: este artículo se publicó originalmente en Pulse de LinkedIn en el siguiente enlace: https://www.linkedin.com/pulse/iterativo-e-incremental-luis-antonio-salazar-caraballo
viernes, septiembre 11, 2015
Gerencia de Proyectos Iterativos: de cómo el software se puede construir por incrementos
Divide et impera: ‘divide y vencerás’.
Frase atribuida a Julio César.
 |
| FreeDigitalPhoto.Net |
Los proyectos de construcción de software deben responder
con prontitud a los cambios frecuentes e inesperados tanto en los requisitos
del negocio como en la tecnología de implementación. Es habitual que en estos
proyectos haya una gran incertidumbre en cuanto al alcance, a la fecha de
entrega y al presupuesto requerido, lo que conlleva un alto número de riesgos
que obstaculizan la consecución de los objetivos propuestos.
Por ejemplo, es un grave error con consecuencias atroces,
asumir que los usuarios –generalmente personas de mandos medios y altos– son
capaces de suministrar al equipo del proyecto información oportuna y precisa de
todos los requisitos para un sistema de software. Además, uno de los problemas
principales de la construcción de software tradicional recae en el hecho de que
quienes han estado involucrados en ello hasta la fecha no están dispuestos a
reconocer que esta actividad es, la mayoría de las veces, un asunto de
planeación ocupacional y organizacional.
Corresponde precisamente al gerente del proyecto lidiar
con todos estos factores que entorpecen la evolución normal de un proyecto de
software. Es el gerente del proyecto quien sabe que los procedimientos
tradicionales seguidos tienen un conjunto de riesgos tácitos “indetectables”
dada la propia naturaleza del ciclo de vida de los proyectos. Los proyectos iterativos propician la detección
temprana de los riesgos y facilitan su manejo anticipado por parte de los
responsables. Pero ¿qué es realmente un proyecto iterativo? Para entenderlo,
veamos lo fundamental.
¿Qué es una Iteración?
Una iteración es un mini-proyecto con una salida bien
definida: una versión incrementada, estable, probada e integrada del producto
de software, con su documentación asociada.
Esta definición lleva implícito un concepto muy
importante: la versión o porción de software que se produce en una iteración tiene
tales cualidades que se podría no solo mostrar al usuario sino poner en
producción. De hecho, en fases avanzadas del proyecto, esto ocurre con
regularidad; es decir, en un proyecto iterativo es posible tener versiones del
software funcionando antes de terminar el proyecto.
Características de las
Iteraciones
Ahora bien, como cualquier proyecto (de software), una
iteración pasa por todas las etapas de un proyecto tradicional: inicio,
planeación, ejecución y control, y cierre. En el caso particular de los
proyectos de software, durante la etapa de ejecución y control de una iteración
encontramos el ciclo tradicional del software: modelado de requisitos, análisis
y diseño, implementación, pruebas, integración y, opcionalmente, despliegue,
aunque una iteración no necesariamente cubre todas las etapas.
Pero la verdadera esencia de las iteraciones radica en otros
aspectos que buscan disminuir la incertidumbre en los proyectos, aumentar el
desempeño, mitigar los riesgos, sobre todo reducir los riesgos técnicos en las
primeras iteraciones, y recibir retroalimentación continua y efectiva de los
usuarios. El primero de estos aspectos es la duración de las iteraciones: de
unos pocos días hasta unas pocas semanas es lo más eficaz, aunque también
depende del tamaño del equipo y de la duración total estimada del proyecto.
Figura 1: esquema de
una iteración típica. Cada iteración es un mini-proyecto con todo lo que ello
implica.
Excepto quizás en proyectos grandes con más de 40 o 50
personas, la idea es no tener iteraciones de varios meses, ya que en ese tiempo
puede ocurrir lo que sucede en los proyectos ejecutados en cascada: hay poca o
ninguna mitigación de riesgos técnicos, puesto que no hay entregas “visibles”
para los usuarios, recibimos poca retroalimentación de ellos y así no medimos
eficientemente el progreso del proyecto, o no podemos reaccionar a tiempo ante
una mala decisión técnica que conduzca a un retraso en el proyecto.
Duración de las iteraciones
Número de personas
|
Duración
|
2
a 15
|
2
a 4 semanas
|
15
a 30
|
4
a 6 semanas
|
30
a 50
|
6
a 8 semanas
|
Fuente:
Bittner, K. Spence, I. Managing Iterative software Development Projects. Addison Wesley Professional. Junio 27, 2006.
Otro aspecto importante es que la duración de las
iteraciones no tiene que ser la misma, pero la desviación debe ser pequeña. La
idea es no tener iteraciones de dos semanas y otras de seis o más. Scrum, una metodología ágil ampliamente usada
hoy día, por ejemplo, promulga iteraciones de 30 días, llamadas Sprint, con equipos de menos de 10
personas. Y ya que menciono Scrum, me parece importante aclarar que no todos
los proyectos iterativos son ágiles, pero todos los proyectos ágiles son
iterativos; la iteración es una propiedad intrínseca de las metodologías ágiles
de construcción de software.
Gestión iterativa de
proyectos
Otra de las características principales de este tipo de
proyectos es que en las primeras iteraciones se construye la porción de
producto que es significativa para la arquitectura del software. El gerente del
proyecto se apoya en el arquitecto y en los ingenieros de requisitos para tomar
la decisión de cuántas iteraciones “arquitectónicas” tendrá el proyecto,
normalmente de 1 a 3, y qué funcionalidad será implementada, de tal manera que
al final de esta fase (llamada de Elaboración, de Planeación o de Arquitectura,
según la metodología que se use), no solo existe un documento de arquitectura o
de diseño de alto nivel, sino que hay software funcionando cuyo propósito es
demostrar que esa es la arquitectura correcta para el producto.
Figura 2: Perfil de los riesgos durante la
gestión iterativa de proyectos. Los riesgos técnicos disminuyen en las primeras
iteraciones. Contrario a lo que sucedía con el método en cascada, donde los
riesgos disminuían al final del proyecto, durante las pruebas en el mejor de
los casos.
La gestión iterativa de proyectos puede tomar muchas
formas, dependiendo de las metas del proyecto: el desarrollo iterativo de prototipos puede ayudar a evolucionar
una interfaz de usuario. El desarrollo ágil
es una forma de involucrar muy de cerca un usuario en un proceso que podría
repetirse diariamente. Entre tanto, el desarrollo incremental permite al equipo del proyecto a producir incrementos
semanales o en cortos períodos de tiempo, mientras que un modelo en espiral puede ayudar al equipo a
confrontar y a mitigar los riesgos de un producto en evolución.
En estos casos es el gerente del proyecto quien toma la
decisión de la estrategia a seguir, teniendo en cuenta el valor de distintas
variables: tamaño del proyecto, tamaño del equipo, experiencia del equipo y de
los usuarios, criticidad y complejidad del proyecto, los riesgos técnicos y
administrativos, el grado de volatilidad detectada de los requisitos y las
herramientas de apoyo disponibles.
 |
| Foto de FreeDigitalPhoto.Net |
La gestión iterativa ayuda a superar las barreras de
especificación y de comunicación entre los usuarios y el equipo de trabajo con
el único objetivo de alcanzar la más alta satisfacción de los primeros. El
factor clave es precisamente que las personas del negocio entiendan los
requisitos y retroalimenten a las personas de tecnología. En este apartado, el
papel del gerente es de mediador, por lo que debería incluir elementos de
comunicación efectiva, como la tolerancia –cuando no se confunde con la
pasividad–, la imparcialidad y la empatía, para construir confianza y
disciplina entre unos y otros.
Corresponde al Gerente del Proyecto integrar el equipo de
trabajo con todos los involucrados tanto
internos como externos y la gestión iterativa posibilita una integración paso a
paso. Para lograrlo, el gerente del proyecto debe tener en cuenta algo que está
fuera de su control: una infraestructura cambiante y un proceso de negocio
inestable. También se debe vincular la estructura del proyecto (iterativo) con
el éxito del proyecto, de esta forma, no habrá espacio para la ruina del
proyecto.
Esto se logra mediante la motivación interna del equipo
de trabajo, el desarrollo de competencias blandas (negociación, técnicas de
comunicación –escrita, verbal y no verbal–, manejo eficaz del tiempo,
creatividad, trabajo en equipo, entre otras) y la “implantación no invasiva de
chips de alta efectividad”, como la proactividad
y la sinergia.
Ahora bien, puede haber muchas desviaciones de un plan de
proyecto de desarrollo de software. En estos casos, el gerente de proyecto
decide cómo manejarlas, puesto que cada retraso requiere de una acción de su
parte. Sin embargo, las opciones del gerente son muchas veces limitadas y una
de las estrategias que puede seguir es esta de la agenda iterativa. Esto
permite corregir o ajustar los planes de trabajo a medida que se desvían de las
medidas iniciales.
Por ejemplo, si una iteración toma más tiempo del
programado debido a un problema técnico que el equipo del proyecto tardó en
responder o a la toma de una decisión por parte del usuario, el gerente puede
reprogramar las iteraciones subsiguientes de tal forma que el plan original
global del proyecto no se vea afectado.
En cualquier caso, todas las formas de gestión iterativa
proporcionan una manera de:
- Integrar y validar la evolución del producto continuamente
- Demostrar progreso en cortos períodos de tiempo
- Alertar pronto al equipo del proyecto de los problemas suscitados
- Entregar funcionalidad de manera temprana
- Incorporar sistemáticamente el re-trabajo inevitable que ocurre en el desarrollo de software
En resumen, la gestión Iterativa de proyectos facilita procedimientos
para el desarrollo exitoso de aplicaciones y minimizan tanto los riesgos como
los costos, combinando técnicas de administración bien estructuradas de métodos
en cascada con técnicas de validación temprana del modelo evolutivo. Este
proceso es más adaptable a situaciones diversas en proyectos de software y da al
gerente la flexibilidad necesaria para acomodarse a un rango dinámico de
alternativas técnicas.
Información
Este artículo fue publicado originalmente por la Revista de la Asociación Española de Profesionales en Dirección de Proyectos, en marzo de 2012. Para acceder al artículo original, pueden hacer clic aquí.
viernes, junio 12, 2015
Cultura ágil y cómo escalarla: #AgilEsAlgoQueEres
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.
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.
Esta es la versión actualizada
de la presentación, como la vieron en Ágiles Colombia, en Cali, el pasado 4 de
junio:
jueves, junio 11, 2015
Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo? (V1.6.0)
El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “marcos de trabajo y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de marcos de trabajo y prácticas ágiles, según sus necesidades.
Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.
Pero, ¿cuáles son esos marcos de trabajo y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, los marcos de trabajo más usados, como Scrum, eXtreme Programming (XP), Kanban, Lean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story Mapping, Product Vision Board, User Persona, User Stories, TDD, BDD, para mencionar solo algunas.
Y lo más importante, ¿para qué sirve cada uno de estos especímenes ágiles? ¿Alguno de ellos es adecuado para el proyecto que inicio mañana? ¿Varios de estos? ¿Son complementarios? ¿Qué problemas puedo encontrar si elijo mal? Y en el fondo, ¿cuáles son las razones por las que debo permitir el nacimiento y expansión de un nuevo ecosistema aun si el actual me está rindiendo beneficios? Y hablando de utilidades, ¿cuáles puedo obtener al implementar la “agilidad” en mi Organización?
Finalmente, sabemos que los ecosistemas están gobernados principalmente por eventos estocásticos (azar), por las reacciones que estos eventos ocasionan en sus componentes y por las respuestas de los organismos a las condiciones que los rodean. ¿Cómo controlar estos eventos y sobrevivir en el intento? Una mirada Darwiniana nos ayudará a entender cómo, mediante la inspección y la adaptación, nos iremos adecuando a los cambios que ocurren en todo proceso de evolución y entenderemos que la cultura ágil es el siguiente paso en la evolución de la inteligencia.
Nota:
Esta presentación, actualizada, la hice durante el Primer Agile Open Space en la ciudad de Pasto, Colombia, el 6 de junio de 2015.
Nivel: Principiante
Título: Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?
Resumen:
Uno de los impedimentos más grandes a la hora de implementar Ágil se origina en el desconocimiento que tienen las personas sobre lo que harán a continuación. ¿Por cuál de los marcos de trabajo o prácticas empiezo? ¿Uno solo es suficiente? La respuesta corta a esta última pregunta es “no”. Entonces, ¿qué debo saber para dar el salto de aquí hasta ágil? ¿De qué me “agarro” para no caer en el abismo? Estos son los asuntos que abordaré en esta sesión introductoria.
Con definiciones simples y ejemplificadas, basado en hechos históricos de los cuales he sido protagonista, le contaré a la audiencia de qué se trata toda esta jerigonza ágil, a manera de Gazafatonario.
Esta es la presentación completa y el enlace para descargar:
domingo, mayo 31, 2015
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:
- Lidera mediante el ejemplo
- Algo de humildad siempre cae bien
- Practica la comunicación efectivamente
- Promulga y cerciórate de que las reuniones sean productivas
- Conoce bien tus limitaciones
- Encuentra un mentor, siempre hay alguien que puede enseñarte algo
- Sé emocionalmente consciente
- 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
- Aprender del pasado, sobre todo de los errores del pasado
- 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:
Suscribirse a:
Entradas (Atom)