#ConversaAgil, Latinoamérica unida en la Agilidad

Media_httpwwwthecreat_axzxa

“Nunca dudes que un pequeño grupo de personas comprometidas puedan cambiar el mundo. En efecto, es lo único que lo ha logrado” – Margaret Mead 

Hoy en la tarde participé de una experiencia fantástica. 


Agilistas de Venezuela, Chile, Colombia, Perú y Ecuador participando con sus tweets en el primer ConversaAgil; una simple pero poderosa iniciativa diseñada para compartir experiencias acerca de Agile y conversar sobre un tema específico propuesto; en esta ocasión “Técnicas ágiles aplicadas a proyectos que no son de software”. 

 

#ConversaAgil se asemeja a un OpenSpace habilitado sobre Twitter (algo como un TOS: Twitter Open Space) en el cual todos los participantes compartieron sus tweets llenos de valiosos aportes, links y consejos. Es un espacio para conocer y exponer puntos de vista sobre una problemática ágil y al mismo tiempo fortalecer las relaciones entre amigos agilistas de la región, que aunque no nos conocemos personalmente, compartimos este gran espíritu ágil y las ganas de ayudar. 

 

Todavía hay cosas por mejorar, pero para ser el primer intento, salió genial!! Pronto llevaremos a cabo otro #ConversaAgil. 

 

Gracias Gustavo Bonalde e Irwin José Franco por hacerme parte de esta maravillosa idea; un gusto colaborar con Ustedes. 

 

Saludos!

Anuncios

Pensadores y Hacedores: Pensando en la Altitud

Hace pocos días leí un gran artículo denominado Pensadores y Hacedores redactado por Francisco Sáez (@franciscojsaez), fundador y CEO de FacileThings. Francisco comenta acerca de la disposición de las personas en dos grupos: los “thinkers” y los “doers” y resalta las características de cada uno. Siendo ambos importantes para una organización, Francisco sugiere la búsqueda de un equilibrio en el cual se rescaten las cualidades de cada personalidad con el fin de lograr un objetivo.

Yo me sentí realmente identificado, ya que en ese preciso día había tenido feedback por parte los miembros de mi equipo con respecto a que sólo pasaba pensando y no haciendo. Esto no quiere decir que para hacer algo no haya que pensar, sino más bien, que me pasaba soñando mucho y pensando en estrategias en lugar de ayudar a cristalizarlas. Al sentirme así, mi comentario fue el siguiente:

Mi_comentario

Al día siguiente Gorky Estrella también comentó al respecto:

Comentario_de_gorky

Gorky es un gran compañero y amigo, y junto a Mercy formamos este pequeño equipo lleno de ilusiones y ganas por hacer cosas geniales. Entenderán entonces su comentario, estaba enojado conmigo.

Reflexionando sobre el tema pensaba que el problema de los thinkers es que pasan (o en este caso pasamos) mucho tiempo en las nubes. En cambio, el problema de los hacedores es que se concentran tanto en el cómo hacerlo que se sumergen mucho en los detalles. Esto puede ser expresado con una cuestión de Altitud. Qué significa??.

Al pensar en nubes y en inmersión recordé un slide de una presentación de Jeff Patton (@jeffpatton) con la que ilustra que una definición de tarea de usuario o construcción de UX es sensible a la altitud en la que nos encontramos al momento de diseñarla.

Niveles

Adentrándome un poco al desarrollo de SW, si el nivel de altitud es demasiado alto nos arriesgamos a un Big Design Up Front, en donde comencemos a pensar y a diseñar cientos de cosas, una arquitectura súper completa adaptable a todos los escenarios imaginables y que permita satisfacer todas las necesidades del usuario incluso las que todavía no tiene. Por otro lado, si el nivel es demasiado bajo, estaremos tan pendientes de los detalles de implementación: el objeto, la clase, el algoritmo, etc., que perderemos fácilmente la visión del para qué estamos construyendo esta funcionalidad o qué necesidad del usuario satisface. Tal como concluye Jeff Patton, es necesario que exista un balance, es decir; encontrar un punto medio que permita abstraer de forma más real e idónea una necesidad de negocio o el mismo UX.

