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

The Agile Way..

I am very happy to announce my new company web site:

Agile Ways Consulting Group

Little by little I'll be posting new articles and blog's entries there.

The objective of Agile Ways is to provide advice and help to companies that need to profit in an agile world. By the way, the first article here.

Open Agile Cordoba 2009 - Satisfacción Agil

Fué un placer compartir dos días en Agile Open Cordoba 2009. Hace pocos meses empezamos con la idea y con la colaboración de empresas locales (Intel, Xarae) y de compañías que ayudan a esta nueva forma de trabajar (Baufest, Sabre Holdings) pudimos realizar este evento que ha tenido una concurrencia muy grande, sobre todo considerando que fue el primer evento.
Pero lo más importante fué la gente. Vinieron de diferentes empresas, ámbitos y de diferentes industrias. Todos ávidos de conocer de qué se trata Agile o de compartir su experiencia. Si hasta se llegaron de países vecinos (Chile, Bolivia) de por supuesto de Provincias hermanas (Corrientes, Bs. As.).
Las sesiones fueron realmente aprovechadas, me hubiese gustado estar en más de una a la vez, pero los temas eran tan interesantes que costaba decidir a cuál asistir.
Hablamos de Planificación y Estimación agil, contratos ágiles, juegos, introducciones, etc. pero lo que más me llamó la atención fueron las ganas de las personas de cambiar hacia un nuevo paradigma de trabajo que nos permita realizarnos como mejores seres humanos. Nadie obliga a chicos de 20ypico estar un Sábado investigando y profundizando cómo ser un mejor profesional, sin embargo, ellos estaban allí... Esta gente es el motor del cambio en cada una de las empresas y en nuestra sociedad.
Dimos el primer paso hacia una comunidad ágil en Córdoba. Gracias a todos por haber compartido esta experiencia conmigo.

Por cierto, tremenda la buena onda de la gente de IES21 :-)

Se viene Open Agile Córdoba 2009

El próximo viernes se realizarán en el IES las jornadas abiertas Open Agile Córdoba 2009.

Es un paso para la comunidad ágil en Córdoba dado que nos reunimos muchos de los agilistas de Córdoba para organizar estas jornadas que son parte de la difusión que estamos realizando a nivel nacional (Argentina Open Tour) en la Comunidad Latinoamericana de Metodologías Ágiles.

El formato Open Space es óptimo para poder sacar provecho de la experiencia en distintas empresas a nivel local que están transicionando hacia Agile como nueva forma de hacer negocios en un entorno cambiante y agresivo.

Los espero el Viernes y el Sábado. Gracias a los sponsors (Intel, Sabre, Baufest, IES, Xarae, Sadio) vamos a poder atenderlos con un pic-nic ágil :-)

You cannot multi-task

One common issue among my clients in different industries is the fact that they manage multiple responsabilities and tasks in a multi-task fashion driven by interruptions.

Multi-tasking is a productivity killer. I has been demonstrated that when you are interrupted, the same task takes up to four times longer to be completed compared to the same taks with no interruptions.

The next immediate effect is the amount of errors introduced when you´re interrupted, being 3-4 times more when switching tasks and when you´re managing numbers and 4+ times errors when you manage words.

While keeping a cellular phone conversation in the car is worse than driving drunk (based on statistics), the same occurs in the office. To be on-line, chat enabled, trying to get things done but switching contexts contantly is a very bad idea.

Boosting productivity

Applying the simple agile principle of prioritization scrum teams assigned to multiple projects and driven by interruptions can deal with this. By defining in the planning day the context and the allowed switch for the day, the team can limit the interruptions and boost the ideal hours of productivity.

Using the context concept from David Allen´s GTD productivty system, team members can distribute their days like:

@Project B (Morning)

@Project C (Afternoon)

@Project A (COB)

Of course this requires the management commitment and a do-not-disturb policy across the organization. Managers can be interrupted, but team members should be able to manage their time in order to boost productivity.

You cannot multi-task. By dividing the day in smaller chunks with less interruptions your productivity as team member is going to be increased dramatically and you are not going to get stuck in the middle of non-productivity.

Decide as Late as Possible

After years of Agile Development I am now positive that no matter how well the development team implemented Agile practices, how well they run their iterations, improve their velocity, how sophisticated is the set of test automation if the organization is still driving business in an old-fashioned fixed price way. 

I have observed the auto-destructive behavior of making commitment per contract when information is the worst possible in the software product development cycle. Developers are pushed to provide estimates (assign probabilities) and these probabilities are written and signed in a contract, with no clues about what the customer really wants or what is to be developed. That's what Mary Poppendieck compares with get married with a woman you just know for a couple of hours.

Homer and Ned Flanders went to the casino's bar and get drunk in the "Viva Ned Flanders" episode, waking up the next morning in their hotel room and married to two cocktail waitresses: Homer's new wife is named Amber, and Ned's new wife is Ginger (who have video evidence of the two men marrying them while drunk). That's a funny episode but it is tough when you receive a project with impossible fixed dates and unknown scope.

Lean Development has an answer for that and there is a solution I suggest to my customers. Decide as Late as Possible and use Agile Contracts. Of course it is not a simple change. Simply some managers feel more confident when they have some linear (impossible) schedule in fornt of them. Well, this is the news:

* Making predictions DOES NOT make you predictable

Taking risks and commitments when information is scarce, in the beginning of the "cone of uncertainty" is simply a bad decision. Agile contracts suggest to share the risks until the cone starts to close, and commitments can take with more probability of occurence. Of course, this require long hours educating the customers and get a collaborative environment that allow working together.

El Agile en tiempos de Crisis (Agile in the time of Crisis)

Global crisis is for real. In 2009 most of the companies are planning for mitigate the impact of the global crisis and organizing resources for overcome the year with the less damage as possible.

Should they think in change? Of course they do.

The crisis is the opportunity to stick to lean development principles and adopt agile practices for optimizing the returned value of their investments. 

1. Eliminate Waste

2. Amplify Learning

3. Decide as Late as Possible

4. Deliver as Fast as Possible

5. Empower the Team

6. Build integrity in

7. See the whole

aren't them great principles? certainly they are. Even more they need to be applied in a critical environment. 

If any Crisis is an opportunity, certainly this year is the opportunity for companies to become agile. But the first step is to know and adhere to these seven principles, companies must understand that Principles conduct to Practices and if organizations adopt isolated Practices (agile practices) without  a deep understanding of lean principles, simply it is not going to work.