Defendiendo los indefensibles vs. Defendiendo los indefensos

"Mejor morir a pie que vivir de rodillas"

La mayoría de nosotros somos familiares con las palabras de Zapata. Cien anos anteriores (cuando menos) en EEUU, el mismo sentimiento fue expresado por Patrick Henry, cuando dijo "Give me liberty or give me death". Para tener una revolución se requiere el ímpetus del cambio, algo nos hace reaccionar y el individuo invoca sus derechos humanos y se levanta para enfocarse y forzar el cambio. Después de el cerrillo inicial, la revolución quema fuertemente, pero al pasar de el tiempo, la gente se cansa y se empieza a tratar de normalizar la situación. Se pregunta uno, porque estoy peleando? Con cuanto cambio se puede vivir? Por que se requiere el cambio?

En la guerra de independencia de EEUU, se piensa que el 90% de la populación era loyalista - soportaba a el Rey de Inglaterra y NO a los revolucionarios. La revolución estadounidense no tardo mucho, y la estructura del liderazgo se mantuvo intacta - dándole la única posibilidad de el resultado que hoy se ve. En Latinoamérica, por lo mucho no se vio este resultado, y las guerras de independencia y cambio duraron muchísimo mas.

Siendo ScrumMaster, se ve que el cambio que se requiere de la organización es un cambio gigante. Se sabe que el "paradigm shift" requerido para poder pensar ágilmente involucra no solo IT, sino que casi todos los departamentos de la organización. IT casi siempre es el grupo que comienza el cambio, aunque yo he visto que a veces el grupo de negocios lo ha empezado. Todos los demás grupos no tienen necesidad del cambio, ya que ellos tienen su estructura y manera de trabajar. Para poder tener un cambio completo (para poder emular a Toyota y a Google) requiere MUCHISIMO esfuerzo, tiempo y sacrificio. La mayoría de las empresas (imagínense las compañías!) no tienen lo necesario para poder pagar por este cambio, ni en manera monetaria, ni emocional, ni en tiempo. Pero si como ScrumMaster les puedes dirigir, y si se empeñan a tratar de cambiar - entonces vale la pena el esfuerzo! Para el ScrumMaster, esto debe ser clarísimo, ya que el primero que cae en los frentes de la revolución es el General de campo (Washington, Gandhi, Hidalgo y Bolívar son ejemplos buenísimos de este hecho). Si se puede efectuar el cambio, el General es un héroe y merece la adulación y gracias de la organización o pueblo. Si no se puede efectuar el cambio, pues ya la historia nos da el resultado.

Entonces, con el conocimiento de arriba, como se reacciona un buen ScrumMaster (al estilo de Ron Jeffries) cuando el mismo equipo de Scrum se niega a cambiar? Cuando el equipo de IT actualmente hace excusas por el resto de una organización para NO efectuar el cambio? Cuando los "lideres" de IT se enfocan a sacudir la educación y la implementación de Scrum o Agil en la compañía? El riesgo que uno toma al enfocar el cambio es casi insurmentable, y como ScrumMaster se encuentran individuales que aman y entienden la metodología. Pero también se encuentra el sabotaje, se encuentran los miembros nefarios, y los que no quieren el cambio. Para muchos de nuestros compañeros, esto es incomprensible. Yo lo he encontrado de cinco equipos cuando menos dos veces. Una fue traición abierta, y se pudo identificar tempranamente y proteger al equipo. La otra fue presión personal de un individuo del equipo, pero sus decisiones internas afectaron al equipo negativamente. De ambos casos escribiré después, por ahora quiero enfocar - cuando se defiende al que quiere y cuando se defiende a los que no quieren, con tanto riesgo al cuello del ScrumMaster?


Se comprende bien cuando la resistencia al cambio se enfoca fuera de los equipos. La mejor defensa para esta resistencia es el desarrollo de los equipos a una mas alta nivel de producción y comunicación, conjuntada con un nivel mas alto de educación para el grupo resistente (comunicando expectativas propias). Es fácil ganar este argumento cuando se ve el resultado de el equipo (dado en working software, delivered value, y aceleración del tiempo de desarrollo). Pero cuando la resistencia es interior de IT, y específicamente cuando se encuentra uno con un equipo dividido, la reacción para mi es mas difícil. Claro, en el mismo cambio y tempranamente se encontraran con los individuos que no quieren ser parte de un equipo. Esto es fácil de remediar. Pero después, cuando empezamos a implementar ScrumBut, quien tiene el derecho de requerir el cambio? Cuanto compromiso es suficiente? Y como se maneja el grupo que dice querer cambiar pero que no se empeña en hacer ningún sacrificio para el cambio? Últimamente, y con un equipo entero he llegado a una simple solución - se deja el equipo en el nivel de la mediocridad que se le hace cómodo. He llegado a que NO se defienden los que no quieren ser defendidos.


Con el grupo mixto, cuando se ve que la mitad o mas de el grupo quiere efectuar los cambios, pero el PO no quiere cambiar; o el Lead Developer no deja que los desorraldores hagan lo que necesitan - como se abandona el grupo? Como se pregunta el cambio de las "golden calves" de la organización, cuando esto mismo es rogar por el termino? Claro, muchas veces en la organización se llega a la observación "Mira, esos ScrumMasters no hacen nada!! Que valor nos dan? Y nos cuestan tanto..." Estas organizaciones no entienden el rol del liderazgo. Y no deben de ser defendidas! Pero el equipo, los que si quieren...


