Tactical Forking

By Fausto De La Torre, Director of Platforms and Cloud – Europe, Thoughtworks

There are occasions in which multiple teams with different needs and business priorities work on the same code base, which infers communication and overhead in coordination between them at different moments of the development cycle, increasing the cycle time, time to recover from errors, etc..

Due to this (and many other reasons) many teams choose to decouple themselves from the rest, taking their domain elsewhere. For this, many use techniques such as the Strangler Application, creation of an Autonomous Bubble or even seek to migrate their domain to a new application completely independent.

These approaches are effective when dealing with legacy systems or with third-party systems, however, when it comes to applications in constant evolution, these approaches require a great effort before beginning to obtain a real benefit; There are times when they are simply endless efforts.

When we think of taking off a piece of the system to another side, what comes to mind is an extraction: take off a piece from the whole (figure 1), however, another way to see it, it is to keep the piece and remove the rest (figure 2)

Figure 1

Figure 2

Under this line of thinking, we could duplicate the application and begin to get rid of the components that are not of our interest. In this way one of the teams can get its own version of the application and start working on it, by reducing the coordination with the other team. This approach is called Tactical Forking

What is sought with this approach is to obtain the benefit from the first moment in which each team can have its own workflow and path to production without affecting another team.

How does Tactical Forking work?

Forking (Duplication)

It is necessary to create a copy of the system and its deployment mechanism (tests, pipelines, etc.).

Routing

It is necessary to have a routing mechanism that allows users or consumers to access the different parts of the systems

Refactoring

This is a key point, it is necessary to constantly refactor the code of the new application eliminating unnecessary code to have a more maintainable code base.

Use cases

Microservices

When we are implementing a microservice architecture, and we start with the Monolith First approach, we can reach a state in which the component has several domains that need independence.

Multiple teams

There are occasions in which an application was developed by a team and then other teams joined the same code base to implement other modules with different business needs, reaching a state in which there is too much coordination and communication for deployment, Correction of errors and even blockades to commit in the code due to pipelines broken by other equipment.

Considerations

Take into account the components that when they change require changes in both copies of the application, for example: non-modular css files that are not served in a cdn.

Finish the work, I mean reach the final state otherwise you will have two or more monoliths with a lot of code that is useless and can produce unexpected errors.

Mind the “Tactical” in the name (Tactical Forking), it’s the first step, not the last one.

Advertisement

Trabajo remoto, una perspectiva de empresa y de equipos

Cuando el trabajo remoto pasa de ser un diferenciador a ser un mecanismo de subsistencia empresarial.

En este espacio quiero abordar este tema desde un ángulo diferente: más allá del individuo, cómo hacerlo eficiente desde una perspectiva de equipo y de empresa.

Las crisis traen oportunidades, y no con esto quiero minimizar su efecto en la sociedad o peor aún justificarlas. El Covid-19, sin ahondar en la enfermedad, sino en los efectos sociales en el colectivo, nos ha llevado a la sociedad a adoptar nuevas formas de desempeñar nuestras actividades acelerando la necesidad del trabajo remoto.

El trabajo remoto, no es una tendencia aislada que sucede ahora, venía siendo una respuesta a las necesidades que las empresas toman en cuenta para atraer al talento joven, a personas con obligaciones en el hogar e incluso desde un punto de vista más consciente, las organizaciones lo están considerando como una ayuda al ambiente reduciendo la necesidad de transporte, sin embargo la situación actual hace que este tema sea más relevante que nunca.

En opinión personal, dudo que el efecto del trabajo remoto se revierta completamente, aún superando la crisis actual, la “normalidad” cambiará y las empresas se verán forzadas a adaptarse a una nueva realidad. Es por eso que traigo a colación algunas lecciones aprendidas por más de 6 años en ThoughtWorks brindado servicios de consultoría tecnológica de manera remota y más de 20 años de aprendizajes colectivos de esta empresa brindando servicios distribuidos.

Desde la perspectiva de la empresa

El trabajo remoto debe ser considerado una capacidad empresarial

Más allá de que una persona pueda hacerlo o que haya sido adoptado por un equipo, las organizaciones deben mirar el trabajo remoto como una capacidad empresarial a desarrollar.

