lunes, 18 de junio de 2018

Equipo Ágil: Propósito

Un equipo sin propósito no es un equipo, es un grupo. Y un grupo no es otra cosa que un agregado de personas, no es un sistema. Y un equipo necesita ser un sistema, que tenga objetivos comunes alineados por un propósito de equipo, con identidad y sinergia. Pues, tanto un equipo como una empresa necesitan identidad, tienen que tener un objetivo global o propósito para existir. La razón de por qué hacen lo que hacen.

En general, el propósito es una misión o una meta global general que buscamos alcanzar, que nos representa y nos da una razón de ser. Es el motor motivacional y el factor cohesionador de nuestras acciones. Permite que nuestro comportamiento tenga foco y coherencia con una finalidad.

En un equipo orientado al valor y de larga vida, el trabajo a realizarse debe estar bajo la sombrilla del propósito. Si se desarrolla un proyecto, también debería estar alineado al propósito. Todo lo que no esté alineado al propósito atenta contra el foco y la eficacia del equipo. Ahora bien... ¿Cómo es la redacción de un buen propósito.

Redacción de propósito


La estructura de propósito de un equipo no difiere tanto de la de una empresa o área funcional de una empresa. Veamos algunos ejemplos de propósitos de empresas.


  • 3M: Resolver problemas sin solución de forma innovadora.
  • Cargill: Mejorar el estándar de vida alrededor del mundo.
  • Fannie Mae: Fortalecer el tejido social democratizando continuamente la propiedad de viviendas. 
  • Hewlett-Packard: Hacer contribuciones técnicas para el progreso y el bienestar de la humanidad.
  • Lost Arrow: Ser un modelo y herramienta del cambio social.
  • Pacific Theatres: Proveer un espacio para que prosperen las personas y mejore la comunidad.
  • Mary Kay: Darle oportunidades ilimitadas a las mujeres.
  • McKinsey & Company: Ayudar a que los gobiernos y corporaciones líderes del mundo tengan más éxito.
  • Merck: Proteger y mejorar la vida humana.
  • Nike: Experimentar la emoción de competir, ganar y aplastar a los competidores.
  • Sony: Experimentar la alegría de promover y aplicar la tecnología para el beneficio del público. Telecare Corporation: Ayudar a que las personas con discapacidad mental desarrollen plenamente su potencial.
  • Wal-Mart: Darle la oportunidad a la gente normal de comprar las mismas cosas que la gente rica
  • ING: Darle a la gente el poder de mantenerse un paso por delante en la vida y los negocios. Kellogg’s: Alimentar las familias para que puedan prosperar y florecer.
  • IAG: Ayudar a la gente a gestionar riesgos y a recuperarse de las penurias de pérdidas inesperadas. 
  • Walt Disney: Hacer feliz a la gente.


Si bien estos propósito son más amplios y generales, de alto nivel; podemos notar un patrón: se usa el verbo en infinitivo para denotar una acción del "qué es lo que hace". También se observa, en varios casos, a quién va dirigida la acción del "qué hace" para identificar para quién va dirigida o "quién es el cliente" o "quién es el beneficiario de la acción". Y, tal vez lo más importante o motivador, "cuál es el beneficio de la acción".

Estructura de propósito


Entonces, se puede componer un propósito de:

  1. Una acción: acción de "qué es lo que haceredactada en infinitivo (proporcionar, construir, desarrollar, ayudar, resolver, presentar, facilitar, etc.).
  2. Un cliente o beneficiario: a quién va dirigida la acción o "quién es el beneficiario de la acción".
  3. Una capacidad o competencia asociada a la acción y al "qué es lo que hace".
  4. Un beneficio: el beneficio esperado de la capacidad que recibirá el cliente o "cuál es el beneficio de la acción".


Ejemplo 1: Veamos un ejemplo con un propósito pedagógico de docentes para el plan de una materia académica:

Ejemplo 2: Propósito de una panadería y pastelería.





lunes, 4 de junio de 2018

Agile Team: Swarming work o Trabajo Enjambre

