Redefining "Distance" in a distributed Scrum team

While most of the bibliography about Scrum implementations address the challenge of having a distributed or a dispersed team with a strong advisory "WARNING - Do not use Agile in distributed teams, simply it does not work" , many of us have to deal with the reality of implementing agile in a distributed environment. I do not even know about any company that has not distributed issues:

• Distributed customers


• Distributed assets


• Distributed knowledge


• Distributed personnel

Then we cannot heed the fact of distribution of problems.

Then I would like to re-define the "Distance" concept used in Scrum teams. The fact that a Scrum team is in the same room, plenty of blackboards and little yellow papers does not mean that necessarily that the team is within a short distance. There are some other variables which must be analyzed as different forms of "separation".
There is an excellent article written by John Puopolo in the Scrum Alliance site: "Be there or be Square" that states most of these dimensions. One common conclusion is that it is impossible to be agile if you are separated. I would like to re-analyze this concept by redefining the Distance in Scrum concept:

Distance_in_Scrum = Multi-dimensional variable measured between different forms of separations:

• A = Customer distance


• B = Geographical separations


• C = Business/Technology separations


• D = Separations in Time and Chronobiology separations


• E = Skills separations


• F = Cultural separations


• G = Organizational distances

Distance in Scrum Teams = f(A, B, C, D, E, F, G)

Multivariable Analysis

I would like to decompose the analysis of each variable in further blog's entries. From a systems point of view, each variable here represents a challenge in itself.

Many companies make the mistake of believing in Communication Technology as Distance Remedy, while the Dislocated communication media, can alleviate the problem, E-mail, Chat, Wiki sites, Phone calls, Phone meetings are of course less effective than the communication taking in-person. I have seen people seated at 2 meters of physical distance that do not communicate each other for weeks (working in the same project!)

Chronobiology is also another important topic I want to analyze. Global teams must understand the West-East effect of the Circadian Rhythm when time zones are really different, but also the longer cycle that derive from the North-South effect of being here in summer in Argentina when my colleagues are suffering a cold winter (!). There is no much research on that and I'm sure it impact on the global team performance.

Next entry I am going to analyze the chronobiology impact in Scrum teams distance.

Ventajas Competitivas en la Industria del Software en Córdoba.

Esta entradad del blog está en Español dado que este tema es un problema doméstico. Es como el problema que nos afecta a todos los Cordobeses, Talleres y su pésima campaña 2008...

Hoy en la edición del Domingo de La Voz del Interior aparece el Ministro Tulio Abel Del Bono (Ministro de Ciencia y Tecnología de Córdoba) con una nota que dice "Mejora de la competitividad en el sector productivo cordobés".
Sin dudas, Del Bono es una persona inteligente, la nota es clara y establece el nuevo paradigma del conocimiento como variable y Ventaja Competitiva fundamental y la innovación productiva como VC indispensable para competir con diferenciación.

Quisiera analizar la nota desde el punto de vista de la Industria del Software arraigada en Córdoba y revolucionada desde el 2001 hasta la fecha.

La primera contradicción que encuentro es la misma Ley de Promoción Software (Ley 25922).

En primer lugar quisiera dejar claro que la ley es muy buena en todos los aspectos y que es muy encomendable el esfuerzo realizado por la gente que luchó tantos años para poder tenerla, esta perspectiva no es una crítica destructiva, sino una oportunidad de mejora detectada a la Ley.

Inmendiatamente despues se hace evidente que la ley obliga a las empresas a contar con una "Certificación de calidad" de producto o servicio. Cuando investigamos un poco más sobre la Ley, nos encontramos que los modelos "reconocidos" son CMM, CMMI e ISO.

En la Industria del Software -quizás más que en cualquier otra área- los trabajadores del conocimiento son los verdaderos poseedores de la capacidad de las empresas. En el famoso "iron triangle" formado por Personas, Procesos y Herramientas, es evidente que el conocimiento está en las Personas y el manejo de conocimiento basado en mejora de Procesos y Herramientas ha traído hasta ahora resultados frustrantes.

Hablo con conocimiento de causa. He participado activamente de 4 assessments de CMM, CMMI, auditorías ISO, Engineering Process Groups, etc. Mi conclusión es simple:

Los modelos tradicionales basan la gestión de conocimiento en mejora de procesos, ignorando el talento de las personas como motor indispensable de la innovación.

La innovación productiva es dinámica. Depende de los Ingenieros y Técnicos que con imaginación, talento y sacrificio resuelven complejos problemas. Los procesos son el soporte de ese trabajo y son fotos estáticas de resolver un problema en forma similar al anterior.

En síntesis, El Régimen de Promoción de Software está impactando negativamente la Innovación Productiva en nuestra industria. El modelo de promoción eventualmente puede ser útil en industrias en donde los productos son tangibles y las máquinas en conjunto con procesos definidos solucionan el problema de la producción en serie.

Hay una nueva generación de trabajadores del conocimiento en Córdoba que están habilitados a trabajar en entornos cross-culturales y globales, con la única infraestructura de una Laptop y acceso a la red.
En este contexto los clusters no hacen la diferencia.

Si podemos rescatar un factor de éxito en la innovación tecnológica, es el aspecto cultural del Cordobés que le permite adpatarse a multiples entornos y resolver problemas en forma imaginativa. Nuestras empresas nunca podrán aportar la innovación productiva necesaria y mucho menos si tienen una ley de promoción que promueva la inproductividad.

γνωθι σεαυτόν - Know thyself

There is an ancient Greek aphorism that says: "Gnothi Seauton" (Know yourself). By ultimately understanding oneself is key for understanding what are our capabilities, our potential and understanding others as well.
Organizations are like humans too. There is a great book that states that every company has its own personality and according to its personality the organization is going to react in different environments.
(Companies are people, too. Discover, develop and Grow your Organization's true personality - Sandra Fekete with LeeAnna Keith)

Today I am analyzing how one organization manage multiple projects. Not surprisingly, I have noticed that while some organization appears to be reluctant to struggle among multiple projects, others are so eager to take advantage of the opportunities that many times losses all.

Probably one of the scariest but more benefitial effects on the upper management when the organization adopts a transparent, reliable Scrum framework is that the real organization capability is exposed. That means that all the stakeholders are now aware of the organization abilities, capabilities and bandwidth to absorb projects at the same time.

Where the limit is? - The overblown juggler analogy

One Juggler can deal with multiple balls according to his/her juggling skills, training, concentration, environment, etc. Multiple factors affect the amount of balls that one juggler can deal with.

Organizations are like humans too. And some organizations have to deal with multiple projects like a juggler.

The juggler does know his limitation, can be 3, 4, 5... 20, whatever number it is, there is a limit while juggling.

The concequences of jugging with more balls than possible have only a simple output: none ball in the air, all balls dropped.

Organizations might sadly discover this limit when they figure out that the delta added value to every project in paralel is not enough for getting anything done at all.

Here is the importance for every organization to create a healthy product porfolio. The same as stories, product must have a PRIORITY and organizations must understand their value, cost, knowledge point and risks in every case for treat them properly.

If the organization accept more work than its capabilities permit, then is going to suffer the overblown juggler effect: projects dropped, nothing at hand.