Algunos humanos son capaces de tocar un instrumento musical de manera extraordinaria; en un principio las actividades y rutinas asociadas requieren esfuerzos deliberados hasta que la capacidad sea desarrollada, es entonces cuando las melodías, que para un novato son imposibles, para los expertos son tan fáciles que las ejecutan sin siquiera pensarlo mucho.

Así mismo las organizaciones que desarrollan capacidades, pueden concentrar sus esfuerzos en temas más complejos basados en las habilidades que como organización han adquirido.

Si bien esta no es una guía de cómo desarrollar una capacidad de negocio, mi intención es poner sobre la mesa algunas experiencias en trabajo remoto que pueden hacer este camino más fácil.

Promover la cultura organizacional en un contexto diferente, por supuesto que esta modalidad trae cambios, y las organizaciones se deben adecuar a ellos, sin embargo la misión y los valores de la empresa buscan permanecer en el largo plazo, el reto es cultivarlos y promoverlos en un entorno un tanto diferente.

Reaccionar rápido y tener en cuenta el largo plazo, si bien las crisis o emergencias pueden llevar a reacciones inmediatas, no quiere decir que esas acciones y formas de trabajo puedan perdurar en el tiempo. Adaptar la visión de cómo trabaja la organización será necesario. La empresa debe comunicar las acciones inmediatas pero debe comunicar el plan o el anhelo de ir más allá de eso, los colaboradores luego de un tiempo se pueden sentir inconformes con una forma de trabajo improvisada.

Tomar en cuenta a todos los individuos como parte del todo, los colaboradores deben saber que están respaldados por una organización, que no están aislados, que hay una diferencia entre ser un “freelancer” que trabaja desde su casa y ser un colaborador de una organización que trabaja desde su casa.

Promover espacios virtuales de comunicación grupal, no solo para hacer comunicaciones oficiales, sino también espacios de discusión y conversación activa entre individuos y equipos. Abrir debates, buscar temas donde la gente pueda exponer sus ideas.

Buscar encuentros frente-a-frente periódicamente, el tener la capacidad de trabajar remotamente no significa que se lo tenga que hacer siempre, nada se compara a hablar con alguien personalmente, las conexiones creadas en este tipo de encuentros perduran en el tiempo, especialmente cuando la organización no nació remota.

Confiar en los equipos y promover la autonomía, existe la creencia todavía de que si no se ve a las personas en el sitio de trabajo entonces no están trabajando, hemos visto que el nivel de autonomía cuando no hay supervisión directa, aumenta (al menos en nuestra experiencia), siempre y cuando las expectativas estén claras, los objetivos definidos y las facilidades instauradas.

La gente se desgasta más trabajando remoto, las organizaciones deben tomar en cuenta que los individuos, trabajan más al estar desde casa; después de un tiempo de generar costumbre, las distracciones disminuyen y el tiempo de enfoque al trabajo es mayor por parte del individuo, temas como lesiones o el desgaste intelectual (efecto burnout) deben ser considerados.

Remoto desde el ingreso, cuando una nueva persona ingresa a la organización, quizás no sabe cómo hacer trabajo remoto; si se quiere adquirir esta capacidad empresarial, la organización debe ofrecer a los nuevos colaboradores desde su onboarding, los implementos, el instructivo, los estándares de herramientas y capacitación, así como exponerlo a ambientes de trabajo remoto desde el inicio.

Los sistemas de comunicación deben ser oficializados, seleccionar herramientas de software para videollamadas, mensajería instantánea, email.

Reconocer que todos pueden trabajar remoto, tener la capacidad de trabajar remoto, quiere decir que cualquier persona o equipo lo pueda hacer, o incluso en casos de crisis o emergencias, que todos lo tengan que hacer al mismo tiempo. Tener un plan de cómo proveer la infraestructura e implementos necesarios es indispensable.

Asegurar y/o proveer a los colaboradores de implementos y servicios para poder trabajar desde su casa de manera eficiente: audífonos, parlantes, cámaras, micrófonos, computadoras portátiles, monitores, internet de alta velocidad, etc.. En estos momentos estamos viendo cómo incluso la prestación de sillas y escritorios son necesarias. Proveer kits básicos de trabajo remoto al momento de que un nuevo colaborador ingresa a la organización (al menos audífonos de alta calidad).

