Mes: octubre 2015

Ok, digamos que el Product Owner siempre está dedicado al equipo el 100% de su tiempo, trabaja codo a codo con quienes implementan el como de la solución, refina la pila (backlog) al menos 2 veces a la semana, mantiene las fechas de entrega alejadas del equipo y enseña a la compañía sobre la importancia de la priorización y valor de negocio.

La totalidad de los miembros se han esmerado en resolver las historias de usuario, remover los obstáculos y pasar la Definición de Terminado (Definition of Done). El día ha llegado, todo el mundo está ansioso ya que en menos de media hora esas características que harán volar la imaginación de las partes interesadas (Stakeholders) estarán en el “aire” de la sala.

La habitación está lista, se cuenta en cada silla con un programa a seguir en papel con una decoración muy bonita, así como una breve descripción de cada sección a llevar adelante. A su vez, el Scrum Master ha confeccionado un par de dinámicas para romper el hielo, ya que hoy habrá varias visitas importantes, de las cuales se espera retro-alimentación positiva, tanto hacia el producto como también sobre difundir las bondades hacia el resto de la empresa de la nueva solución.

Incluso los miembros del equipo han comprado  dulces y tartas para recibir a los invitados, así como se han conseguido  varios computadores portátiles y tablets para probar la versión móvil.

El día anterior, Product Owner y equipo probaron las distintas características para asegurarse no solo la pre-aprobación sino que también que todo esté en orden.

Las expectativas son altas y puede sentirse en el ambiente la energía y optimismo resultado del trabajo duro de 2 semanas más la acumulación de pequeñas tareas en los anteriores. El equipo realmente quiere ver como cambiará la vida de esas personas a perpetuidad el trabajo que han hecho.

De repente, el teléfono suena 10 minutos antes de la Sprint Review y las noticias no son alentadores…. su Product Owner ha tenido un percance personal(*) y se siente indispuesto. No estoy hablando aquí de uno  mediocre que pone otra prioridad de la empresa el día de la ceremonia más importante, esto es algo inesperado y de último minuto.

¿Qué hacemos entonces? ¿Cancelamos la Sprint Review para el día siguiente? ¿Fin del próximo Sprint? ¿La hacemos otro día con menos personas? ¡El equipo entra en pánico!

La respuesta es NO a todas ellas. La cadencia es fundamental en la agilidad; aquí los equipos son auto-organizados, responsables y deben apropiarse del problema de la misma forma que hacen con las historias de usuario.

“Como equipo Scrum deseo poder mostrar lo que he hecho y obtener retro-alimentación para así deleitar al cliente”

Hasta aquí no hay problema ya que es posible que se lleve adelante, no obstante, el criterio de aceptación de la ceremonia Sprint Review es que las historias de Usuario sean aceptadas/rechazadas durante la misma.

¡Ups! debemos entonces ver la historia completa

“Como equipo de Scrum Deseo poder mostrar lo que he hecho y obtener retro-alimentación para así deleitar al cliente”
Criterios de aceptación:

• Que se muestren las soluciones a los problemas
• Que se aprueben o rechacen las historias si se cumple la Definición de Terminado y los criterios de aceptación de cada una de ellas

Para esta segunda parte, es necesario que alguien tome temporalmente el rol de Product Owner. ¡Pero cuidado, no es un Product Owner Proxy! Es simplemente una persona dentro de la empresa que tiene el conocimiento y el poder suficiente para aprobar las historias y no ser enviado al infierno por hacerlo.

En las organizaciones más jerárquicas, podría ser el Jefe del Product Owner, pero otro Product Owner también es un buen candidato.

Conseguido el mismo, la sesión se lleva adelante de la misma forma

¡pero cuidado!

Quizá se necesite tomar un poco más de notas o incluso filmar la sesión ya que seguramente se pierda parte de la retro-alimentación en el traspaso de la misma para cuando esté de vuelta el alma perdida.

Pero Erich…. ¿Qué hacemos si no hay nadie que lo suplante?

Si no hay nadie que pueda ser un reemplazo de forma temporal, sería posible para el equipo presentar las historias pero no llevar adelante su aprobación, por lo que éstas quedará temporalmente congeladas (sin ir a producción).

Es importante en todo momento mantener la motivación y capturar toda la retro-alimentación posible. Al no estar el Product Owner, es posible que no se hagan tantas preguntas, por lo que deberán poner especial atención en enfatizar y maximizar las mismas.

