Ant Hill
Un framework para generar feedback loops orientados a la aportaci贸n continua de valor
Pilares
Ant Hill se basa en la teor铆a de control emp铆rico de procesos.
Como organizaci贸n solo conocemos aquello que ha pasado y solo podemos tratar de predecir aquello que ocurrir谩.
Por ello, nuestros pilares son la Transparencia, la Inspecci贸n y la Adaptaci贸n, tanto de nuestros productos y servicios como de nuestra forma de ser y hacer.
Premisas
- Nuestra prioridad es satisfacer las necesidades de nuestros usuarios a trav茅s de la utilizaci贸n de productos y el consumo de servicios de calidad. Los planes de entrega y manuales, por s铆 mismos, no logran este objetivo.
- Creemos que los equipos de alto rendimiento emergen desde la autonom铆a para decidir c贸mo quieren trabajar y el empoderamiento suficiente para poder comprometerse con la entrega de valor.
- Tenemos derecho a fallar, es el camino para abordar la incertidumbre, pero tenemos la responsabilidad de hacerlo en el menor tiempo posible y con la menor cantidad de recursos disponibles.
Roles
Key Stakeholder
Los Key Stakeholder son l铆deres al servicio de la organizaci贸n, comprometidos con la autonom铆a de los equipos y la entrega de valor.
Nuestra m谩xima prioridad, como Key Stakeholder, es entender las necesidades de nuestros clientes y usuarios, internos o externos, y trasladarlas de forma clara y expl铆cita a todos los integrantes de nuestra organizaci贸n.
Definimos en Epopeyas las l铆neas de trabajo que cubren las necesidades detectadas, dejando espacio para decidir 驴Qu茅 contiene la soluci贸n? por parte de los Owners y 驴C贸mo se lleva a cabo? por parte de los equipos de desarrollo.
Team
El Equipo o Team, es el encargado de materializar soluciones para las necesidades detectadas dentro de la organizaci贸n. Esta responsabilidad es compartida por todos los miembros del equipo.
El equipo es autosuficiente, crossfuncional y autoorganizado para definir c贸mo quieren trabajar con el prop贸sito de alcanzar las Epopeyas. Para ello, deber谩 disponer de conocimiento t谩ctico como estrat茅gico.
En relaci贸n a su 谩rea de especializaci贸n y empoderamiento, dentro de cada equipo podremos identificar tanto el rol de Owner como el de Desarrollador.
Owner
La misi贸n del Owner es maximizar el valor del producto y la calidad del servicio desarrollado por el Team.
El Owner debe estar empoderado para establecer los criterios de valor que considere aplicables para avanzar a trav茅s de las Epopeyas de los Key Stakeholders.
Al Owner le pertenece la capacidad de establecer a trav茅s del Backlog qu茅 necesidades hay que satisfacer
Se recomienda que el rol est茅 identificado en un solo miembro del equipo para evitar desperdicios relacionados con los canales de comunicaci贸n y con los conflictos que puedan suceder al establecer criterios de valor al ordenar el backlog.
Development Team
La misi贸n del Equipo de Desarrollo o Development Team es satisfacer las necesidades de nuestros clientes y usuarios a trav茅s de la entrega continua y frecuente de servicios de calidad y productos de valor.
El Equipo de Desarrollo tiene la capacidad de establecer c贸mo satisfacer las necesidades de los usuarios
Artefactos
Epopeyas
Son grandes l铆neas de trabajo estrat茅gicas, establecidas por los Key Stakeholders, que deben recoger de forma clara y expl铆cita las necesidades de nuestros clientes, englobando el conocimiento actual y el retorno esperado con su ejecuci贸n.
Las Epopeyas son artefactos vivos cuya naturaleza y alcance puede variar durante su desarrollo , usualmente est谩n vinculadas a hip贸tesis de negocio.
Backlog
El Backlog es un listado ordenado de necesidades que deben ser cubiertas para satisfacer a un usuario.
Puede estar compuesto por 茅picas, Historias de Usuario, Spikes, Tickets o cualquier otra t茅cnica o medio que permita al equipo establecer un entendimiento com煤n y compartido sobre lo que debe contener un producto o entregarse en un servicio.
El Backlog debe estar ordenado por el criterio que los Owners consideren oportuno para maximizar el valor de su producto o servicio.
Eventos
Respetando los eventos o feedback loops que establezcan los equipos en su forma de trabajar, se establecen como necesarios los siguientes eventos.
Todos los eventos respetan el concepto de Timebox.
El Timebox (caja de tiempo) es una t茅cnica para limitar la duraci贸n de una reuni贸n o evento. Una vez alcanzado el prop贸sito del evento o superado el tiempo establecido y conocido por todos los asistentes, el evento en curso debe finalizar.
Iteraci贸n
La iteraci贸n es el contenedor de los dem谩s eventos que se describir谩n a continuaci贸n.
Cada iteraci贸n comienza con la inspecci贸n de necesidades a cubrir durante el periodo, transcurre con su desarrollo en base a planes flexibles y finaliza con la obtenci贸n del feedback sobre el valor entregado durante la iteraci贸n y la inspecci贸n y adaptaci贸n de la forma de trabajar de la organizaci贸n.
Una iteraci贸n tiene un timebox de 2 meses como m谩ximo y al finalizar la vigente comienza otra de la misma duraci贸n.
Big Planning
Timebox: 8 horas para ciclos bimestrales.
Invitados: Los Owners de cada equipo junto con los Key Stakeholders.
Cada Owner tiene la posibilidad de invitar a miembros de sus equipos que consideren relevantes para cumplir con el prop贸sito de la sesi贸n.
Prop贸sito: Inspeccionar las Epopeyas, ordenarlas en funci贸n del valor que pueden aportar, desagregarse en 脡picas, detectar dependencias y proceder a su refinamiento e incorporaci贸n al Backlog de cada equipo.
Big Review
Timebox: 4 horas para ciclos bimestrales.
Invitados: Los Owners, el Development Team y los Key Stakeholders
Prop贸sito: Inspeccionar la entrega de valor realizada durante la iteraci贸n por cada uno de los equipos en base a las Epopeyas.
Big Retrospective
Timebox: 3 horas para ciclos bimestrales.
Invitados: Los Owners, los Equipos y los Key Stakeholders
Prop贸sito: Inspeccionar y adaptar la forma de trabajar de los equipos en base a la experiencia adquirida durante la iteraci贸n. Compartir buenas pr谩cticas e inspeccionar v铆as para subsanar bloqueos recurrentes. Al menos una acci贸n de mejora debe proponerse y probarse durante la siguiente iteraci贸n que beneficie a la mayor parte de equipos.
Actividades
Asimismo, junto con los eventos, hay dos actividades enmarcadas dentro del framework que son realizadas a petici贸n de los Development Team, los Owners o los Key Stakeholders:
Refinamientos
Durante esta actividad los Key Stakeholder refinan, clarifican y a帽aden detalle a las Epopeyas junto con los Equipos para trasladar la necesidad existente y la gesti贸n de expectativas sobre el valor esperado.
Escalado de Bloqueos
Cada Equipo junto con los Key Stakeholders determinan las v铆as para el escalado de Bloqueos y los protocolos para su subsanaci贸n.
Se entiende por Bloqueo todo aquel impedimento que no puede resolver el Equipo por s铆 mismo.
Los bloqueos recurrentes deben ser tratados como puntos de mejora, cada equipo velar谩 por la inspecci贸n y adaptaci贸n de acciones para su reducci贸n o eliminaci贸n.
Las acciones de mejora realizadas en una iteraci贸n pueden ser objeto de inspecci贸n a trav茅s de la Big Retrospective.
Comunidad de Pr谩cticas
Con el fin de fomentar la auto-organizaci贸n, el desarrollo y la difusi贸n de conocimientos orientados a las necesidades de los productos y servicios prestados por la organizaci贸n, tanto dentro del equipo como entre equipos, es recomendable la creaci贸n de comunidades orientadas al aprendizaje y desarrollo de habilidades pr谩cticas.
La creaci贸n de una Comunidad de Pr谩ctica tiende a ser fruto como respuesta a las acciones de mejora detectadas durante la Big Review.
Acuerdos
Como bases m铆nimas que sustentan el control emp铆rico de procesos, cada equipo debe tener un lenguaje com煤n que permita la inspecci贸n, adaptaci贸n y transparencia a trav茅s del desarrollo y difusi贸n de acuerdos expl铆citos.
Los acuerdos base sirven como instrumento del entendimiento compartido y es desarrollado sobre la base de los compromisos y responsabilidades adquiridos por los equipos.
M-DoD (Minimum Definition Of Done)
Todos los equipos de desarrollo de producto comparten una definici贸n de hecho m铆nima.
La Definici贸n M铆nima de Hecho, es la base necesaria para generar un entendimiento compartido de "驴qu茅 se entiende por hecho?" Este entendimiento no es objeto de negociaci贸n, puesto que opera sobre la calidad de los productos y servicios prestados.
Sobre esta base, cada equipo puede perfeccionar y mejorar los criterios de calidad de su producto o servicio dando lugar a un D.O.D propio m谩s exigente que comparta la base com煤n establecida en la organizaci贸n.
SLA (Service Level Agreement)
Todos los equipos deben establecer Acuerdos de Nivel de Servicio sobre c贸mo operan en el desarrollo de productos y en la prestaci贸n de servicios.
Estos acuerdos deben ser establecidos, conocidos e inspeccionados de forma emp铆rica (a trav茅s de la experiencia en el desempe帽o de las actividades del equipo y amparados con datos objetivos que los respalden) para aumentar, en la medida de lo posible, la predictibilidad y la cadencia de entrega dentro de la organizaci贸n.
Durante el desarrollo de los servicios los SLAs pueden modificarse para adaptarse a las circunstancias y necesidades del entorno.
Usualmente los equipos de desarrollo de producto establecer谩n sus SLAs, indicando de forma expl铆cita las cadencias de entrega de incremento de producto.
ROI (Return Of Inversion)
Sin perjuicio de la utilizaci贸n de otras m茅tricas que garanticen la inspecci贸n del 茅xito de nuestros productos y la calidad de nuestros servicios, el Retorno de la Inversi贸n es la m茅trica de medida principal para cada una de las actividades que realicen los equipos de la organizaci贸n.
Analizar la rentabilidad que obtiene la organizaci贸n, bas谩ndonos en las inversiones y actividades realizadas, durante el desarrollo de productos y la prestaci贸n de servicios es un indicador directo y transparente para la validaci贸n de las hip贸tesis de negocio contenidas en cada una de las Epopeyas.
Aquellas acciones que no tengan impacto directo o indirecto en el Retorno de la Inversi贸n deben ser evaluadas y, en su caso, eliminadas para el buen gobierno y desempe帽o de la organizaci贸n.