Redes y mecanismos de acceso seguros, es primordial que las empresas tengan un plan (no improvisado) y ciertos estándares implementados para el acceso remoto hacia sus servidores, bases de datos, aplicaciones, etc. El NIST, por ejemplo emitió una guía en 2016 para empresas de cómo hacerlo.

Instalar software de acceso seguro en las computadoras de todos los colaboradores para acceder a la red interna de la empresa desde el primer día de ingreso e.j.: clientes VPN si la empresa lo maneja.

Asegurar el acceso a los proveedores de servicio, no solo a los colaboradores.

Se amplían los límites de contratación, las empresas ya no estarán limitadas a contratar personas que vivan en su misma ciudad.

El espacio físico cuando una empresa comienza a institucionalizar el trabajo remoto, quizás el espacio físico no tenga que crecer en la misma proporción que antes.

Los horarios pueden cambiar ya que muchas personas podrán optimizar el tiempo de transporte y empezar sus actividades más temprano..

Nuevos proveedores, las organizaciones buscarán nuevos proveedores para adecuar espacios remotos de sus colaboradores.

Desde la perspectiva de los equipos

El todo es más que la suma de sus partes.

Cuando hablamos de un equipo no solo hablamos de un grupo de personas que trabajan juntas, sino de un ente que ha desarrollado una cultura, una forma de trabajo, valores compartidos y metas que van más allá del individuo. Hemos visto como aspectos de la cultura de un equipo se mantienen incluso cuando todos los miembros originales han sido reemplazados.

CULTURA

La entidad (equipo) debe ser tomada en cuenta además de los individuos y es indispensable que alguien tome la batuta.

  • En nuestros equipos, las buenas prácticas del trabajo remoto se han convertido en un hábito, sin embargo cuando trabajamos con clientes que no están acostumbrados a esto, el designar un “champion” del lado del cliente, que es quien aboga por velar que estas las buenas prácticas se cumplan, es necesario.
  • Si todavía estas prácticas no se han convertido en un hábito es recomendable que alguien tome la batuta y abogue por ello.

Escoger un horario, puede ser el mismo que cuando todas trabajaban presencialmente, sin embargo, cuando están trabajando desde casa, el tiempo utilizado en el transporte, es utilizable y puede ser excusa ideal para iniciar y finalizar antes.

Conservar y crear nuevas prácticas y rituales, si se solía trabajar de manera presencial y ahora se cambia a un esquema remoto, hay que buscar la manera de adaptar las prácticas para que sean amigables de manera remota e ir cambiando de a poco, evitar cambios bruscos de forma que la cultura vaya evolucionando no destruyéndose.

Introducir el trabajo remoto en las retrospectivas intencionalmente o hacer retros específicamente para este tema.

Tener en cuenta a las personas como individuos y ser empáticos, crear espacios virtuales intencionalmente de conversación personal, ser tolerantes a los nuevos espacios de trabajo, no todos tienen una oficina en su casa.

COLABORACIÓN

Utilizar una pizarra virtual, muchas veces es necesario dibujar, cuando las personas están Cara-a-Cara se levantan y utilizan una pizarra, al estar remoto se necesita un board virtual colaborativo (Mural nos ha ayudado mucho). Se puede tener un board dedicado como si fuera un pizarrón, al que todos tienen acceso.

Incluir la sala virtual en todas las invitaciones de las sesiones de trabajo y todos los links de documentos, presentaciones, etc.. que vayan a ser utilizados.

Todo digital, si bien parece obvio a veces no lo es, cuando estamos trabajando de forma distribuida hay ocasiones que dos o más personas se encuentran juntas y por la facilidad se tiende a utilizar la pizarra y poner una cámara para que la gente vea, o utilizar el board de avance de trabajo (kanban, scrum) físico y poner una cámara: esto hace que la comunicación y la conversación sea aislada y dominada por la gente que se encuentra junta y se excluye a los demás miembros.

