Software: How do you know when it is Green, Ripe, or Rotten?

Farmers Market Fruit Stand, public domain image @ http://www.publicdomainpictures.net/view-image.php?image=149772&picture=farmers-market-fruit-stand

How to buy fruits?

When I was a child, I spent a lot of time with my grandmother. She was raised in a remote agriculture community of my country. So she was very experienced with agriculture products. I love fruit juices and she love to consent all her grandchildren. One of the earlier lessons that I learned was how to pick a good, ready to eat, fruit. There were “easy” ones, like mangoes. Even a child can tell when a mango is not ready to eat yet, ripe, or overripe. But I also face more difficult challenges like melons and passion fruits. 

Those two have a similar little trick, as my grandmother teach me. You have to evaluate the outer layer, or skin, and look for overripe signs. If the outer layer was looks ripe, but firm, then you have to evaluate the inside of the fruit, without open it. Here comes the trick: you must shake the fruit near one of your ears and try to “listen” for the seeds to bounce and hit the inner cavity. If you feel or hear the seeds bouncing then there are good chances that the fruit was ready to eat.

You must have similar stories with culture and region specifics variations. There are other kind of “passed-on” skills like how to buy the best used car with a limited budget.

Now you could be a ground-up woman or man. You may be a c-level executive, a manager or any organizational role facing the decision of buy software products and / or services. And here comes the question: Do you know how to buy a software that is just “ready to eat”?

How to buy software?

Unfortunately, our elders did not taught us how to buy a good piece of software: a “healthy” one. Now we are facing that problem, and each day it becomes bigger and bigger. The average executive does not know how to evaluate the quality attributes of a software product. The more versed ones only know how to ask for aesthetics (visual), usability (easy to use, responsiveness, etc.), and functional quality. So they know how to assess if a software is “easy to use”, “looks pretty” (as of the industry and user-base standards), and if presents the functional characteristics they need (modules, features, etc.).

But there are other quality characteristics of a software products less obvious to the end user. To keep this discussion out of the technical (software engineering) jargon, just imagine (as with the fruits), that software products have an “inside” meat, that needs to be assessed as well. This quality characteristics of the “inside” parts of the software are called Structural Quality Characteristics. 

So, if you are not versed on how to evaluate the “insides” (structural quality) of a software product, do not worry. There are quantitative evaluations and even standards that can throw light into this matter. The last question will be: How to connect all this with my reality?

What to do?

Let's say that you are a COO (Chief Operations Officers), or a CFO (Chief Financial Officers); and you are involved in a big project requiring the purchase of a very expensive software product. If you are not in a very specialized industry, there will be lots, or at least two, options. So you need to select the “mature” (not the green, or rotten) one. And remember that “mature” means “good in the outside and in the inside”. Here you need to ask for the experts.

Your due diligence should be to demand that your IT staff, external organization, or an individual consultant bring together an assessment process that translate all this stuff into a simple, quantitative, decision matrix.

¿Por qué los equipos de Scrum tienen un tamaño limitado?

Visto desde distintos ángulos podemos ver diferentes explicaciones para la recomendación. Primero vemos cual es la recomendación (tomada de The Scrum Guide v2016, p6. Development Team Size):

El espíritu de la “regla”

"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint."

El límite inferior: 3

"Fewer than three Development Team members decrease interaction and results in smaller productivity gains."

Tamaño mínimo de un equipo de Scrum

El límite superior: 9

“Having more than nine members requires too much coordination.”

Tamaño máximo de un equipo de Scrum

Integrantes: solo los ejecutores

"The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog." 

Así que, tendremos equipos con un mínimo de cinco (5) integrantes y un máximo de once (11). Debemos recordar que el equipo de Scrum se compone del Equipo de Desarrollo, el Scrum Master y el Product Owner. En este cálculo asumimos que el Scrum Master y el Product Owner no son ejecutores (no toman trabajo dentro del sprint backlog).