El trabajo enjambre o swarming se menciona en el contexto de Agile o Extreme Programming para indicar el trabajo en donde todos los miembros del equipo trabajan, colaborando, sobre un mismo problema o artefacto. Es decir, todo el equipo frente a una pizarra o una computadora analizando y resolviendo un solo problema, diseñando y diagramando una arquitectura, escribiendo un documento o desarrollando una sección de programa (Mob Programming). 

Scrum en Enjambre


Por ejemplo, en un equipo que trabaja bajo Scrum, todos en en el equipo trabajan en la misma historia al mismo tiempo. Es decir, todos toman una historia y se reparten trabajo de la misma historia o se enfocan en una tarea a la vez hasta que se completa, para luego pasar a la siguiente tarea, donde todos trabajan juntos en ella; así hasta completar la historia y poder pasar a la próxima. El equipo puede manejar un WIP de 1, todos en una historia y una historia por vez. Esto es particularmente importante y útil cuando un equipo recién comienza, ya sea como equipo o en un producto nuevo.


Mob Programming



Mob programming es una estrategia de programación en la que un equipo de desarrolladores trabajan sobre una única tarea al mismo tiempo, en el mismo ordenador y, sobre todo, colaborando entre ellos. Es decir, todos sentados con una computadora y en lo posible con un monitor grande, pantalla grande o proyector.

La dinámica puede consistir en que uno de los desarrolladores se encargue de liderar o “pilotar” (por 15 min. rotativo) y el resto actúe de “navegadores” o colaboradores. El piloto guía el desarrollo de la tarea, mientras el resto va opinando y dando ideas sobre la mejor forma de afrontar el código: detectando malas prácticas (smells) a tiempo, aportando posibles refactors o consideraciones de calidad y ayudando a que emerja un diseño lo mejor posible.

Puede parecer poco productivo que todo un equipo esté todo el tiempo con una tarea en una computadora, pero no es necesario que sea una práctica constante. Puede ser utilizada, por períodos de tiempo estipulados, para nivelar conocimiento en un equipo, para desarrollos de partes complejas o creativas y para diseños grupales.

Swarming work meeting

El equipo suele tener ceremonias (de Scrum, por ejemplo), reuniones técnicas o de análisis de problemas. Las reuniones en equipo altamente colaborativos, son donde participan todos, de manera equilibrada, usando un único artefacto que posibilite la colaboración (como una pizarra, herramienta de colaboración, lámina canvas, etc.) pueden ser llamadas "swarming work meeting".


El equipo de Dr. House haciendo swarming.

Las herramientas digitales que favorecen el swarming son Google Drive, herramientas de texto por código (como LaTeX, etc), pizarras digitales, herramientas de diseño y diagramación colaborativas, herramientas de votación colaborativas, etc.


Referencias:


lunes, 28 de mayo de 2018

Agile team: El rol Iteration Manager

El rol Iteration Manager



El Iteration Manager (IM) es un Facilitador del Delivery que vela por que el equipo tenga todas las capacidades para entregar el mejor valor posible. En resumen, es una función dentro de los equipos de desarrollo Agile que se enfoca internamente en el equipo, facilitador de equipo, y en la facilitación del proceso de desarrollo y de entrega. Es un rol que algunas empresas usan como abstracción del rol de Scrum Master (de Scrum) y de Flow Master (del método Kanban). El Iteration Manager busca lograr que su equipo logre ser un equipo ágil de alto desempeño y que mejore continuamente.




Referencias:


domingo, 6 de mayo de 2018

Escalamiento: PODAC

Principios PODAC


A la hora de organizar una empresa ágil nos encontramos con algunos interrogantes: ¿Cómo nos podemos organizar y formar equipos? ¿Qué diferentes opciones estructurales tenemos? Si bien tenemos diferentes framework y modelos de escalamiento como: Modelo Spotify, Nexus, Scrum@Scale, SAFe Scaled Agile Framework, Large-Scale Scrum (LeSS) y The Disciplined Agile (DA) Framework, entre otros; tenemos la dificultad de evaluarlos y adaptarlos a nuestra realidad. La mayoría de los framework están pensados para escalar de abajo hacia arriba o como modelo completo de organización. Pienso que en vez de evaluar un marco de escalamiento y elegir uno, es más importante preguntarse: ¿Qué principios de diseño podemos seguir? o sea... ¿Qué principios de diseño organizacional para una empresa ágil nos puede guiar para reestructurar la compañía?Aquí propongo utilizar los principios PODAC (Principles of Organizational Design for an Agile Company):

  1. Eficacia sobre eficiencia (outcome sobre output).
  2. Negocio y tecnología trabajan juntos.
  3. Alineamiento.
  4. Control descentralizado.
  5. Organizando por valor del cliente. 
  6. Basado en equipos orientados por valor.
  7. Alta cohesión y bajo acoplamiento.
  8. Usar patrones de escalamiento según necesidad.