Si uno está remoto, el equipo está remoto, basta con que alguien en el equipo no se encuentre físicamente para que el equipo esté en modo remoto, esto implica que todos los que estén juntos se comuniquen mediante la herramienta de mensajería instantánea o que incluso todos se unan a las videollamadas desde sus computadoras para las reuniones de trabajo.

VIDEOLLAMADAS

Una sola herramienta para videollamadas, hay muchas en el mercado, el escoger solo una ayuda a que los plugins, los drivers, etc. se hayan configurado y funcionen bien para todos, a veces el tener dos herramientas, una con el cliente y otra para nosotros, ocasiona inconvenientes como que el micrófono o audio a veces no sirve si sales de una herramienta y entras a otra, entonces reiniciar la computadora o re configurar algo es necesario.

Considerar criterios claves al escoger una herramienta: que permita mute/unmute fácil, incluso en pantalla completa o compartida, que se pueda compartir la pantalla con varias opciones, en Zoom por ejemplo se puede elegir la ventana a compartir, de esa forma se pueden ver notas al momento de hacer una presentación. Tener en cuenta que existen herramientas de videollamadas que tienen limitaciones en cuanto a miembros conectados o a tiempo de duración.

Videollamada grupal siempre abierta en la que todos los miembros puedan estar conectados siempre; si alguien se encuentra en otra llamada es comprensible que no esté conectado, se recomienda unirse a la llamada grupal en cuanto sea posible, esto ayuda a crear un sentido de equipo y transparencia.

Cámara prendida, parlantes/audífonos abiertos y micrófonos cerrados para todos los individuos.

Micrófono y monitor compartido, si hay miembros del equipo que se encuentran juntos es recomendable prender también un micrófono central y un monitor conectado a la videollamada grupal.

Dos monitores si es posible para cada miembro del equipo, uno para su trabajo personal y otro para proyectar la videollamada grupal siempre visible.

MENSAJERÍA INSTANTÁNEA

Oficializar una sola herramienta de mensajería instantánea para el equipo. Siempre hay preferencias diferentes: slack, telegram, hangouts, etc., pero el tener solo una es esencial para fortalecer la comunicación como equipo y evitar conversaciones aisladas.

Considerar criterios claves al escoger una herramienta, al momento de evaluar considerar una que permita tener varios canales, etiquetar personas, notificaciones, versión móvil y de escritorio, que se pueda instalar en varios sistemas operativos, que permite saber fácilmente cuáles son los mensajes no leídos.

Instalar en el teléfono móvil: la energía eléctrica y la conexión a internet no son tan fiables como quisiéramos, al menos la telefonía móvil suele servir en esos casos. No hay que olvidar de silenciar las notificaciones luego del horario convenido.

Contestar rápidamente y respetar los horarios convenidos, el uso de estas herramientas es justamente para tener interacciones inmediatas, si un mensaje llega, lo esperado es una respuesta rápida, es por ello que al momento de enviar un mensaje hay que ser consciente de los horarios convenidos y del tiempo de los otros que pueden estar enfocados en otras tareas.

Solo para respuestas rápidas, evitar utilizar este medio para temas que no requieren una respuesta rápida.

No utilizar el chat de videollamadas, si la herramienta de mensajería instantánea no es la misma de las videollamadas entonces evitarla al momento de enviar links o cualquier texto, oficializar toda comunicación de este tipo en la misma herramienta, en ocasiones en una llamada es necesario enviar el link de una presentación o un extracto de un mail y por facilidad se utiliza, por ejemplo, el chat de Zoom, la desventaja es que los mensajes en el chat de Zoom son volátiles, y no siempre son visibles para las demás personas que se unen después.

CANALES

Un canal principal del equipo, para mantenerse siempre atentos.

No hay sobre comunicación, si alguien va a estar desconectado por algún motivo por mas de 10 minutos es importante notificarlo: AFK 15 min, volví, buenos días, etc. hacen que la cultura del equipo no se pierda.

Abrir un canal informal: a veces es necesario distraerse, un chiste, memes, etc. y en ocasiones el canal grupal no es el mejor mecanismo, aquí caen todos los mensajes que no requieren una respuesta rápida o ninguna en absoluto.