En este artículo nos enfocaremos en el tema de los canales de comunicación. Para saber cuántos canales de comunicación tendremos en un equipo se utiliza la formula CM = ( n * (n - 1) ) / 2, donde n es la cantidad de integrantes del equipo. Volviendo a nuestros límites tenemos que:

• Inferior n=5: CM = 10 dado por (5 * 4 ) / 2
• Superior n=11: CM = 55 dado por (11 * 10) / 2

Es decir, que en un equipo de Scrum pudiéramos tener que manejar entre 10 y 55 canales de comunicación a lo interno del equipo. A esto súmele la interacción con entes externos. Recordemos también que se recomienda que el área principal de trabajo para un equipo de Scrum sea un espacio compartido por todos los miembros (colocación), esto entre otras cosas para aumentar la comunicación osmótica. En otras palabras, se busca que la comunicación sea abierta y que permee, y haya un máximo grado de sincronización entre los miembros. 

Se busca que los miembros escuchen la mayor cantidad de información posible, aun esta no esté dirigida directamente a ellos. Dependiendo de la cultura del equipo esto puede suponer un alto grado de interrupciones a las labores individuales de cada miembro ya que fácilmente se puede romper su concentración cuando necesitan concentrarse en alguna tarea. 

La cantidad de canales de comunicación también dificulta la labor del Scrum Master. Este deberá poder gestionar impedimentos, mejorar la dinámica del equipo, llevar una bitácora mental de las distintas interacciones entre los miembros y sus oportunidades de mejora. 

En un equipo muy grande, la duración de las ceremonias tendría que extenderse para darle tiempo a cada miembro a tener una participación de calidad. Tomando el daily como ejemplo tenemos que cada miembro del equipo puede hablar hasta 1min:40secs en un equipo de 9 (máximo). A medida que la cantidad de miembros crece este tiempo se irá reduciendo.

Un tema que puede ser analizado por su propio peso y que se relaciona con los canales de comunicación son los medios utilizados. Yo y mis compañeros de equipo utilizamos mayormente la comunicación oral, cara a cara, pero también utilizamos canales electrónicos como Slack. Imagine ahora que además de tener 55 canales de comunicación posibles “cara a cara” ahora también podemos hacer lo mismo en Slack. Podemos tener también grupos cerrados donde se manejen temas que pudieran interesar a todo el equipo. 

En resumen, la cantidad de miembros del equipo impacta de manera directa y positiva la cantidad de canales de comunicación totales. Con el aumento de los canales de comunicación vienen muchas complicaciones en cuanto a la autogestión de un equipo. Esta no es la razón única o principal para mantener un tamaño limitado sobre los equipos agiles, pero definitivamente es un factor de peso considerable.

Como ilustración aquí se presentan la cantidad de canales para equipos de dos a cinco personas.

Canales de comunicación: equipos de 2 a 5 integrantes

Requirements, Acceptance Criteria, and Scenarios

What they are?, How they differ?, How they are related?

Context

We are building a very basic calculator, one that only supports the four basic operations: Addition, Subtraction, Multiplication, and Division.

Requirements

(from the SWEBOKv3 @ http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf)

What they are?

- At its most basic, a software requirement is a property that must be exhibited by something in order to solve some problem in the real world.

What they do?

- Express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.

Properties:

• An essential property of all software requirements is that they be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement.
• Priority rating
• Uniquely identified

Types (Categories) of Requirements

• Product: A product requirement is a need or constraint on the software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course”).
• Process: A process requirement is essentially a constraint on the development of the software (for example, “The software shall be developed using a RUP process”).
• Functional: Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features. A functional requirement can also be described as one for which a finite set of test steps can be written to validate its behavior.
• Nonfunctional: nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

Examples

We're going to map each of the basic arithmetic operations to a single requirement, so we'll have:

