Business Value

We have talked a lot about that our software should add value to the business, actually is one of the principles in agile methodologies, and I think is a good principle because our software should be part of the effort to achieve something bigger.

But What does business value mean? Is it possible to measure it? if so, What is the importance of this?

What is it?

We can say business value is a covered need or satisfied expectation of the business, when I say business, I mean stakeholders.

So this concept will depend of the stakeholders, and their needs, the more stakeholders, the more the perspectives of what the business value is.

It will depend on the the business area you are working on: for instance, if your goal is replacing a legacy licensed system maybe the business value will be determined in terms of the money invested vs the money you used to pay for the licenses; if you are talking about a business area that prevents doing illegal things, the business value could be  accomplishment of regulations; if you are involved in automating processes in government institutions the business value could be  satisfaction of the citizens when they use the systems or accomplishing the policies or regulations; even in the same business area, people could have more than one perspective of what the business value means.

Is it possible to measure it?

Yes it is, however is either complex or subjective, and here is the challenge, make the subjective points of view into tangible explicit concepts and deal with complexity to make it visible and understandable.

Before to start measuring something or at least trying to measure, we need to define it, since this definition is complex. We can not create a single concept, we need to define a model of the business value.

Defining the business value model.

A model is an abstraction that lets us represent something in an understandable way.

In order to simplify the reality, we make models to convey our understanding of things, but not only to understand, models always have a purpose and in most cases this purpose is to make decisions.

Identify the relevant stakeholders (decision makers):

In order to know what a covered need or a satisfied expectation is, we need to identify first who are the people who can define this.

There are a lot of interested people involved in an application construction, however it doesn’t mean that all of them are relevant for the project, it will depend on the project we are working on, not because someone uses the system it means that is our relevant stakeholder, we should clarify who are them, because only they can certainly know what are the goals that are required to achieve.

Identify goals:

Once we have identified the relevant stakeholders we can know which are the goals of the project, these goals can’t be subjective, should be described without ambiguities, and should be defined in a way that we can measure them.

Define the values:

It is important to know what are the values which will drive the project if it is the profit, policy or regulation accomplishments, the internal/external user satisfaction, the customer satisfaction, etc. we will need this in order to know if the work we are doing will deliver value or not.

Prioritize the values:

Defining which value is more important than other would let us decide the work we should start in case we have more than one important thing to solve at the “same time”

Identify metrics:

We need to agree on a way to measure the achievement of the goals through the values, choosing tangible metrics, and defining a way to collect those metrics; this way we will know how much value we are adding to the business and if the effort done is enough, if it is effective, this will let us change directions and make decisions..

For example the goal is pay less for the functionalities that a licensed application has, so we can identify the profit as the value and the metric is the money we are going to spend building a new system vs the money we used to paid for licenses.

Business value is not just a metric, is a model that will let us to identify what are our priorities, taking decisions based on the information, knowing what are the goals and the drivers.

Is it important to know what is our business value model?

Once the business value model is defined we have a way a to prioritize the requirements, we can know which should be the first system or functionality we should start on.

Otherwise, how do we certainly know if the effort we are doing is adding any value to the business? How the business could make decisions to continue or stop the project, or adding/reducing resources or members in the team, etc.?

When do we need to define the business value model?

When the project starts, to not work in the air without a north, to avoid doing effort that the company doesn’t need, making of our work a meaningless thing, to know what are our priorities and with which requirements we need to start.

Why is it important to measure the business value?

We need to know the business value we are adding and compare with the effort that it costs to produce it, with this relationship we could now if our work is efficient, if you should keep doing effort in certain aspects.

Look up the trends

It is important have metrics in regular bases, as in software we should study the story of numbers rather than the number itself (at least when the value is not determined in terms of money), if we look the trends we can certainly know when the relationship value/cost is decreasing. E.g. The business value is in terms of customer satisfaction (we are assuming that we have a way to measure it) we can have metrics about the relationship business value/cost every iteration, and lets say that in 10 iterations the value of the relationship oscillates between 35-40, suddenly in iterations 11, 12, and 13 the value begun to decrease to 25, 20, 15, so we can say that our effort is inefficient and we have to make some decisions.

Do we need to estimate the business value in our story cards?

I think is better ask ourselves how to identify stories that deliver business values, since we have a model with prioritized values the stories we create should be aligned with that model.

Advertisement

Trabajando en Squads

“Divide y Vencerás”

Trabajar en un equipo grande implica desafíos, más aún cuando dicho equipo es distribuido, desafíos en el hecho de conservar prácticas ágiles y que estas aporten valor y no sean ejecutadas solamente porque así lo dice el manual; parte importante de ser un equipo ágil, es no solo ser reactivos a situaciones inesperadas sino también es estar inmiscuido en un proceso de mejora continua, en el que se puede evidenciar escenarios, que aunque no sean problemáticos a simple vista y formen parte de la rutina de trabajo, no son los más adecuados para ciertas condiciones.

todos

Evidenciamos que en un equipo de alrededor 20 personas, en el que se trata de cubrir las necesidades de varias aristas del negocio, existen aspectos que no favorecen el evolucionar dentro de un proceso de mejora continua, por lo que luego de un tiempo y hacer hincapié en las ideas propuestas, se decidió dividir al equipo en grupos más pequeños llamados squads.