Mantener la relevancia en los canales, frases como “No lo ví”, “Se me pasó” u otra similar son un buen indicativo que gran parte de los mensajes no son importantes para los miembros.

Evitar conversaciones muy específicas entre dos personas en los canales grupales, quizás es necesario una llamada.

Canales por intereses comunes, dependiendo de las necesidades se pueden abrir otros canales donde se traten temas específicos de un grupo que no son relevantes para todo el equipo.

Evitar la proliferación de canales, Si bien abrir un canal es fácil, la consecuencia es que las personas no saben que seguir o dónde colocar sus mensajes.

La mensajería instantánea no reemplaza al correo electrónico. El email es la mejor manera para tener conversaciones importantes que pueden ser tratadas de manera asíncrona.

Preferir videollamadas cuando se requiere mayor comunicación, si es una conversación importante y/o requiere acción inmediata cambia a una videollamada inmediatamente.

Toda innovación es producida por una necesidad, ya sea de motivación interna o por agentes externos, que hace que las organizaciones se adapten a un nuevo entorno para poder seguir siendo relevantes.

El trabajo remoto no es algo nuevo, pero hoy es mas importante que nunca. El efecto que esta crisis esta causando en cuanto al trabajo remoto no se revertirá del todo; esta crisis solo aceleró la adopción de esta práctica que seguirá permeando en la organizaciones y la sociedad generando efectos colaterales y un cambio de cultura al que tendremos que adaptarnos todos.

Funciones de Aptitud (Fitness Functions)

Cuando creamos una arquitectura, lo hacemos con un propósito, y muchas (o todas) las veces pensamos que la arquitectura que estamos ideando antes de iniciar el desarrollo es la que va a cumplir el propósito, que puede ser asegurarse del rendimiento, auditabilidad, escalabilidad, mantenibilidad, etc. (los llamados requerimientos no funciones)

El hecho es que muy pocas veces (o nunca) en realidad verificamos que el propósito de la arquitectura ideada se esté cumpliendo. Así mismo cuando nos encontramos desarrollando las aplicaciones y evolucionando la arquitectura (todas las arquitecturas evolucionan), no sabemos en realidad si el desarrollo de una solución está “respetando” o preservando la arquitectura o los principios de arquitectura, y nos damos cuenta cuando ya es muy tarde.

Parte de los conceptos de una arquitectura evolutiva son las funciones de aptitud (fitness functions) que en esencia, tratan de hacer verificables las características principales de arquitectura que guían una solución de manera constante e incremental.

Es así que cuando estamos diseñando una arquitectura nos preocupamos de que la solución sea escalable o mantenible (bonitas palabras), pero que significa que sea escalable, que tenga “buen” rendimiento o que sea mantenible, justamente es aquí donde entran las fitness functions, buscando hacer más objetivas estas características mediante mecanismos de verificación constantes.

Por ejemplo: si decimos que una arquitectura busca que la solución tenga “buen” rendimiento, entonces necesitamos crear una(s) función de aptitud que defina que significa “buen rendimiento”, creando un mecanismo de control que verifique en cada nueva versión de la aplicación que las operaciones o transacciones más importantes no tomen más de medio segundo en ser ejecutadas; esta función de aptitud puede ser ejecutada en el proceso de integración o entrega continua antes de liberar un nueva versión a producción.

Si buscamos que sea mantenible y entendemos que una de los aspectos para que la solución sea mantenible es crear una arquitectura en capas dónde buscamos que solo existan dependencias en una dirección (figura 1), entonces debemos crear una función de aptitud que verifique las dependencias entre paquetes sean solamente las que hemos definido (figura 2).

Captura de pantalla 2018-02-27 a la(s) 15.41.53

figura 1 –  Arquitectura en Capas

Captura de pantalla 2018-02-27 a la(s) 15.57.12

figura 2 – Función de aptitud que analiza dependencia entre capas

Dado que cuando estamos construyendo arquitecturas evolutivas buscamos soportar un cambio incremental y guiado a lo largo de múltiples dimensiones, es importante saber hacia donde estamos guiando el cambio y es aquí donde las funciones de aptitud juegan un papel principal, ya que son controles que nos permiten identificar si las características principales de arquitectura se están preservando al mismo tiempo que la arquitectura evoluciona, o en otras palabras: Las funciones de aptitud nos permiten identificar si la arquitectura está evolucionando hacia donde queremos que evolucione.