jueves, 7 de diciembre de 2017

Modelo Spotify: Guild (Comunidad)

La comunidad


Aunque la traducción que se suele hacer de Guild es gremio, prefiero llamarlo "Comunidad". En el modelo Spotify, un Guild es una "comunidad" de interés, orgánica y de amplio alcance. Es una organización de personas que quieren compartir conocimientos, buenas prácticas, herramientas, códigos, iniciativas e ideas, generar capacitaciones, organizar code katas/hackathons, organizar eventos en pos de la misión, ayudar en la construcción de estándares comunes y acuerdos organizacionales. Serían como las "comunidades de práctica" o los grupos de aprendizaje, no necesariamente están en el mismo área de competencia pero mantienen intereses comunes. Una comunidad normalmente no pertenece a una tribu en particular, sinó que recorre toda la organización. Y se reuninen exporádicamente o periódicamente, con cierta regularidad, sin ser un equipo fijo ni una estructura formal de la organización. La vida o disolución de una comunidad depende de la participación, cohesión y motivación de sus miembros.


Líder de la comunidad 


Es aconsejable que la comunidad tenga al menos un líder que sea responsable (pueden ser más de uno). Esto hace que sea más fácil seguir el progreso hacia la misión de la comunidad. El líder no es un cargo formal, sino un rol. Tanto la participación, como líder o como miembro, es voluntaria. Hay que tener en cuenta que el líder de comunidad debe ser un líder servicial, quien sostiene la misión y la visión de las respectivas competencias de la comunidad y quien facilita su funcionamiento. También es deseable que el líder sea alguien proactivo y/o un agente de cambio, ya que la comunidad funciona también como mecanismo de mejora continua para hacer aportes de mejora a la organización, generar ideas o liderar alguna innovación. Las principales funciones de un líder de comunidad son:

  • Convocar a las personas. 
  • Agendar las citas y reservar salas.
  • Permitir y promover que personas de diferentes equipos se reúnan de manera fluida y colaboren en un propósito compartido. 
  • Facilitar y/o moderar las reuniones. 
  • Encargarse de alguna administración mínima (seguimiento de temas). 
  • Coordinar a las personas o miembros para que se realicen las reuniones. 
  • Asegurarse que la comunidad tenga una misión clara y visible para todos. 
  • Asegurarse y promover que sea valiosa para los miembros y la organización. 
  • Facilitar puentes o medios de comunicación. 
  • Fomentar y usar prácticas ágiles (como uso de backlog, kanban boards, retrospectivas, etc.).
  • Delegar y generar trabajo en equipo. No debe ser un cuello de botella ni un acaparador. Debe fomentar el trabajo distribuido, colaborativo y formar otros líderes. Debe lograr que la comunidad pueda llegar a funcionar y existir sin él.
  • Germinar una comunidad si ve la necesidad en la organización.

Germinar una Comunidad


Para hacer nacer una comunidad se necesita crear un ambiente abierto y acogedor. No intente estructurarlos o hacerlos excesivamente formales; en principio, deberían ser entidades autónomas, orgánicas, que prácticamente carecen de jerarquía. Una de las mejores cosas acerca de la vida de las comunidades es que serán evaluadas por su comunidad de ingenieros o colegas, por lo que, tan pronto como una deje de cumplir una función, se vuelva redundante o no necesaria, naturalmente se desvanecerá. O también puede ser absorbida por otra comunidad. Es aconsejable que al momento de formación se defina un propósito y/o misión y se de a conocer al resto, invitando a los integrantes de la organización a participar de forma abierta. Preferentemente es bueno comenzar con alguna lista de temas de interés priorizada, acuerdos de trabajo y herramientas colaborativas a usar.

Ejemplos 