• Req-1: The calculator must support the Addition operation.
• Req-2: The calculator must support the Subtraction operation.
• Req-3: The calculator must support the Multiplication operation.
• Req-4: The calculator must support the Division operation.

Acceptance Criteria

Set of statements indicating how to judge if a given [software] component or system satisfies certain requirement. Each element, criterion, is an specific statement.

Examples

We, as math experts, know that these operations have certain "properties". We can think of these properties as rules or statements that further define some aspect of the requirement (arithmetic operation). So, now we'll take the Addition as the subject of our examples. We'll have one Criterion for each of the Addition Operation's properties.

• Cri-1-1: The calculator must comply with the Commutative property for the Addition operation.
• Cri-1-2: The calculator must comply with the Associative property for the Addition operation.
• Cri-1-3: The calculator must comply with the Identity property for the Addition operation.
• Cri-1-4: The calculator must comply with the Distributive property, respect to the Multiplication, for the Addition operation.

Scenarios

Set of concrete examples used to validate a single Acceptance Criteria.

Examples

Now we'll take the Commutative property for the Addition operation, as the subject of our examples of Scenarios. What we need are concrete Addition expressions that validate the "presence", or "proper implementation" of the Commutative property (Acceptance Criterion) for the Addition operation (Requirement).

• Sce-1-1-1: 4 + 2 = 2 + 4
• Sce-1-1-2: 10 + 5 = 5 + 10
• Sce-1-1-3: 1 + 2 + 3 = 3 + 2 + 1

A picture is worth a thousand words

Here is a breakdown structure of these three concepts:

Requirements, Acceptance Criteria, and Scenarios breakdown

Summary

What they are? see above definitions.

How they differ? 
Requirements are high level descriptions of system characteristics. Acceptance Criteria are elements used to comply with the "verifiable" property of requirements. Criteria must state how to determine if the software system had properly implemented the requirement.

Often, acceptance criteria are not detailed enough to be useful in practice, so we need concrete examples of Input-Output,  Input-Response Time, etc.; those are the Scenarios.

How are related?
From the above descriptions, you can infer that they are three levels of details of the same thing: what we expect the system to do.

But, what's the deal with all this?

• All actors of the SDLC process must understand what are, how they differ, and why are all three levels required.
• Requirements / User Stories, without Criteria and Scenarios will be to subjective to be verifiable.
• Criteria and Scenarios alone, will be too difficult to manage, without a grouping element (parent requirement).

The usage of all three levels bring a lot of benefits, such as better effort estimation of Stories, Criteria, and Tasks. They also bring some challenges about how to express, document and/or automate those validations. We can review all this in another article, here I just wanted to point out their difference and give some simple examples of each one.

Requerimientos, Criterios de Aceptación y Escenarios

¿Qué son?, ¿En qué difieren?, ¿Cómo están relacionados?

Contexto

Estamos construyendo una calculadora básica, la cual solo soporta las cuatro operaciones básicas: Adición, Sustracción, Multiplicación y División.

Requerimientos