Anticorruption Layers

That panic moment when the decision of changing the application X which our systems depend on is made.

When we build systems, most of the times those systems depend on or need external or third party applications. The moment when one of these external applications need to be changed or an updated is needed is when the problems don’t stop.

The biggest problem most of the time is not the new application or the new version doesn’t have the same features than the older one (in fact they tend to have cooler features or more of them), the problem is that our system is invaded with dependencies of the external application; the problem is that our domain is corrupted by an external domain.

Screen Shot 2016-06-29 at 3.59.57 PM

For instance, we have a system (green boxes) that manages, besides other features, files and documents, so it has been decided to use a file repository like Alfresco or FileNet (yellow box). Alfresco (or any other tool) provides libraries or API’s that are used by our system to make the integration. In this point our system/domain has an external dependency along multiple components, and that’s why we say our domain is corrupted because the external domain is allocated everywhere. The moment we will decide to switch the the yellow box by a red one we will need to seek every single dependency in our domain and make the change for the new one.

We can avoid this problem introducing an Anticorruption Layer (a term coined in the book DDD) that allows us to isolate the external or third-party dependencies, whether these are tools, systems, libraries, different domains, etc..

Screen Shot 2016-06-29 at 4.14.17 PM

The idea is to build a layer between our domain and the external dependency. This layer is the responsible to do the transformations in both ways; it means, transform the components of our domain into components that the external tool can understands, and vice versa. This way we can isolate the dependency in one single place, so our domain (green boxes) is focus on solving the problem, and any change in the external dependency won’t affect substantially our system behavior.

Conway’s Law in Software Architecture

In 1967 M. Conway enunciated a phrase at the end of his publication How do committees invent?. This phrase was made popular by Fred Brooks on his book The Mythical Man-Month with the name of Conway’s Law.

“… organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” M. Conway – 1967.

Although this is not a scientific law, it is a valid proposition for many environments, and we can perceive it in our workplace or in other companies that develop software.

The organizational structure of a company will reflect in the systems produced by this organization; if there is an invoicing department, there will be an invoicing system for sure, if there is a notifications area, a system called NOTSYS (with such a cool name) will exist, the finance department will have a FINSYS, and so on, and the systems will integrate with each other in the same way the organization departments communicate.

This law also plays a role at the construction time of every of these systems, because the architecture of these products will reflect the communication structure of the teams that are part of that process.

Due to this fact, if the technology department is organized around technical capabilities, with a work group focused on the user interface, other group to the database, other to the infrastructure, other to the process management, another to the implementation of business logic on the server side (figure 1) the architecture of the resulting systems (figure 2) will be very similar to these communication structures.

Technical organization of teams
figure 1 – Technical organization of teams

Architecture driven by technical capabilities
figure 2 – Architecture driven by technical capabilities

Systems are dynamic, there will always be changes, and these are often caused by changes to the business definitions; if an organizational structure is driven by technical capabilities, every change in the business definitions will require work from all the technical areas of the organization, budget and time assignment, etc. This is one of the reasons why some organizations try to group requirements to “optimize” time and resources, lengthening the development process until all the necessary work can be “justified”, which leads to the business insatisfaction towards the technology department.

In the other hand, we can find organizations that favour multidisciplinary or cross-functional teams formed by different roles and guided by the business capabilities (figure 3) where changes produced by new business definitions are executed from begin to end by just one team avoiding processes overhead, producing different, and often more distributed, architectures (figure 4) with greater evolution capacity.

Organization of teams driven by business capabilities
figure 3 – Organization of teams driven by business capabilities

Arquitectura guiada por el negocio
figure 4 – Business Driven Architecture

In the end, software is the product of an intellectual and collaborative process that will reflect the ideas of the people involved in this process and the communication structures between teams, as we have seen. Due to this, we should take in account this law at the time when we are structuring teams depending on what we want to achieve.

Translated from the original in Spanish. Thanks for the translation Carlos Oquendo @andres19_05

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.

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.