Hay un dicho cuando uno empieza la certificación de ScrumMaster "a dead ScrumMaster can help no one". Acordando con las organizaciones, he visto dos muertes de Scrum. He educado a mis equipos, y muchas implementaciones han nacido de mis esfuerzos. Pero si no se puede tener una implementación debido a la organización misma, la muerte es inevitable. Quizás es mejor identificar esto tempranamente, pedir los cambios inmutables y tener el cesamiento del esfuerzo en este tiempo mas temprano para el beneficio de los que quieren hacer lo que es necesario - que seguir tratando de defender lo indefensible, y morir en emboscada por un equipo inmaduro o no cometido. Con el único resultado de ver a el resto del equipo a sufrir el regreso a una marcha de muerte...

Now in English -

“It's better to die upon your feet than to live upon your knees!”

Most of us are familiar with the words of Emiliano Zapata. One hundred years before him (at least) in the United States, the same thought was expressed by Patrick Henry, when he said “Give me liberty or give me death”. In order to start a revolution we need to have the necessity for change, something that makes us react and the individual will invoke his human rights and takes a stand in order to focus and force the needed change. After the initial spark, the revolution burns strongly, but as time passes, people get tired and they inevitably try to normalize their surroundings. They ask themselves, why am I fighting? With how much change can we live? Why do we even need this change?

In the war of Independence of the United States, it is thought that 90% of the colonists were loyalists – supporters of the King of England and NOT of the revolutionaries. The American Revolution was relatively short lived, and the leadership structure was left intact – giving it the only possibility for the result that we now see. In Latin America, for the most part this was not the case, and the wars of independence lasted a lot longer.

Being a ScrumMaster, you see that the change that an organization needs to undertake is a gigantic endeavor. You know the kind of “paradigm shift” required for an Agile mindset to occur involves not only IT, but almost all the departments within the organization. IT usually is the department that is leading the change, although I have seen at least one case in which the business has started the implementation. All the other departments may not need to change, given that they probably have their way of doing things. To have a complete change of mindset (to emulate Toyota or Google) requires an INMENSE effort, time and sacrifice. Most industries (not to mention companies) do not have what it takes to be able to undertake this change, neither monetarily, nor emotionally, nor in terms of time. But if as a ScrumMaster you can guide them, and they are willing to try to change – then it is worth the effort in undertaking! For the ScrumMaster, it should be very clear that the first leader that falls in the front of the revolution is the Field General (Washington, Gandhi, Hidalgo and Bolivar are great examples of this fact). If you can get the change in place, the General is a hero and deserves the adulation and thanks of the organization or people he helped. If the leader cannot affect the change, well history tells us what happens in these cases.

With the above being known, how should a good ScrumMaster (a Ron Jeffries emulator) react when the Scrum team itself refuses to change? When the IT team actually makes excuses for the rest of the organization in order to NOT affect change? When the IT “leaders” focus on placing Scrum education and implementation on a shaky basis for the company? The risk that one takes in helping to get a focus for change is almost insurmountable, and as a ScrumMaster you will find individuals that understand and love the Agile methodologies. But you also will find saboteurs, nefarious users and those that are threatened by change. Many in the Agile movement find this incomprehensible. In the five teams I have helped lead, I have discovered these types of scenarios twice. Once, it was a sabotage issue, and I was able to identify it and try to protect the team. The other was due to an individual team member’s pressure, but his own decisions affected the team badly. I will write about both of these cases in detail later, but for now I want to focus on this point – when do you defend those who want to be protected and when do you defend those who do not want protection, with so much risk riding on the ScrumMaster’s neck?

It is easy to understand when you meet resistance to change from outside IT groups. The best defense against this type of resistance is the development of the teams to a higher level of performance and communication, in conjunction with an educational push for the resisting team (setting appropriate expectations). It is easy to win this argument when the team’s results are easy to see (especially in terms of working software, delivered value, and time to market acceleration). But when the resistance is from within the IT organization, and specifically when you are dealing with a divided team, it is more difficult to have an appropriate reaction. Of course, you will see the individuals who resist change and teamwork very early on just due to the changes that are needed. This is relatively easy to remedy. But after a while, when the organization begins to adopt ScrumBut, who has the right to request change? What compromise level is enough? And how do you handle a team that says it is interested in change but that will refuse to make any sacrifice needed for change to take place? Ultimately, with one team I have come to a simple solution – you leave the team at the level of mediocrity it finds comfortable. I have reached the point of NOT defending those who do not want to be protected.

With a mixed team, when you see that half or more of the members want to commit to the changes, but the PO is not interested; or the Lead Developer does not let the Developers do what they need – how can you abandon this team? How do you ask the organization to change the “golden calves”, when this is at best dangerous or possibly career ending? Of course, some organizations reach a point where they observe ”These ScrumMasters don’t do much!! What value do they really bring? And they are a bit expensive…” These organizations do not understand the role of leadership. And they should not be helped! But the team, those that really want it…

There is an adage you may hear when you get your ScrumMaster certification “A dead ScumMaster can help no one”. I have seen two failed Scrum implementations in the organizations I have tried to help. I have educated my teams, and many other implementations have come as a direct result of these efforts. But if the implementation is not organizationally possible, the death of the effort is inevitable. Perhaps it may be easier to identify this possibility early on, asking for those immutable changes at this early stage and have the effort cease at the earlier time frame for the benefit of those that want to implement the needed changes – rather than continuing to try to defend the indefensible, and suffering sabotage at the hands of an immature or uncommitted team or organization. With the only reward being for you to see the teams slip back into a return to a death march…