El Product Owner debe ser un arquitecto?

La semana anterior conversaba acerca del tema a través de twitter  con un amigo agilista de Ecuador. Cuando él propuso esto, lo debatí fuertemente; ya que para este momento no concebía que un arquitecto de software pueda llevar la gran responsabilidad del PO. Mi temor estaba orientado a que podría dársele más énfasis a aspectos técnicos y tecnológicos que a satisfacer las necesidades funcionales y expectativas de negocio de nuestro cliente. Al final del día, no importa mucho si lo haces con .NET o Java, 3 capas o cliente-servidor, si el producto no es de calidad (según mi visión de calidad basado en el modelo Kano), sino representa utilidad para el negocio y las funciones diarias del cliente; sino deleita.

Durante esta semana (y mientras escribo este post) tuve la oportunidad de participar en un curso de arquitectura basado en la visión del IASA. He descubierto que estaba muy sesgado acerca del rol de un buen arquitecto de TI y un buen arquitecto de software, comprendiendo que un buen arquitecto buscar solucionar problemas de negocio apalancado en tecnología, algo fácil de decir pero muy complicado

Anuncios

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