Porqué hacerlo

  • El trabajar en un grupo tan grande dificulta la colaboración y comunicación entre los miembros, las ideas de mejora se pueden desvanecer, o tardar demasiado en probarlas, llegar a consensos no es lo más fácil y rápido.
  • Al tener varias aristas del negocio, se comienzan a formar grupos que no siempre siguen una línea clara.
  • La coordinación se centraliza y no da mucho campo de acción ni espacio a la auto organización del equipo.
  • Cuando tu equipo es grande y tienes diferentes perspectivas de negocio, es fácil perder el panorama general y empezar a concentrarse en los detalles perdiendo de vista objetivos por parte del negocio.
  • “Si funciona no lo toques”. Así como en el código, podemos evidenciar este fenómeno también en el proceso; si las cosas funcionan de cierta manera, ¿no existe la necesidad de cambiarlo? no es verdad; siempre puede ser mejor. El proceso en  el que veníamos trabajando ya llevaba así por largo tiempo y prácticas que en un inicio tenían mucho sentido y agregaban valor, después de un tiempo no.
  • Prácticas como el stand up diario  pueden carecer de significado, al ser un equipo grande donde ciertas personas están enfocadas en un tema y otras en otro, muchas veces los detalles diarios carecen de importancia para los demás miembros.

Como lo implementamos

Formar los equipos

Se formaron tres equipos con un promedio de 6 integrantes, buscando equilibrar la carga entre miembros del cliente y consultores; guiados por líneas del negocio en las cuales nos podamos enfocar el menos en el mediano plazo.

Objetivos Claros

Cada squad debe tener una meta clara que no sea a muy corto plazo; es importante trabajar juntos en un objetivo en común y que todos los miembros estén conscientes a todo momento de lo que se busca alcanzar.

squadsAnalistas del negocio

Si estamos buscando agregar valor al negocio, es imprescindible contar con al menos un experto en cada squad que pueda dar directrices claras de lo que se está esperando alcanzar; al tener tres analistas en el equipo, lo primero que se hizo fue que cada uno sea parte de un squad, sin embargo hemos evidenciado que ellos pueden participar activamente en más de un squad durante un mismo periodo de tiempo.

Kick off de la meta planteada

Antes de iniciar la ejecución y desarrollo, existe una sesión de análisis con todos los miembros del squad dónde el analista de negocio explica claramente que es lo que se quiere lograr y para qué; de esta forma todos están claros antes de dar inicio.

Squad Amigos

Al iniciar con una tarjeta lo que hacíamos anteriormente es hacer una sesión denominada 3 amigos, donde intervenía el analista de negocio, el desarrollador y el tester; al dividir al equipo en squads, viendo que somos relativamente pocos en cada uno, decidimos probar haciendo está sesión entre todos los miembros en lugar de solo 3. Esto fue fruto de la auto organización de un squad que realizó la prueba y luego fue adoptada por los demás.

QA

Se busca que que la etapa de QA se la haga dentro del mismo squad, sin embargo hemos evidenciado que ciertos cambios que son de interés y conocimiento de todo el equipo, pueden ser revisados por otros squads.

Standups

  • Internos

Al finalizar cada día se realiza un standup entre los miembros de los squads, esté es el standup tradicional, donde cada miembro o pair habla de lo que ha hecho, lo que piensa hacer, los problemas que ha tenido, etc. Los standups son agendados a diferentes horas al final del día ya que existen personas como los BA´s que pueden estar en más de un squad.

  • Externos

Al inicio de cada día todo el equipo de trabajo se reúne y una persona de cada squad informa de manera general como va el squad en su búsqueda de alcanzar la meta, no comparte detalles, identifica si hay algo relevante que compartir al grupo como problemas o soluciones transversales a todo el equipo, esto ha causado que en lugar de sesiones de 20 a 30 minutos se reduzca a 5 o 10 como máximo.

Rotación y Pairing

  • Interno

El haber dividido en squads nos ha posibilitado ejecutar prácticas como pairing con el cliente más a menudo de lo que se hacía antes; es importante mantener la rotación entre los miembros del squad.

  • Entre squads

Hemos iniciado la rotación entre squads: luego de terminar la meta establecida un integrante de un squad puede ir a otro sin debilitarlo.

Retrospectivas

  • Internas

Realizamos retrospectivas entre los miembros del squad donde interviene también la persona que funge como Iteration Manager, que se convierte en un veedor del proceso en todos los squads y es quien puede generar un feedback mucho más rápido acerca de lo que ha funcionado o no en otros squads.

  • Externas

El Iteration Manager facilita la sesión cada fin de periodo, donde expone estadísticas e información relevante a todo el equipo de trabajo, es este el espacio donde se puede también discutir temas transversales, comunes y donde se puede compartir las conclusiones de la gestión de cada squad.

Despliegue:

El paso final de la gestión de entrega a producción sigue siendo centralizada, con resultados positivos.

Conclusiones y Ventajas:

  • Independencia en la organización: Equipos auto organizados con libertad de acción.
  • Llegar a acuerdos es más fácil y rápido
  • Retroalimentación más eficiente y rápida
  • Podemos probar prácticas en solo un squad para ver resultados y poder extrapolarlos al resto si funcionan o desecharlas sin causar demasiado impacto en el equipo.

Hemos visto luego de casi cinco meses de trabajar en squads, que los resultados son positivos, y perfectibles sin lugar a dudas, lo importante está en aprender de los errores y potenciar los aciertos, ya que esto no termina, es un camino de diario aprender y mejorar.