Jeff_patton

Es evidente que en este punto medio se encontrarán las habilidades y fortalezas de Thinkers y Doers, trabajando juntos para alcanzar la meta: hacer brillar a nuestro cliente de felicidad. Esto no quiere decir que se deba permanecer siempre a nivel del mar. Seguramente nos adentraremos en los detalles y resolver el cómo realizarlo. De igual forma, es necesario subir y abstraer e imaginar nuevos escenarios y oportunidades. Ubicarnos entre el nivel de la cometa y el nivel del mar es el punto de partida que nos permitirá enfocarnos hacia una apreciación adecuada y hacia un trabajo dirigido hacia el usuario.

Thinkers y Doers: mismo equipo, misma meta!.

PD: Estimado Gorky, por favor tenme paciencia 🙂

Formando un equipo ágil

Luego de recibir un curso, charla o seminario de Agile o Scrum se genera un gran entusiasmo al conocer una nueva forma de crear software, un conjunto de nuevos principios y sobretodo al descubrir los muchos beneficios que la agilidad brinda sobre el enfoque de desarrollo tradicional. La energía crece al saber que Agile o Scrum no son las metodologías o frameworks de moda, sino más bien un movimiento que está empujando a la industria del software y a otras hacia nuevas direcciones en las que se garantiza productos de calidad y clientes deleitados (algunas estadísticas #mce_temp_url#).

Como resultado del estusiasmo, al siguiente día la oficina luce paredes llenas de post-its, varios StoryBoards y compañeros de pie ensayando su primer Stand-Up meeting. Toda esta buena energía es positiva, sin embargo debe ser correctamente canalizada. En el proceso de adopción de Agile muchas organizaciones comienzan velozmente al aplicar las prácticas sin tomar mucha atención en la interiorización de los valores Agile. Generalmente todos desean aplicar Scrum pero no se tiene un inicio claro del qué vamos a hacer, porqué o para quién.

En mi experiencia al comenzar a plasmar los conceptos de la agilidad, he resumido unos pocos pasos que están dando buenos resultados en el proceso de adopción en la empresa en la que trabajo y que deseo compartir:

1. Full Empowerment: contar con el respaldo total por parte de la organización (o instancias superiores) acerca del proceso de adopción de una práctica ágil como Scrum para el desarrollo; la organización debe estar convencida de los beneficios que brindará sobre la manera de crear software. Agile implica muchos cambios a nivel cultural y de procesos que deben ser auspiciados por la empresa. Este respaldo es importante ya que brindará autonomía al equipo y le dará espacios transparentes para la toma de decisiones. La difusión del inicio del proceso como un programa piloto es parte de este punto. Si Usted es un emprededor ágil debe comenzar a “vender” y generar confianza en los directivos de su organización.

2. Invitación a participar a las personas que lo deseen: Identificar e invitar a las personas que posean los perfiles apropiados, talentos y habilidades pero por sobretodo, estén con muchas ganas y entusiasmo de comenzar con Agile. Que su forma de pensar y de actuar sea de cierta forma coherente con los valores y principios de la agilidad y que estén deseosos de aprender y mejorar. A mi forma de pensar, pesan más las ganas, la capacidad de aprender, desaprender y reaprender por sobre el badaje técnico que se pueda tener.

 3. Identidad: Cuando propuse este punto como parte del inicio de un equipo, muchos me preguntaron…para qué?. El sentido de identidad va más allá de un nombre para el equipo, consiste en brindar un sentido de pertenencia, unión y colaboración entre las personas que conforman el equipo. Identidad la entiendo como la definición de un nombre, valores, principios y acuerdos que constituyen la cultura del equipo y rigen su comportamiento. La siguiente pregunta fue: pero…no son los mismos valores y principios del Agile Manifesto??. Mi respuesta fue: hagamos de este equipo nuestro equipo y que represente lo que somos y lo que hacemos. La definición de la identidad es la primera reunión del nuevo equipo -nada formal-, donde todos aportan efusivamente y se llega a los primeros acuerdos. Cada nuevo miembro del equipo debe estar de acuerdo y comprometerse con lo acordado.

24012012885

 

13012012842

4. Lenguaje común: consiste en el manejo homogéneo de conceptos, términos y prácticas -tanto técnicas, tecnológicas, procedimentales y de agilidad- de los miembros del equipo; no necesariamente con gran nivel de profundidad o un manejo experto de cada tema; pero si una visión y comprensión de los conceptos que usará el equipo. Durante mi experiencia en este punto, se organizaron varias charlas informarles entre los miembros del equipo (no más de 40 minutos entre contenido y preguntas), en donde todos propusimos temas en los cuales se tenía ciertas dudas, deficiencias o simplemente temas que se querían conocer; además de los que todos considerábamos importantes antes de iniciar. Fue un proceso de aprendizaje bastante satisfactorio, ya que los que más conocían acerca de algo compartían su experiencia con los demás miembros. Se hicieron breves Coding-Dojos y talleres altamente participativos. En muchas literaturas se denomina a este punto como Iteración 0, sin embargo pienso que más que una evaluación de nuestra habilidad con herramientas y tecnologías, la formación de un Lenguaje común es un elemento que involucra otros aspectos y que no necesariamente están dentro del contexto de adquirir o conocer nuestro Velocity.

2301201287723012012878

5. Envisionamiento del Producto: Okay, es aquí donde comenzamos a vivir más intesamente la agilidad. Básicamente la definición del qué vamos a hacer, el porqué y para quién se realiza en este punto. Qué es lo que vamos a lograr como equipo. Es la definición del norte acerca del producto que se desea construir. Como todos sabemos, en Scrum es el Product Owner quién acerca la idea al DevTeam a través del Product Backlog. Es vital contar un PO con las características adecuadas y el conocimiento que dirigirá el esfuerzo del equipo de desarrollo. El PO motiva al equipo. Su Product Backlog lo reta constantemente y le inyecta dinamismo. Si no se cuenta con un PO lo más recomendable para mí es emprender un proyecto al interior de la misma empresa, alguna solución que agregue valor en donde nuestros compañeros más conocedores del negocio al cual se quiere ayudar, nos entregue su enfoque de producto sin ser necesariamente un PO, podemos involucrarlos y juntos con el equipo emprender un proceso de discovering y crear una visión de producto compartida, en la cual poco a poco se vayan abordando prácticas como el Visual story Mapping con la participación y el conocimiento de todos.

6. Requisitos Operacionales: consiste en la definición de aspectos importantes para el desempeño diario del equipo:

  • Common workspace: Importantísimo. un ambiente de trabajo que fomente la colaboración, comunicación y comodidad del equipo, facilite las Daily Meettings y otras reuniones, se puedan ubicar StoryBoards, etc.
  • PCs, networking, ambientes de desarrollo, pruebas de usuario o de review, servidor de integración continua, herramientas de colaboración y comunicación.
  • DevOps: el primer acercamiento del equipo de infraestructura hacia la agilidad. El concepto de DevOps es acercar al equipo de desarrollo con el de infraestructura-operaciones de la compañía. Estos dos mundos que siempre han estado separados, ahora trabajan junto con el DevTeam para realizar una exitosa entrega continua. Las tareas de Configuration Management, Versionamiento y otras son manejadas en este contexto. Por lo general en equipos o empresas pequeñas estas tareas son manejadas por el mismo DevTeam, sin embargo cuando existen muchos proyectos o se requiere colocar entregables en ambientes de producción de ciertos clientes estas operaciones conjuntas son necesarias (hablaré más de DevOps en un siguiente post más adelante).

7. Y…creo que estamos listos para emprezar!!

Estos pasos no son una guía formal o rígida (tanto en el orden como en la forma de abordar cada punto). Crear un equipo ágil depende mucho del contexto de la empresa, las personas y de los productos a construir; pero espero que en un sentido general estos pasos sirvan de utilidad para aquellos que desean comenzar firmente el camino hacia la agilidad y hacia un crecimiento personal y profesional. Me gustaría conocer sus comentarios y/o sugerencias al respecto. No olvidemos que Agile involucra un aprendizaje continuo.

Muchos saludos.

Al aplicar Scrum ya somos ágiles?? Podemos ser ágiles sin aplicar Scrum?

Hace poco en la oficina participé en un breve debate acerca de Scrum y Agile, y me parece bastante valioso comentar al respecto. El punto en discusión es: si aplicando Scrum ya podemos decir que somos ágiles??. Y otro punto interesante es: podemos ser ágiles sin aplicar Scrum??.

Con la aparición de la revolución Agile han nacido y siguen naciendo “prácticas” o frameworks de trabajo que tratan de adaptarse y ser compatibles con la filosofía Agile: Scrum, Kanban, Scrumban, ScrumFall, Scragilefall, Waterscrum, Wagile, Agile PMI, MSF 5 o Agile MSF, etc.

 

Mi punto de vista al respecto es: Agile no es una metodología o conjunto de metodologías, agile es una “cultura” basada en valores y principios, una forma de pensar y actuar. Scrum es un marco de trabajo en cuyas prácticas es compatible en alta medida con los valores de la agilidad y del agile manifesto. 

 

Al aplicar Scrum ya somos ágiles? No. No se trata de pegar Post-its, tener un StoryBoard y reunirnos todos los días para decir que ya somos ágiles. Si no se respetan y siguen los valores de la agilidad simplemente estamos ensuciando la pared y muchas ocasiones perdemos el tiempo en reuniones que no persiguen los objetivos del equipo, el producto y de la agilidad como tal. La mayoría de empresas fracasan en la adopción de Agile precisamente porque comienzan apresuradamente a seguir un framework pero sin entender los valores de la agilidad.

 

Podemos ser ágiles sin aplicar Scrum?? Sí podemos. Si comprendemos el espíritu de Agile, respetamos los valores, practicamos los principios y somos coherentes con la forma de pensar Agile, podemos aplicar acciones compatibles -que ni siquiera pueden estar consideradas como metodologías- pero que agregan un altísimo valor al equipo, al producto y a la organización. La metodología a aplicar depende mucho del contexto de la empresa, las personas y el producto. La agilidad permite tener tu propia metodología, pero si esta no respeta los valores Agile no podremos decir que somo ágiles (por más obvio que parezca). Más del 75% de los proyectos ágiles usan Scrum ya que su simplicidad y flexibilidad ayuda al equipo a integrarse a esta nueva forma de pensar y de actuar. Con el tiempo y con un gran velocity, muchas veces se pasan a Kanban u otras más rigurosas gracias a la experiencia ganada.

 

Para terminar: 

 

1. Hay que tener muy claro los conceptos en cuanto a Agile, comprenderlos e interiorizarlos; y entender también la diferencia con Scrum. 

 

2. Hay que tener cuidado en las múltiples propuestas de proveedores, empresas, herramientas o incluso nosotros al proponer nuevos frameworks de trabajo o adaptarlos. Si estos no respetan los valores de la agilidad o son incompatibles (como por ejemplo: que el Scrum Master es el Agile PM, o usar horas/hombre para la estimación, etc), deberán ser evaluadas y re-adaptadas.

 

Coloco aquí algunos links interesantes de los expertos con referencia al tema. Espero sus comentarios sobre este mi primer post. Gracias 🙂

 

http://www.telerik.com/agile-project-management-tools/blogs/…
http://scrumcoaching.wordpress.com/2011/06/12/…
http://www.planbox.com/blog/news/updates/agile-is-evolving-not-declining.html ​ 
http://scrumology.com/guest-post-scrum-is-the-vehicle-not-the-destination/?utm_source=dlvr.it&utm_medium=twitter