Warning: Scrum can cause pain

The model proposed by Scrum is so simple that bottom-up feedback is immediate and many times could cause some pain. The Stand-up daily meetings (A.K.A. Scrum meetings) expose to the organization the productivity impediments and organizational inefficiencies. The intention of this outstanding almost real-time feedback is to allow the organization to correct and remove impediments in a record time.

Smart managers will use this information for re-engineering processes and correct organizational defects while identifying the possibilities to improve in a continuous identification framework.

Some impediments that may appear not to be obvious are:

• Workers that need training in the technology (blockers under-estimated)
• Unclear Priorities in the Backlog
• Team members are assigned and committed to other tasks
• Inadequate design
• Lack of commitment and team participation

However, not everybody is prepared to deal with this pain. While some managers can take this as a huge opportunity to improve and excellence, others can be afraid and be resistive and blind over the evidence and express: "Just tell me when will be done" , "This Scrum thing is not for us, our culture is different" (sic)

Some organizations prefer to be less than efficient while they are comfortable due to their margins due to the unique products in the market niche they are. They have the waste of abusing of excessive meetings, organizations based on hierarchies, excessive management and incompetence.

But this is a fast world. The market will ensure that agile companies with new technology or more efficient organizations just defeat the inefficient ones.

Source: Agile Ways Consulting Group

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.

γνωθι σεαυτόν - 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.