Finalmente, si al día siguiente para la ceremonia de Sprint Planning el Product Owner sigue ausente, el equipo puede comenzar su Sprint tomando del Backlog de Producto las historias más prioritarias basadas en su velocidad (velocity), esto es, en el orden de prioridad existente ya que el equipo no tiene la potestad para cambiar la misma.

Gracias por escucharme,

Erich.

(*) Ningún Product Owner ha sido maltratado para escribir éste artículo.

According to various religions, karma is a transcendent energy (invisible and immeasurable) which is derived from the acts of individuals. Agile also has its own karma which is divided into 6 levels. Each of these offers a different kind of «energy» which is translated into a specific and unique type of feedback loop.

Agility requires the 6 levels implemented and operating effectively to continuously grow into a healthy and unstoppable eco-system.

The level zero is what I call Hell or Inferno. In here, the focus of the whole organization is set to push for deliveries at certain dates without seriously considering business value as an evolutionary process. This mentality brings a drop in quality, the creation of a pool «resources» that will make employees slaves of products, bunches of unstable code and products that will not fully satisfy the customer. This will also cause uncertainty about the completion of products by certain dates, thing which will fuel a bigger vicious circle of unintended consequences.

Karma Level 1 implies the adoption of the Agile mindset. Under this energy, people have an internal feedback loop where the customer is placed first and in the centre of the universe. Understanding how to deliver value to them is the primary objective of this kind of energy. This «energy» places also the focus on the effectiveness of a perpetual cadence to  deliver business value and the use of honest and face to face communication. This level of innate feedback occurs in the conscious area of the brain related to decision-making -and is the fastest one-.

Karma level 2 focuses on the use of work in pairs 24/7 (pair programming).This technique has been shown that not only help teams share and retain knowledge within the group but also empowers them to validate and make better design decisions. This  promotes a sense of collaboration on its various tasks and reduces code «paternity», reinforcing individuals to explore different options based on its diverse points of view. This kind of «energy» should be mandatory on times where software complexity has raised exponentially. This circle enables a feedback loop to the team in a matter of seconds.

Karma level 3 focuses on refactoring, writing tests first and Test-Driving-Development (as also as acceptance tests or similar). TDD is a disciplined practice where teams write the evidence that will support a hypothesis before writing the implementation itself. TDD helps create a structure which facilitate changing the application quickly as well as reducing defects and increasing reliability and code quality. Here the feedback loop occurs in a matter of minutes.

Karma level 4 of karma focuses on breaking a pattern typically found in traditional software companies: integration of the components of an application at the very last minute or when the project is almost done. When continuous integration is used, this process is often carried out in a matter of hours. This helps teams lower the risks of integration and eliminate potential periods of stabilization. Using continuous integration activates a  feedback loop which helps analysing  all the code as a whole, thing which occur within tens of minutes.

Karma level 5 becomes in place when the Product Owner is collocated with the team. This helps the group obtain support and questions answered in a maximum of hours. This creates a feedback loop which increases the level of communication related to the product, thing which will decrease the times from days to hours.

Finally, the Karma level 6 keeps the team focused by using a time-box. This allows an  effective flow of information and feedback loop from clients/stakeholders (Stakeholders) in weeks rather than months. This energy will re-affirm the cadence and prepare effectively people to future demands, thing which ultimately strengthen the nature of evolutionary software.

The 6 levels of Karma  must be adopted effectively and in full in companies wishing to move into the Digital IT world and Agility. The fact that one does not exist or is not addressed in full will hinder the company growth towards the creative economy and the steps  towards being a continuous learning organization.

Have in mind that any effect on the lower levels exponentially affects the upper circles. Because the feedback loop times are different inside each circle, the consequences will be seen deferred in time, thing which will increase system complexity and complicatedness. In the event of that happening in a traditional company, people will tend to focus on solving the a problem -resulting from the action in the past- rather than addressing the root/real cause.

This last thing is generally seen in immature companies without continuous improvement. In there, any fault on the inner circles will be addressed by adding new processes or controls to alleviate the system imbalances. The result will be an  increase in complexity and complicatedness and  establish a bigger vicious cycle which will destabilize the other areas.

As you can see, the 6 levels of Karma help teams and companies find a way to self-evaluate and improve themselves. Having in mind the circles in this way will also help understand the effect of the actions and connection between them and the different timings.

In which level of Karma is your team or company currently now?