Las comunidades pueden ser por capas tecnológicas de desarrollo o especialidad como: Backend Guild, Frontend Guild, QA Guild, UX Guild, DevOps Guild, Iteration Manager Guild (Team Facilitator), Product Owner Guild, Agile Management Guild, etcétera. También por lenguajes: Javascript Guild, Java Guild, etcétera. Por tecnología o prácticas: Continuous Integration, Machine Learning, etc.

Ejemplo de una declaración de comunidad:

Comunidad de Iteration Managers


  • Propósito: Reunir a Facilitadores de Equipos, Iteration Managers y Scrum Masters para capacitarnos y desarrollar mejor el perfil profesional a través de la discusión y el intercambio de conocimientos. Alternamos entre talleres en los que pasamos la hora aprendiendo una habilidad, dinámica o técnica, reuniones regulares donde presentamos lo que hemos estado haciendo y discutimos ideas (sobre métricas, buenas prácticas, calidad, procesos, agilidad, estándares, etc.) para mejorar nuestros procesos de trabajo y empujar la transformación ágil.
  • Mission: Empoderar a los IM para ser agentes de cambio y mejorar nuestra organización y trabajo de los equipos.
  • Objetivos: Compartir conocimiento, prácticas e ideas. Generar iniciativas de mejoras. Unificar criterios y generar acuerdos. Influir en el cambio cultural de la organización hacia una cultura ágil.
  • Métricas: Tener una presentación al menos una vez al mes. Generar al menos una iniciativa mensual. Celebramos algun logro de la comunidad mensualmente.
  • Agenda: Nos reunimos en la sala desiganad de 16:00 a 17:00 cada martes.
  • Herramientas: usamos Trello (Jira, Google Drive, etc.) para administrar nuestro backlog de temas e iniciativas.



Referencias



viernes, 23 de junio de 2017

Movimiento Ágil: los 4 aspectos claves de la agilidad empresarial



Hoy en día, la agilidad se transformó en un movimiento más allá de Ingeniería de Software y área de producción. En este sentido, el Manifiesto Ágil ya ha quedado algo obsoleto, pero no así su esencia, su corazón. El núcleo esencial ágil se sintetiza en cuatro aspectos claves que pueden aplicarse y guiar las prácticas de cualquier disciplina o proyecto de componente intelectual en cualquier organización empresarial o Sistema Social Empresarial. En el siguiente video esquematizo estas cuatro claves que considero conforma el espíritu del movimiento.






Tengo que recalcar que no inventé nada nuevo. Esto es simplemente la síntesis (que cualquiera puede hacer) del Manifiesto Ágil y la literatura al respecto que fluye en el movimiento ágil. No obstante hace poco rescaté un fragmento de video de Ángel Medinilla, en un meetup de Agilidad y escala, donde sintetiza la agilidad en estos cuatro aspectos claves con los que estoy totalmente de acuerdo y que me alegra que haya alguien que profese lo mismo. Siempre consideré que el movimiento ágil, tanto en la industria de software como en cualquier ámbito empresarial, se resume a estos cuatro aspectos esenciales. El manifiesto ágil está orientado solo al desarrollo de software y por esa razón considero que está algo obsoleto, por lo que algunos intentan brindar alguna otra fórmula valorativa alternativa, como "Modern Agile" o "Heart of Agile", sin embargo pienso que esas ideas no engloban realmente la esencia ágil, no guardan el verdadero espíritu ágil. Y viendo a Ángel encontré, por fin, a alguien que resume tan bien la agilidad y que está en sintonía con algo que hace años vengo fomentando, y es que: estos cuatro aspectos valorativos pueden emplearse en cualquier sistema social empresarial y es lo que constituye el corazón del movimiento ágil.

A continuación comparto el video:



Referencias:

  1. Manifiesto por el Desarrollo Ágil de Software: http://agilemanifesto.org/iso/es/manifesto.html
  2. Ángel Medinilla, meetup agilidad a escala: Conversatorio con Ángel Medinilla sobre Agilidad a escala, incluyendo experiencias reales de los asistentes y perspectivas sobre los marcos de trabajo más conocidos (SAFe, LeSS, Nexus...).





domingo, 7 de mayo de 2017

Valores ágiles: Mandala Ágil