(tomado del SWEBOKv3 @ http://www4.ncsu.edu/~tjmenzie/cs510/pdf/SWEBOKv3.pdf)

¿Qué son?

- En su forma mas básica, un requisito de software es una propiedad la cual debe ser exhibida por algo (componente / modulo / sistema / etc), con el objetivo de resolver un problema del mundo real.

¿Que hacen?

- Expresan las necesidades y limitaciones colocadas sobre el producto de software, el cual contribuye a la solución de un problema del mundo real.

Propiedades:

• Una propiedad esencial de todos los requerimientos de software es que deben ser verificables como una característica individual como requisito funcional, o a nivel de sistema como un requisito no funcional.
• Deben ser estar priorizados.
• Deben estar identificados de manera única.

Tipos (Categorías) de Requerimientos

• de Producto: un requerimiento de producto es una necesidad o constreñimiento en el software a ser desarrollado (ejemplo, "El software debe verificar que el estudiante cumpla con todos los pre-requisitos antes de que el o ella se registre para un curso").
• Proceso: un requerimiento de proceso es esencialmente un constreñimiento en el proceso de desarrollo de software (ejemplo: "El software sera desarrollado utilizando el proceso RUP").
• Funcional: los requerimientos funcionales describen las funciones que el software debe ejecutar; ejemplo: formatear un texto o modular una señal. A veces son conocidos como capacidades o características. un requerimiento funcional puede ser descrito como uno para el se puede escribir un conjunto de pasos de pruebas finito, a ser utilizado para validar su funcionamiento.
• No-funcional: los requerimientos no-funcionales son los que restringen la solución. Muchas veces se les conoce como constreñimientos o requisitos de calidad.

Ejemplos

Vamos a tomar cada una de las operaciones aritméticas básicas como un único requerimiento, así que tendremos:

• Req-1: La calculadora debe soportar la operación Adición.
• Req-2: La calculadora debe soportar la operación Sustracción.
• Req-3: La calculadora debe soportar la operación Multiplicación.
• Req-4: La calculadora debe soportar la operación División.

Criterios de Aceptación

Conjunto de sentencias las cuales indican como sera juzgado (evaluado) un componente de software dado para ver si satisface o no un requerimiento. Cada elemento, criterio, es una sentencia especifica.

Ejemplos

Nosotros, como expertos en matemáticas, sabemos que las operaciones aritméticas básicas tienen ciertas "propiedades". Podemos pensar en esas propiedades como reglas o sentencias las cuales definen en mayor detalle algún aspecto del requerimiento (operación aritmética). Así que ahora tomaremos la operación (requerimiento) Adición como el sujeto de nuestros ejemplos. Tendremos un Criterio por cada una de las propiedades de la operación Adición.

• Cri-1-1: La calculadora debe cumplir con la propiedad Conmutativa para la operación Adición.
• Cri-1-2: La calculadora debe cumplir con la propiedad Asociativa para la operación Adición.
• Cri-1-3: La calculadora debe cumplir con la propiedad Elemento Neutro para la operación Adición.
• Cri-1-4: La calculadora debe cumplir con la propiedad Distributiva, respecto a la multiplicación, para la operación Adición.

Escenarios

Conjunto de ejemplos concretos utilizados para validar un único Criterio de Aceptación.

Ejemplos

Ahora tomaremos la propiedad Conmutativa para la operación Adición, como nuestro sujeto. Lo que necesitamos son ejemplos concretos de expresiones de suma los cuales validen la "presencia", o "implementación correcta" de la propiedad Conmutativa (Criterio de Aceptación), para la operación Adición (Requerimiento).

• Sce-1-1-1: 4 + 2 = 2 + 4
• Sce-1-1-2: 10 + 5 = 5 + 10
• Sce-1-1-3: 1 + 2 + 3 = 3 + 2 + 1

Una imagen vale mas que mil palabras

Aquí tenemos un desglose de los tres conceptos::

Desglose de Requerimientos, Criterios de Aceptación y Escenarios

Resumen

¿Qué son? ver definiciones anteriores.

¿En que se diferencias? 
Son descripciones de alto nivel de características de un sistema. Los Criterios de Aceptación son elementos utilizados para cumplir con la característica "verificable" de los requerimientos. Los criterios deben especificar como determinar si el sistema de software ha implementado correctamente el requerimiento.

Con frecuencia, los criterios de aceptación no tienen el detalle suficiente para ser útiles en la practica, así que tenemos que utilizar ejemplos concretos como Entrada-Salida, Entrada-Tiempo de Respuesta, etc.; estos son los Escenarios.

¿Como se relacionan?
De las descripciones anteriores, usted podrá inferir que son tres niveles de detalle de la misma cosa: que se espera que el sistema haga.

Y ¿Cual es el asunto de todo esto?

• Todos los actores del proceso de desarrollo de software deben entender que son, en que se diferencian y porque son necesarios los tres niveles.
• Los Requerimientos / Historias de Usuario, sin sus Criterios de Aceptación y Escenarios serian muy subjetivos para ser verificables.
• Los Criterios y Escenarios solos serian muy difíciles de manejar, sin un elemento de agrupación (requerimiento padre).

El uso de los tres niveles trae muchos beneficios, como mejores estimaciones de esfuerzo requerido para las Historias de Usuario, Criterios y Tareas. También traen algunos retos interesantes sobre como documentar o expresar automatizar todos estas esas validaciones. Podríamos revisar eso en otro articulo, aquí solo quise resaltar sus diferencias y dar algunos ejemplos simples de cada uno.

Valor de Negocio vs Esfuerzo

Luego de una encuesta rápida ( https://plus.google.com/+LorenzoSolano/posts/U6ZSU5t22vA ), en la cual se preguntaba sobre la relación entre los Puntos de Historia y el Valor de Negocio, quise hablar un poco sobre este mal entendido.

Definiciones Rápidas (contexto: Agile, Scrum, Desarrollo de Software)

Valor de Negocio [Entregado]

Incremento en cierto aspecto de una organización, fruto de un cambio en algún producto de software. Ese aspecto puede ser una fuente de ingresos, mitigación de algún riesgo, etc.

En palabras simples, el valor de negocio entregado luego de una iteración / sprint es el incremento en la capacidad del negocio para generar más dinero o evitar ciertas perdidas (financieras, de reputación, etc.).

Puntos de Historia

Esfuerzo percibido, por un equipo de desarrollo, como necesario para construir cierta característica en un sistema de software.

Las ideas principales aquí son: percibido y un equipo de desarrollo [especifico]. Lo que esto significa es que el esfuerzo es una medida subjetiva, y que ese “sujeto” es un equipo de software en todo el universo. Usted no puede comparar un equipo a otro en términos de cuantos Puntos de Historia (esfuerzo) ellos le asignan a una característica a ser construida.

Los Puntos de Historia y el Valor de Negocio no tienen Relación

Escenario

Imagine dos equipos de desarrollo de software, a los cuales se les da la tarea de estimar cuanto esfuerzo requieren (no horas / tiempo, no dinero), para construir la Característica X. Ambos equipos tienen exactamente el mismo contexto (imaginario por supuesto): ellos pertenecen a la misma organización, responden a los mismos interesados, trabajan con las mismas tecnologías y herramientas.

Donde ellos difieren es en su nivel de experiencia. Así que, tenemos un Equipo de Principiantes y un Equipo de Expertos. Si usted les pregunta a los principiantes acerca del esfuerzo requerido para construir la Característica X, ellos responderán con un estimado mucho más alto que los expertos.

Desde el punto de vista del dueño del negocio, el valor agregado a la organización por la Característica X (luego de ser construida), es el mismo sin importar quienes lo construyan. El negocio solo quiere su nueva funcionalidad, no importa cuán difícil o fácil sea para los constructores lograrlo.

Utilizando un ejemplo menos abstracto; piense en que la cantidad de valor de negocio agregado por la Característica X, es un litro de agua fresca en el desierto. Imagine que su familia vive a una milla (1.6 KM) de distancia de la fuente de agua,

( fuente de agua: contenedor del "valor de negocio" )
Bayuda Desert Well by Clemens Schmillen CC. https://commons.wikimedia.org/wiki/File:BayudaDesertWell.jpg

y que usted necesita ese litro de agua para cocinar las comidas del día. Ese es su valor de negocio, usted necesita el agua no importa como la consiga.

Ahora viene el esfuerzo: si usted debe ir caminando y traer el agua a su casa, el esfuerzo requerido seria alto.

( esfuerzo requerido por el "Equipo de Principiantes" )
Desert walk https://www.flickr.com/photos/maartmeester/5130198174 by Maarten van Maanen @ Flickr.com

Pero, si usted utiliza un camello para ir y buscar el agua, entonces la tarea se vuelve más fácil.

( esfuerzo requerido por el "Equipo de Expertos" )
Camel at desert https://pixabay.com/en/camel-desert-sand-mongolia-692648/ by hbieser @ pixabay.com

Conclusiones

De esta comparación, inadecuada, me gustaría puntualizar algunas observaciones clave:

• No compare equipos utilizando su velocidad promedio (Puntos de Historia por Sprint)
• No asuma que un equipo entrega más valor de negocio porque ellos tienen una “velocidad” más alta que otro
• La velocidad de un equipo es solo para su uso
• Usted puede comparar la velocidad pasada a la actual, analizar tendencias y responder a cambios bruscos en ella (incrementos o decrementos) como indicador de que algo está pasando: nuevos miembros, rotación, cambios en infraestructura tecnologías, etc. Obviamente, la comparación será entre medidas presentes y futuras DEL MISMO EQUIPO.

Business Value vs Effort

After a quick poll ( https://plus.google.com/+LorenzoSolano/posts/U6ZSU5t22vA ), asking about the relation between Story Points and Business Value, I want talk about this misconception.

Quick Definitions (context: Agile, Scrum, Software Development)

[Delivered] Business Value

Increase on certain aspect of an organization, due to a change on some software product. That aspect could be a revenue stream, risk mitigation, etc.
In simple words, the delivered business value after an iteration / sprint is the increase on the business’s capacity to generate more money or to avoid certain losses (financial, reputational, etc.)

Story Points

The perceived amount of effort, for a development team, required to build certain feature into a software system.

The main concepts here are: perceived, and a [specific] development team. What this means is that the effort is subjective measurement, and that the “subject” is one software team in the entire universe. You cannot compare one team to another in terms of how much Story Points (effort) they assign to a given feature to be built.

Story Points and Business Value are Unrelated

Scenario

Image two software development teams given the task estimate how much effort (not hours / time, not money), they as a team, will require to build the Feature X. Both teams have the exact same context (imaginary of course): they belong to the same organization, respond to the same stakeholders, work with the same technology stack, and with the same tools.

Where they differ is in their seniority (experience) level. So, we have a Beginner’s Team and a Senior’s Team. If you ask the beginners about the effort required to build Feature X, they will respond with an estimate much larger than the seniors.

For the point of view of the business owner, the value added to the organization by the Feature X (after construction), is the same. They just want the new functionality, no matter how hard or easy is for the builders to do it.

In a, less abstract, example; think of the amount of business value added by the Feature X, as a litter of fresh water in the desert. Imagine that your family lives one mile away from the water well,

( water well: "business value" holder )
Bayuda Desert Well by Clemens Schmillen CC. https://commons.wikimedia.org/wiki/File:BayudaDesertWell.jpg

and that you need to get that litter of water to cook the day’s meals. That’s your business value, you just need the water no matter how you get it.

Now comes the effort: if you must go by foot and bring the water to your house the effort required will be high.

( effort required by the "Beginner's Team" )
Desert walk https://www.flickr.com/photos/maartmeester/5130198174 by Maarten van Maanen @ Flickr.com

But if you use a camel to go and get the water, the task becomes a little easy.

( effort required by less Expert's Team )
Camel at desert https://pixabay.com/en/camel-desert-sand-mongolia-692648/ by hbieser @ pixabay.com

Conclusions

From this, inadequate, comparison I want to point out some key takeaways:

• Do not compare teams per their average velocity (Story Points per Sprint)
• Do not assume that one team is delivering more business value because they have a higher “velocity” that another
• A team’s velocity is only for their usage
• You can compare past to actual velocity, analyze trends, and respond to abrupt changes on velocity (up or down) as an indicator that something is happening: new members, rotation, infrastructure / technology stack changes, etc. Obviously, the comparison will be between measurements of the SAME TEAM, past and present.