En estos días (primera semana de Mayo 2017) asistí al Agile Open Camp de Chile 2017. Es un evento diferente, con energía, buena onda y muchas conversaciones interesantes. Fue un espacio para compartir y generar semillas para nuevas ideas.

En algunas charlas interesantes sobre la vigencia del “Manifiesto Ágil” y sus posibles actualizaciones con generalizaciones y simplificaciones, surgieron debates sobre “Modern Agile”, “Heart of Agile” (de Alistair Cockburn) y como se podría mejorar la forma de presentar el Manifiesto Ágil. A mi no me convencía la propuesta de “Modern Agile”, con el agregado que hace de la seguridad como requisito (“Make Safety a Prerequisite”) ni tampoco me cerraba la simplificación propuesta con el “Heart of Agile” con dos incisos muy relacionados como la reflexión y la mejora continua, pero mostrados separados. En consecuencia pensé en hacer una síntesis.

La idea es que la agilidad se ha vuelto excesivamente decorada y el manifiesto, hasta cierto punto, tiene muchos incisos (4 valores y 12 principios) como para ser aprendido fácilmente. Además fue concebido para el desarrollo de software, específicamente, y no para cualquier organización.

Algunas preguntas que me resonaban en esos días fueron… ¿Qué podemos enfatizar para volver al corazón de la agilidad y reinterpretar al manifiesto ágil rescatando lo esencial? ¿Cómo mostrar el corazón de la agilidad de una forma didáctica y simple? 

Respondiendo a estas preguntas, pienso que es bueno tener un mandala, como un escudo, que resuma algunos conceptos claves de la agilidad, sin perder nada del manifiesto. Cuando terminaba el evento “Agile Open Camp” hice un borrador de lo que para mí podría ser un buen mandala (con forma escudo) que muestra cuatro conceptos clave, que cohesionan a los 4 valores y 12 principio. El dibujo que hice (con sharpie en hoja A4) es el siguiente:


Los conceptos clave son:
  1. Collaboration
  2. Delivery (Value Flow)
  3. Adaptation
  4. Improvement

Estos conceptos contemplan a los valores y principios ágiles como comento a continuación:
  1. Factor humano (Colaboración): este concepto abarca a la priorización de "individuos e interacciones sobre procesos y herramientas" y a la "colaboración con el cliente sobre negociación contractual". Ambos valores son necesarios para lograr la colaboración. También sostiene al principio que dice que "los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.". Además para lograr mejorar la colaboración, y con ella un equipo de alto desempeño de trabajo sostenibe, es necesario lograr individuos motivados. La colaboración se da en procesos de autoorganización. Y finalmente para promover la colaboración se prioriza y fomenta la conversación cara a cara y el fortalecimiento de las relaciones humanas dentro de la organización.
  2. Flujo de valor (Entrega): esta es una idea pragmática de operatibilidad. Abarca a "Software funcionando sobre documentación extensiva" donde se amplía a producto funcionando como foco principal por sobre documentación excesiva (de esta manera no se limita a solo software). Se tiene como prioridad satisfacer a nuestros clientes mediante la entrega temprana y continua de un servicio o producto con valor. Las entregas de valor deben ser frecuentes, con preferencia al periodo de tiempo más corto posible. Que las cosas funciones, nuestros productos y servicios, es la medida principal de éxito y progreso.
  3. Adaptación: este abarca a la "Respuesta ante el cambio sobre seguir un plan". Los procesos Ágiles promueven el desarrollo sostenible mediante ciclos de retroalimentación y auto-regulación para manejar el cambio de requisitos y el entorno cambiante. Se busca la adaptabilidad en un proceso sostenible con procesos de auto-ajustar el comportamiento según el contexto cambiante y el continuo feedback del cliente y usuario.
  4. Mejora continua: este concepto incluye la búsqueda de la excelencia, mediante la mejora contínua con etapas de reflexión y acción. También incluye a la simplicidad, como parte de la búsqueda de excelencia, además de que es parte de la ciencia y de la ingeniería.

Pienso que esta síntesis es una buena herramienta visual y conceptual para enseñar agilidad. Recordar estas cuatro ideas se hace muy simple, más si mantenemos visible el mandala en nuestro lugar de trabajo.

El equipo de participantes del AOC...

Referencias: